Can AI Write Your E2E Tests? What Actually Works in 2026

You have a release going out, three critical browser tests, and no appetite for another week of locator work. You searched whether AI can write tests because the demos look convincing, but you need to know which parts survive contact with CI, test data, and a changing product.

Yes, AI can write and run useful E2E tests in 2026, through four working approaches: editor-assisted Playwright authoring, agentic generation platforms, runtime browser agents, and tests generated from recorded sessions. None removes human judgment. You still define the expected outcome, provide controlled data and environments, and decide whether a failure is product behavior or test noise.

That qualification matters. In a CloudBees survey, 92% of technology leaders expressed confidence in the production readiness of AI-generated code, while 81% reported more production issues tied to it. Those are self-reports from 213 enterprise technology leaders, collected by TrendCandy for CloudBees with a stated margin of error of plus or minus 8% at 95% confidence. They are not measured incident data. Still, the tension is familiar: generating code got cheaper faster than verifying behavior did.

The useful question is where the AI runs, what artifact it leaves behind, and who owns the hard decisions afterward. Vendor claims and package versions in this post were checked on July 12, 2026.

Four ways AI writes E2E tests

The products in this category automate different jobs. Calling all of them an AI test generator hides the most important distinction.

The first two change authoring. The third changes execution. The fourth learns coverage from observed usage. That difference determines cost, control, and which failures can be detected.

AI-assisted Playwright authoring

The most conservative answer is to let Copilot, Claude Code, Codex, or another coding agent write ordinary Playwright. You keep TypeScript, assertions, fixtures, traces, and the same CI runner. Your team still owns the suite.

Playwright now formalizes this with Test Agents in version 1.56 and later. The planner explores the app and writes a Markdown plan. The generator converts that plan into Playwright Test files. The healer runs the suite and repairs failures. As of mid-2026, the current Playwright package is 1.61.1.

Run the initializer for your editor loop:

npx playwright init-agents --loop=vscode
npx playwright init-agents --loop=claude
npx playwright init-agents --loop=codex
npx playwright init-agents --loop=opencode

The generated project puts plans in specs/, tests in tests/, and a seed test at tests/seed.spec.ts. The Claude loop also creates three agent definitions in .claude/agents/ and an .mcp.json file for Playwright MCP. The official docs say to regenerate those definitions after upgrading Playwright.

This automates exploration, first-draft coverage, repetitive interactions, and some repairs. It leaves reviewable code in the framework you already use.

The cost is still code ownership. A generated locator can be wrong. A plausible assertion can verify the wrong business outcome. The healer may produce a passing test, or skip a test when it believes the feature itself is broken, according to the official behavior. A human has to review that skip instead of treating green CI as proof.

A known Playwright MCP issue tracks large accessibility snapshots inflating context. Token use and review time can erase part of the authoring gain. Our guide to Playwright MCP with Claude Code covers that trade-off.

Agentic generation platforms

Agentic platforms take on more of the lifecycle. Instead of asking a general coding assistant to produce a test, you give a testing product your application, tests, or code changes. It creates tests, runs them, and attempts repairs.

Momentic stores human-readable YAML in your repository. Steps can express actions such as adding a backpack to a cart and going to checkout, with click: and assert: prefixes rather than selectors. Its CLI can explore a diff with momentic ai explore, generate new tests, and run them in CI with momentic run anywhere Node.js runs.

This automates test construction and locator selection while keeping a reviewable artifact in Git. The trade-off moves from engineering time to platform credits. Momentic pricing lists 2,000 monthly credits on the free plan, about 200 typical runs, and a $125 monthly plan with 10,000 credits, about 1,000 typical runs. AI actions, failure recovery, and auto-heal consume step credits. Maintenance has not disappeared. It has become metered.

Checksum takes a different ownership position. It generates Playwright tests that land in your repository, so the output is code your team can inspect and run. The company says teams can bootstrap 100 to 150 tests in their first week and that about 70% of failures self-resolve without human involvement, with healing changes opened as pull requests. Those are Checksum’s own claims, not independent measurements. The second number also gives the honest boundary: about 30% do not self-resolve by their account.

These platforms suit teams that want broad initial coverage and accept a vendor workflow. Someone still needs to review intent, approve repair PRs, and stop the suite from preserving accidental behavior.

Runtime AI execution

With runtime execution, an agent decides how to act on the current page. This handles interfaces where selectors or wording change often, but introduces model cost and probabilistic decisions.

Stagehand 3.6.0 is an MIT-licensed TypeScript framework for choosing when to use code and when to use instructions. Its act() API performs one action and returns whether it succeeded, a description, and the concrete actions it took. The Stagehand act documentation says it handles iframes and shadow DOM and supports caching. Multi-step work belongs in agent() instead.

tests/checkout.ts

await stagehand.act("click the checkout button");

await stagehand.act("type %password% into the password field", {
  variables: { password: process.env.TEST_PASSWORD ?? "" },
});

const agent = stagehand.agent();
await agent.execute({
  instruction: "Complete checkout and confirm the receipt appears",
  maxSteps: 30,
});

Variables use %name% substitution so sensitive values remain hidden from the model. The agent API defaults to 20 steps and reports token and inference usage. The test can adapt during a run, but is no longer fully described by deterministic TypeScript.

Smoketest uses the same broad mechanism at a higher level. A test is a Markdown description with sequential actions and an explicit expected outcome. The agent runs it in a real browser and returns pass, fail, or inconclusive based on what it observes.

tests/signup.md

## Signup
- Open the signup page
- Enter a test email
- Submit the form
- Verify the onboarding checklist appears

This automates execution and interpretation, not product intent. “Test signup” is underspecified. “Verify the onboarding checklist appears” defines success. An agent cannot infer which post-signup state your business promises.

Session-replay generation

Session-replay generation starts with what people actually do. Meticulous asks teams to add a script to local development, staging, and preview environments, records sessions, then derives a suite from those interactions. It saves and replays backend responses so generated tests run without causing the original side effects.

That can produce wide frontend coverage. Meticulous says its deterministic scheduler eliminates flakes and thousands of screens run in under 120 seconds. Those are vendor claims. It has no public pricing.

Replaying backend responses verifies the frontend against recorded data. It cannot tell you that today’s payment API, authentication service, webhook, or database write works. It is frontend regression coverage, not a replacement for live checks across real dependencies.

Session-derived tests also reproduce observed paths. A critical recovery test that no recorded user triggered may never enter the generated suite. Humans still decide which unobserved risks deserve explicit coverage.

What AI still cannot decide for you

Across all four approaches, three jobs remain stubbornly human.

First, assertion intent. A model can assert that a page loaded because that is visible and easy. Your actual requirement may be that the invoice total includes a newly purchased seat, the account gained the correct entitlement, and a confirmation email was sent once. Those outcomes come from product rules, not the DOM.

Second, test data and environments. Someone must create accounts in known states, choose payment sandboxes, rotate secrets, isolate parallel runs, and clean up records. AI cannot decide whether a shared tenant is safe to mutate.

Third, flake triage. A healer can change a locator, retry, or skip a suspected product failure. A timeout might be test noise, a slow dependency, or a real regression. The release decision still needs evidence and an accountable person.

The practical goal is not zero human involvement. It is to spend human attention on intent and diagnosis instead of transcribing browser steps.

Which approach fits your team

Hybrids are normal. A Playwright team can use an editor agent for most coded tests, Stagehand for one dynamic surface, and a small set of live runtime tests for checkout. The right boundary is the one your team can debug at 2 a.m.

For a broader product comparison, see our guide to the best AI testing tools. If your suite keeps growing while release confidence does not, the issue may also be where E2E fits in your strategy, not which generator you picked. We cover that in why the testing pyramid is wrong for startups.

Where Smoketest fits

Disclosure: we build Smoketest, so judge this entry accordingly. Manually writing Playwright with an editor agent works well when your team wants to own test code. It stops being a good use of time when a lean team only needs its money-critical tests checked in a real browser, with explicit outcomes, recordings, and results, but no one can keep another coded suite current.

FAQ