Debbie O'Brien (four years on the Playwright team, now at Block) makes the case that you have "zero excuses" not to test: an AI agent driving a real browser through the Playwright MCP can write, run, and fix end-to-end tests for you. The heart of the talk is Playwright's three closed-loop agents — a planner that reads your app's accessible tree and writes a test plan, a generator that verifies each locator before it writes the test, and a healer that runs tests in debug mode and self-repairs them — plus the guardrails (project dependencies for safe login, seed files, commit-often) that turn AI-generated tests from flaky junk into a real testing solution.
fix me comment back to you instead of deleting code to force a passing test.O'Brien opens with a confession that doubles as a demo: switching jobs cost her all her slides, so she pointed the Goose coding agent and the Playwright MCP server at the YouTube recording of a previous version of this same talk, had it pull the transcript, and generated a fresh reveal.js deck on the flight over. That story sets the theme — AI is now good enough that "I don't have time to write tests" is no longer a defensible excuse. Whether you love testing or hate it, the argument goes, an agent can produce the tests, and the cost of shipping untested code is bugs you chose to allow.
For the newcomers, O'Brien recaps that Playwright is Microsoft's free, open-source library that automates real browser end-to-end testing by simulating user actions. The Model Context Protocol then "gives the LLM superpowers" — a toolbox to open a browser, click, and fill forms. Crucially, the Playwright MCP uses accessible-tree snapshots instead of vision mode, so it reads the accessibility tree to locate elements by their accessible names. That is what makes it fast, LLM-friendly, and especially well-suited to testing rather than brittle pixel matching.
She also untangles the fast-moving terminology: instructions (context you give the agent about your app), prompts (reusable commands worth saving), and agents — what VS Code used to call "chat modes" and Claude Code already called agents, now unified under one name.
The origin story: trying to book a hotel swimming lesson in Croatia, O'Brien hit a live JavaScript bug on a five-star hotel's site — the children-count selector closed the dialog on click. She concluded the site couldn't possibly have tests, and wrote one for them with AI to prove the point. The early approach was pure natural language against the Playwright MCP server ("book a swimming lesson, add two children, capture a screenshot to prove it"), and it worked — but it exposed the common failure modes of naive AI test generation.
Before Claude Opus 4.5, O'Brien catalogued recurring problems: the LLM sprinkled unnecessary timeouts everywhere (Playwright already auto-waits, so her instructions now say don't add timeouts — "and if you really need timeouts, fix your JavaScript"); duplicate locators matching multiple elements with the same name; and cookie banners the agent couldn't get past. Some needed manual fixes even on a tiny test — a warning that scale multiplies the problems. Playwright's answer was a suite of debugging tools with a "copy prompt" button in the HTML report, trace viewer (local and on CI), and UI mode, all of which feed the accessible tree and source context to an LLM so it can explain and fix a failure roughly 95% of the time.
Released around version 1.56, Playwright agents formalize what O'Brien had been hand-rolling as reusable prompts. Running the agents command auto-generates an agents folder, the MCP configuration, and a seed spec file — everything you put in that seed (import utilities, navigation, database seeding, global setup/teardown) is copied into every generated test.
The planner logs into the app, reads the accessible tree, and produces a structured, comprehensive plan — in her demo, 10 test suites and 45 test cases. Login is handled securely through project dependencies: a setup project authenticates and stores state, credentials sit in env variables, and the LLM never sees the password. O'Brien stresses she went through every single tool call to verify this herself.
The generator writes one test per file, and its defining trick is that it verifies elements before writing — running await expect(page.getByText(...)).toBeVisible()-style checks inside Playwright first, so it verifies itself before it actually writes that code. It reads from a test log rather than its own memory to avoid hallucinating, and runs multiple times for accuracy. It's deliberately not a one-shot "open the site and dump tests" flow — that gives terrible results; the slower, verified loop is what yields good ones.
The healer runs failing tests in debug mode with access to console and network, so it can distinguish a broken selector from a genuine API error. In O'Brien's run it took a suite from 23 failing tests down to 16 on its first pass, largely by adding a data-testid to disambiguate a duplicate menu locator. Its most important design constraint: it does not fake passing tests — when a failure is a real application bug, it leaves a fix me comment and hands the problem back to you.
Her tips: run headless when multitasking (--headless in the MCP config), enable auto-approve for speed once you trust it, and commit constantly — commit the test plan before generating, and commit before healing so you can diff what the healer changed. She's also reversed her earlier advice to generate section-by-section: since Claude Opus 4.5 (December/January), feeding the whole plan at once works and is simply better.
Looking ahead, O'Brien previews tests authored in Markdown (a return to Cucumber-style intent, done right this time — "go to nike.com, buy a pair of runners in size 42, test the whole process"), Ralph-style bash loops that pull the human out of the inner loop entirely, and a just-released Playwright CLI. The genuinely unsolved problem she flags is management: once anyone can generate hundreds or thousands of tests, test coverage and knowing which tests are worth running on CI becomes the new hard problem — and that responsibility falls on whoever ships the code.
"AI is going to write your test for you. That's the future."
"The agent's job is not to make everything green. It's to make good tests."
"There's absolutely zero excuses now."
"Why do we need to write code to be able to test something? We just need to be able to speak what we need and clearly define our needs for what needs to get tested."
| Approx. Time | Topic |
|---|---|
| 0:00 | Intro and audience poll — who knows Playwright and MCP |
| 3:00 | The lost-slides confession — AI-generated deck via Goose + Playwright MCP |
| 6:00 | Zero excuses to test; AI will write your tests |
| 9:00 | What is Playwright, and what is the Playwright MCP (accessible-tree snapshots) |
| 13:00 | Instructions vs prompts vs agents (chat modes renamed to agents) |
| 16:00 | The broken hotel swimming-lesson booking and the first AI test |
| 20:00 | Common issues: timeouts, duplicate selectors, cookie banners |
| 24:00 | Debugging tools: HTML report, trace viewer, UI mode, copy-prompt / fix with AI |
| 28:00 | Playwright agents arrive (v1.56): planner, generator, healer |
| 31:00 | Two MCP servers — Playwright MCP vs Playwright test MCP |
| 34:00 | Planner agent, seed files, and secure login via project dependencies |
| 39:00 | Generator agent — verify before write, reading the test log |
| 42:00 | Healer agent — debug mode, fix-me comments, not just green |
| 45:00 | Best practices: headless, auto-approve, commit often |
| 46:30 | The future: Markdown tests, Ralph loops, the test-coverage problem |
| 48:00 | 30-minute challenge and wrap-up |