Playwright MCP and AI agents: can they really write your tests in 2026?

Every QA Slack I'm in has the same question this quarter: *"Can I just point an AI at my app and get a test suite?"*

With Playwright MCP, the answer is finally closer to yes than no. But "closer to yes" is not "yes." I spent the last two weeks running Playwright MCP against three real client codebases — a SaaS checkout flow, a B2B dashboard, and a marketplace. Here's what happened.

What Playwright MCP actually is

MCP (Model Context Protocol) lets an AI agent — Claude, GPT, Cursor, whatever — talk to Playwright directly. The agent can:

• Open your app in a real browser
• Click, type, scroll like a human
• Read the actual DOM, not screenshots
• Write a .spec.ts file based on what it just did
• Run that test and watch it pass or fail

You give it a prompt like *"test the checkout flow for a logged-out user with an invalid card"* and it will click through your product and leave you a Playwright file in your repo.

That is genuinely new. Last year this was a demo. This year it's a tool I'm billing clients for.

The 20% that works beautifully

Smoke tests for critical paths. Login, signup, checkout — flows with clear "success" and "failure" states. The agent nails these. I had 12 happy-path tests covering a SaaS onboarding in under 90 minutes.

Writing selectors. The agent picks getByRole, getByLabel, getByText over brittle CSS selectors by default. Better than most junior engineers I've reviewed.

Boilerplate. Page Object skeletons, fixture setup, config files. All the parts that drain an afternoon — gone in 10 minutes.

Documenting flows. When I ask the agent to *explain* a test it wrote, I get a readable summary of the user journey. That alone has saved me multiple handoff meetings.

The 80% that still needs a human

Flaky selectors on dynamic UIs. Modal that animates in? Toast that disappears after 3 seconds? The agent writes a selector that works *right now* and fails on CI 20% of the time. You'll spend a day adding .waitFor() and expect.poll() in all the right places.

Business-logic edge cases. The agent will test "can the user check out?" It will not test "what happens if the user applies a 100% discount coupon on a $0.01 item while another tab is adding the same item to cart?" That's the kind of bug that costs you a Hacker News post.

Realistic test data. The agent happily hardcodes test@test.com and password123 everywhere. Shared state between tests, dirty database — your parallel runs will eat each other.

Visual regressions. MCP sees the DOM, not pixels. A button that silently moved 40px off-screen? Still passes.

Auth and permissions matrices. "What can an admin see that a free user can't?" The agent writes one test for one role and calls it done. You wanted 12.

The workflow that actually ships

After two weeks and some painful CI mornings, here's the loop I'm using on client work:

1. Human defines the flow in plain English. One sentence per test. "Logged-out user tries to checkout with an expired card and sees a specific error." 2. Agent writes the draft. It opens the app, clicks through, generates the .spec.ts. 3. Human reviews the selectors. Replace anything brittle. Add waitFor on dynamic content. Rename variables to match project conventions. 4. Agent runs the test 20 times in a row. If it passes 20/20, it goes to CI. If it flakes once, back to step 3. 5. Human adds the edge cases. The weird coupon math, the race conditions, the "what if the user is on 3G in Istanbul with a cracked screen" scenarios. The agent cannot imagine these. You can.

That workflow gets me ~3-4x faster than writing tests from scratch. It is not 10x. Anyone selling you 10x is selling you flakes-in-production.

What this means for your team

If you're a solo founder or small team: use it. Right now. The ROI on the first week is already there. You will not match a dedicated QA engineer's coverage, but you will go from "zero tests" to "the critical path is protected" in a weekend.

If you have an existing suite: don't wholesale replace. The agent is bad at reading your existing patterns and worse at not duplicating them. Use it for *new* flows, not for refactoring old ones.

If you have an existing QA team: give them MCP as a tool, not a replacement. The best use I've seen is a senior QA pairing with an agent — the agent handles the typing, the human handles the thinking. Output triples.

The uncomfortable part

A lot of "AI will replace QA" takes miss what QA actually is. The typing part — the page.click('button') part — was never the valuable part. The valuable part was asking *"what could go wrong?"* The agent cannot ask that question. It can only answer the questions you already thought to ask.

Which means AI test agents don't eliminate QA. They eliminate the *bottom half* of QA — the typing — and raise the ceiling on what one QA engineer can cover. The thinking part is still yours.

That's actually great news if you're a founder. It means a $1,500 Automation Starter with a human reviewing every test now covers 3x more surface area than it did six months ago. Same price, more protection.

Want me to set up Playwright MCP on your repo and ship your first 20 tests? Book Automation Starter — $1,500, 2 weeks, you own the suite.