Playwright Test Agents in Practice: Planner, Generator and Healer
Playwright now ships three AI agents that plan, write and repair tests. What each one does, why the healer can hide a real bug, and the review rules we would put around them.
Playwright now ships three AI test agents: a planner, a generator and a healer. Discussion among QA engineers tends to split two ways. Some say the agents make tests far cheaper to write. Others say they make it cheap to build a suite nobody trusts. Which one you get depends on the rules you put around them.
What each agent does
From Playwright's documentation:
| Agent | Input | Output |
|---|---|---|
| Planner | A request, a seed test and, optionally, a PRD | A Markdown test plan in specs/ |
| Generator | The Markdown plan | Test files under tests/, with selectors and assertions checked in a live browser |
| Healer | A failing test | A passing test, or a skipped test if it believes the feature is broken |
You add them with npx playwright init-agents, choosing a loop for VS Code, Claude Code, Codex or opencode. Playwright says to regenerate the definitions each time you update Playwright.
Where they help
- Screens nobody got round to testing. The planner walks the app and lists its flows, including the dull ones such as form validation and empty states.
- Plans a person can read. A Markdown plan can be checked by a product owner before any code exists, and most of the value is in that check.
- Locators that match the real page. The generator tries each locator against the running app as it writes, so you start with fewer broken selectors.
Where they cause trouble
The healer can turn a real failure into a skipped test. Playwright describes the healer's output as "a passing test, or a skipped test if the healer believes that functionality is broken." Along the way it can patch locators, waits or test data until the run goes green. If it adjusts a test to fit broken behaviour, the regression ships with a passing build.
Suites grow faster than anyone reviews them. Writing tests used to be slow, which kept suites small and deliberate. With that limit gone, a team can add hundreds of tests in a week, many with waits and assertions nobody has read. A flaky test in that pile costs far more to find than it took to write.
Plans describe the app as it is. The planner explores what the app does today. If a checkout flow is wrong, the plan records the wrong flow as expected unless a PRD or a person says otherwise.
Rules we would put around them
- Review every healer change like any other code change. A diff that touches an
expectline needs a reason from a person. - Fail the build when a new
test.skipappears, and show the count of skipped tests on the team dashboard. - Give the planner the requirement as well as the app: the PRD, the ticket or the acceptance criteria.
- Read the Markdown plan before generating tests. A sentence is cheaper to fix than a test file.
- Keep a flake budget. If a generated test fails intermittently twice in a week, quarantine it, then fix it or delete it.
- Commit the agent definitions alongside the Playwright version, and regenerate them when you upgrade.
MCP or CLI?
The agents use Playwright MCP, which lets a model drive a browser through the page's accessibility tree instead of screenshots. Microsoft's README now steers coding agents towards Playwright CLI with skills, because CLI calls "are more token-efficient", and keeps MCP for long exploratory or self-healing loops. For most teams that means the CLI for everyday coding and the agents for planning and repair.
Our QA automation practice sets up these review rules as part of the pipeline. AutoGherk, our own tool, turns specs into test scenarios that stay linked to their Jira tickets, which gives the planner the requirement to work from. For the wider programme, see how we run an enterprise automation programme.
