Playwright now ships AI agents in the box — a planner that explores your app, a generator that writes verified tests, a healer that repairs failures — and Cypress ships self-healing as cy.prompt. This module teaches you to run that stack with human gates at every stage, because the healer's signature failure is a test that passes while the feature is broken.
The structural shift is easy to miss: agentic testing is no longer a paid-platform pitch. Playwright's test agents and its official MCP server are first-party open source; Cypress's cy.prompt self-healing ships from the framework vendor; Healenium has done open-source self-healing for Selenium for years. When the agents live in the core tools every SDET already runs, "should we adopt AI agents?" stops being a procurement question and becomes an engineering-discipline question — and supervision, not operation, becomes the durable skill.
Ananya's team adopts the Playwright agent loop: npx playwright init-agents --loop=vscode. The planner explores the storefront and writes a Markdown test plan into specs/. It is impressive — and wrong in both directions: eight scenarios for the marketing carousel nobody tests, nothing at all for coupon stacking, the feature that burned them last quarter.
She edits the plan — deletes the carousel padding, writes the coupon scenarios herself. The generator turns the edited plan into tests, verifying each step against the live app as it writes. The suite is real, reviewed, and hers.
A frontend redesign renames data-testids across checkout. Fourteen tests fail. The healer proposes patches for all fourteen. Thirteen are correct locator updates. She almost merges the batch.
Patch nine: the "Apply coupon" button no longer exists — the redesign accidentally dropped it. The healer, built to make tests pass, retargeted the test to the adjacent "Apply gift card" button, which is superficially similar. The test would go green. The feature is broken. Her diff review catches it: the heal changes which behavior is under test, not just which selector finds it.
The team writes the rule into their workflow: every heal is a proposed change, reviewed like a PR; any heal that alters the acted-on element's role or accessible name is escalated as a probable product bug. Patch nine becomes defect SHOP-2214 — found by a heal review, not hidden by a heal.
That is the whole module in one incident: the agents are genuinely useful, the plan needed a human editor, the generated tests needed review, and the healer needed an auditor — because its objective function is "make the test pass," and a passing test is not the same thing as a working feature.
Playwright's agent architecture is deliberately staged, and the stages are where your judgment plugs in. Each agent's output is an artifact you can read, edit and version — that reviewability is the design's best feature, and skipping it is the design's easiest abuse:
specs/. Expect over-scoping on visually prominent, low-risk surfaces and under-scoping on high-risk logic invisible in the UI — the planner sees the app, not the risk history. Gate: edit the plan. The plan is a draft from a sharp junior who started yesterday; your product knowledge is exactly what it lacks.The agents share one property — they optimize for a plausible, passing suite. Only the human in the loop optimizes for a suite that fails when the product breaks. That asymmetry is why the gates are not optional ceremony; they are where the quality enters.
The Model Context Protocol server for Playwright gives an LLM structured control of a live browser: navigate, click, type, read. The key design choice — it operates on accessibility-tree snapshots, not screenshots — means the model reads the page's semantic structure (roles, names, states) rather than guessing at pixels, which makes its actions precise and its observations quotable. Three uses earn a place in your week:
The same honesty applies as everywhere in this track: an MCP browser session is a capable junior tester with no memory of your last release and no model of your users. Sessions that start from a written charter and end in verified findings are productive; unsupervised "go test my app" sessions produce confident noise.
Every self-healing tool works roughly the same way: when a locator fails, score candidate elements against the original's remembered fingerprint (attributes, position, text, role) and re-target to the best match. Healenium does this for Selenium with a backend that stores locator history; cy.prompt brings it to Cypress with every healed step visible in the command log; Playwright's healer proposes patches at the agent layer. The vendor pitch is maintenance reduction, and it is real — locator churn is a genuine tax, and most heals are correct.
The curriculum is the case the pitch omits. When the UI changed because the feature broke, the best-matching surviving element is precisely the wrong target — and re-targeting converts a failing test into a passing one without anyone deciding that should happen. The demo shows the renamed button healing correctly; it does not show the removed button healing onto its neighbor. Ananya's patch nine is not an edge case; it is the statistically inevitable outcome of running heals unreviewed at scale.
The button still exists, does the same job, reads the same to users — the redesign renamed its test-id. The heal updates the locator; role and accessible name are unchanged; behavior under test is identical. Approve, and thank the robot for the fifteen minutes back.
The button is gone — the feature regressed. The healer re-targets a lookalike element; the test goes green; the defect is now invisible to the suite that existed to catch it. The only defense is a human reading the diff and asking: did the behavior under test change?
The governance workflow that makes healing safe is the audit queue — every heal is a proposed change with the same lifecycle as a code change:
"The healer patched the test and it now passes — what do you do?" has one scored answer shape: review the diff, check whether the acted-on element's role and accessible name are unchanged, and treat any behavioral retarget as a candidate product defect. "Accept, the suite is green" is the planted wrong answer.
The honest adoption question is not whether the stack works — it does — but where it pays. A decision table for the team lead:
| Situation | Agent leverage | Why |
|---|---|---|
| Coverage gap on a stable, well-understood app | High | Planner + generator produce reviewable coverage fast; low churn keeps heal volume low |
| Repro hunting and exploratory sweeps | High | MCP sessions excel at directed drudgery; findings are human-verified anyway |
| Locator churn on high-frequency UI change | Medium | Healing pays only with the audit queue staffed; unreviewed it is a bug-masking machine |
| Complex business-logic assertions | Low | Agents verify steps run, not that the right thing was asserted; human-authored asserts dominate |
| Team cannot yet review generated code well | Negative | Output volume exceeds review capacity — the repo fills with tests nobody understands |
The last row is the Ananya fear from this track's research, and it is the real adoption risk: agents raise the production rate of tests; they do nothing to raise your comprehension rate. A suite you cannot explain is a suite you cannot trust in an incident, whoever wrote it. The disciplines that hold the line: agents work from plans humans edited; everything merges through review; heal audits are staffed like a rotation, not "when someone has time"; and if review capacity saturates, you throttle generation — never review.
The agentic test stack is real, first-party and worth adopting — as a pipeline of proposals, not a pipeline of facts. Edit the planner's plan, review the generator's assertions, and audit every heal with one question — is this the same behavior? — because the healer's job is to make tests pass, and yours is to make sure passing still means working.
npx playwright init-agents against a demo or staging app, read the generated plan in specs/, and mark every over-scoped scenario and every risk area it missed before touching the generator.Take this into Lab 02 (exploratory session with Playwright MCP), Lab 03 (planner → generator → healer pipeline) — where one healer patch is correct and one masks a seeded bug — and Lab 05 (self-healing governance), which you fail if the wrong heal lands. Companion playbooks: pb-15 through pb-18.