Playwright's planner, generator, and healer: self-healing tests or self-hiding regressions?

Playwright's 2026 release added three built-in test agents, and by the week of July 21 every QA lead I talk to wanted an opinion on them. They arrived alongside an MCP server that gives agents full browser control through accessibility snapshots rather than screenshots. The agents split the E2E job cleanly. The planner explores your app and writes a Markdown test plan. The generator turns that plan into runnable tests and validates the selectors it picks. The healer takes a failing test, replays it, and rewrites the locators until it passes. That last one is the reason I am writing this, because "until it passes" is doing a lot of work in that sentence.

What shipped

• Planner: crawls the application and produces a human-readable Markdown plan you can review before a single line of test code exists.
• Generator: converts the plan into executable Playwright tests with selector validation, so it does not hand you locators that never matched anything.
• Healer: replays a red test, inspects the accessibility tree, and adjusts locators to make it green again.
• MCP server: exposes the browser to coding agents such as Claude Code through accessibility snapshots, which the team describes as token-efficient compared to shipping pixels into a context window.

The speed numbers circulating with the release put Playwright at roughly 290 ms per action against Selenium at roughly 536 ms. For new projects in 2026 Playwright is the default; Selenium is for legacy suites. As of September the package still pulls around 52M npm downloads a week, so this is the mainstream E2E runner changing how tests get written and repaired, not a niche tool getting an experimental feature.

Why accessibility-tree-first is the real change

Pixel-clicking agents were always fragile: a font change, a dark mode toggle, a different viewport and the vision model is guessing. The accessibility tree gives the agent element roles, names, and states, which is what a good human-written locator uses anyway. It is also the catch: the approach depends on the quality of your app's accessibility tree. If your buttons are anonymous divs with click handlers, the agent inherits that mess and picks locators that are stable today and meaningless tomorrow.

Self-healing or self-hiding

Here is the failure mode I care about. A test fails because the checkout button moved from the summary panel into a modal. That is a product regression: the flow changed and nobody decided it should. The healer replays, finds a button with the same accessible name in the modal, updates the locator, and the suite goes green. The regression was detected and erased in the same CI run. Nobody saw it.

A healer that can rewrite locators without a human reading the diff is not repairing tests, it is deleting evidence.

The second cost is nondeterminism. The planner and generator are LLM-driven, so two runs against the same app can produce different plans and different tests. That is fine at authoring time and unacceptable in a gate. And every heal is an LLM call inside CI, which means a flaky suite now has a token bill attached to its flakiness.

Governance that keeps the win

• Healer output is a pull request, never a silent commit. The locator diff gets reviewed like code, because it is code.
• Cap heals per run and per test. A test that needs healing three sprints in a row is telling you the feature is unstable or the locator strategy is wrong.
• Pin generated tests once they pass review. The generator runs at authoring time; CI runs the committed artifact, not a fresh generation.
• Log the reason for each heal with the before and after accessibility snapshot so you can audit whether the app changed or the test was brittle.
• Budget the LLM spend in CI separately from build minutes. If you route agents through MCP, the MCP primer covers the server and client split, and Claude Code with MCP is the pairing most teams will use.

The honest gap

I have not run the healer on a large production suite yet, and the per-action timings are community numbers, not something I measured. The 290 versus 536 ms comparison also says nothing about the LLM round trips the agents add. Treat the maintenance savings as plausible, measure your own heal rate before you trust it, and never let green mean more than "the locator matched."