Lesson 01 · ~15 minutes · First win

Make Claude Drive a Browser & Verify One Thing

Install the one tool that turns Claude Code into an autonomous UI tester — then watch it open a real browser, do a task, and confirm it worked.

Why this, why now → Your mission is to tell Claude "open my app and check that X works" and have it actually do it. Everything starts with one capability: giving Claude hands to control a browser. This lesson installs those hands and proves they work — against a public demo app, so there's nothing of yours to set up yet.

1. The idea in 30 seconds

Out of the box, Claude Code can read and write files and run shell commands — but it can't see or touch a web page. We fix that by adding the Playwright MCP server: a plugin that hands Claude a set of browser actions (navigate, click, type, snapshot, screenshot).¹

Crucially, Claude doesn't guess from a screenshot. Playwright gives it an accessibility snapshot — a clean text list of every button, link, and field on the page with stable IDs — so it acts on real elements deterministically.² That's what makes it reliable enough to test with.

Once installed, Claude runs the agentic loop:

READ page→ ACT (click / type)→ OBSERVE result→ DECIDE next↺

This is the whole game. A UI test is just this loop ending in an assertion: "did the thing I expected actually appear?"

2. Install the browser tools (2 min)

In a terminal, add the official Playwright MCP server to Claude Code:¹

claude mcp add playwright npx @playwright/mcp@latest

That registers a server named playwright. Confirm it's connected:

claude mcp list

You should see playwright listed. (Inside an existing Claude Code session you can also run the slash command /mcp to see connected servers and their tools.) The first time Claude uses it, Playwright may download a browser — that's normal.

If claude mcp add isn't available You can instead install the official Playwright plugin with one click from the Claude plugin marketplace³ — same server, same tools. Either path lands you in the same place.

3. Give Claude its first task (5 min)

We'll test the TodoMVC demo app — a public todo list, no setup required. Start (or stay in) a Claude Code session and paste this:

Prompt to Claude

Using the Playwright browser tools, open https://demo.playwright.dev/todomvc. Add a todo that says "buy milk". Then verify the todo actually appears in the list, and tell me the page's reported active-item count. Show me a screenshot as proof.

Watch what happens. Claude will call a navigate tool, take a snapshot to see the page, find the input field, type into it, snapshot again to confirm "buy milk" is now in the list, and grab a screenshot. That sequence is the agentic loop. You just delegated a manual UI check.⁴

4. Make it a real test: force a verdict

A demo isn't a test until it can fail. Run this follow-up to feel the difference between "it didn't crash" and "it actually worked":

Prompt to Claude

Now check something that should be false: verify the list contains a todo called "walk the dog". Report PASS or FAIL with the reason. Don't add it — just check.

Claude should report FAIL (that todo doesn't exist). That's the assertion doing its job — the single most important idea in testing. A check that can only ever pass is worthless; a good check takes a real stance about what should be true.

5. Your turn — practice loop

Drive it yourself. Ask Claude to do each of these against the same TodoMVC page, one at a time, and confirm the result:

Add two todos, then verify the counter reads "2 items left".
Mark the first todo complete, then assert it now shows a completed/strike-through state.
Delete a todo, then assert the list length dropped by one.
Make one intentionally wrong assertion and confirm Claude reports FAIL (not a crash).

Each is one trip through READ → ACT → OBSERVE → DECIDE, ending in an assertion. That's the muscle this whole mission is built on.

✓ You've won this lesson when… Claude opened a real browser on its own, performed a UI task you described in plain English, and gave you a truthful PASS/FAIL backed by a screenshot or the page's actual state.

Your teacher is in the room. Stuck, curious, or something behaved oddly? Ask me right here in chat — e.g. "why did it take a snapshot before clicking?", "what tools did Playwright MCP expose?", or "can it test a page that needs me to log in first?" I'll explain, and we'll fold anything important back into the glossary.

6. Where this is heading

Right now Claude tests live, ad-hoc — great for "check this works as I build." Next lessons will:

Point Claude at your own running app (starting a local dev server first).
Teach good selectors so checks don't break when your UI shifts.
Turn a successful manual check into a saved Playwright test you and CI can re-run.

References

Playwright MCP — Getting Started (install command & config). playwright.dev/docs/getting-started-mcp
Accessibility-tree snapshots vs. screenshot guessing (deterministic interaction). Playwright MCP docs · Builder.io setup guide
Official Playwright Plugin for Claude (one-click install, by Microsoft). claude.com/plugins/playwright
Using Claude + Playwright MCP as an autonomous QA engineer (realistic workflow). alexop.dev