Playwright with AI: agents, MCP and self-healing tests (what works and what doesn't)

Short answer: since version 1.56, Playwright includes three AI agents (planner, generator and healer) plus an MCP server that lets an AI assistant drive a real browser. They speed up the first draft of a test and routine maintenance, but they don't replace human review: an agent that "heals" a test may be hiding a real bug.

What Playwright ships today

There are three distinct pieces, and it helps not to mix them up:

1. Playwright MCP: a server that exposes the browser to an AI assistant (for example, a coding assistant) using the page's accessibility tree instead of screenshots. The model "sees" roles, names and states, not pixels.
2. Test agents: three agents that can be used separately or chained together.
   • Planner: explores the app and produces a Markdown test plan.
   • Generator: turns that plan into Playwright Test files.
   • Healer: runs the tests and tries to repair the failing ones.
3. ARIA snapshots: a way to assert on the page's accessibility structure instead of brittle CSS selectors.

To get started, per the official documentation:

npx playwright init-agents --loop=vscode

Other options are --loop=claude, --loop=codex and --loop=opencode. The command generates the agent definitions, a specs/ folder with human-readable plans and a tests/ folder with the generated tests, plus a seed.spec.ts that sets the initial context.

A stable ARIA-based assertion

await page.goto("https://playwright.dev/");
await expect(page).toMatchAriaSnapshot(`
  - banner:
    - heading /Playwright enables reliable end-to-end/ [level=1]
    - link "Get started":
      - /url: /docs/intro
`);

This kind of assertion survives class-name or layout changes because it verifies what the user (and a screen reader) actually perceives.

Where it really saves time

• A first draft of coverage: the planner walks the app and proposes scenarios a busy team misses.
• Smoke tests and basic flows: login, creating a record, search. They are repetitive and the model handles them well.
• Routine maintenance: a renamed selector is the ideal case for the healer.

Where to be careful

• The healer can hide bugs. If a button disappears because of a real defect, an agent will "fix" the test by changing the selector or skipping it. The documentation itself warns it may skip tests when it detects broken functionality. Every healer change should go through code review like any other.
• You need a good seed test and, ideally, a product requirements document. Without context, the plan will be generic.
• Agent definitions must be regenerated when you update Playwright, otherwise they drift.
• A generated test that passes doesn't prove it validates the right thing. Review what it asserts, not just that it's green.

How to adopt it safely

1. Start with a narrow module (for example, login or checkout).
2. Ask for a plan, edit it yourself and only then generate code.
3. Review each generated test as if a junior developer had written it: names, assertions and test data.
4. Keep the healer as a suggestion in a Pull Request, never as an automatic change to the main branch.
5. Measure: how many maintenance hours did it save, and how many false greens appeared?

AI speeds up the mechanical part; deciding what to test and when a result can be trusted still belongs to the QA team. For the starting point, see how to automate your first Playwright test, or read what to automate first.

Want to evaluate how to apply this in your team without breaking your current suite? Let's talk.

Sources: official documentation for Playwright Test Agents and ARIA snapshots.