1. It grades its own homework
The model that decided what to build is the one deciding whether the build is correct, carrying the same misreading of the ticket that caused the bug. Independent verification means a pass that did not write the code.
Comparison
Claude Code can drive a browser. Keeping it honest is the hard part.
Wiring Playwright MCP into Claude Code is a genuinely good exploratory setup — and a poor merge gate. This page is a straight account of where the DIY loop holds and where it quietly stops covering you.
What the DIY loop actually looks like
The pattern is well known by now: add Playwright MCP to Claude Code, then ask the agent to open your app and try the thing it just built.
# the setup most people are running
claude mcp add playwright npx @playwright/mcp@latest
# then, in the session
> open localhost:3000, sign in, and check the new checkout step works
claude mcp add playwright npx @playwright/mcp@latest
# then, in the session
> open localhost:3000, sign in, and check the new checkout step works
This works. Claude Code will navigate, click, read the accessibility tree, and tell you what it saw. For poking at a page while you build, it is the fastest feedback loop available, and nothing below is an argument for dropping it.
The problems start when you try to make it the thing that protects your main branch.
Keep the MCP setup for this
- Exploratory checks while you build. You are already in the session, the app is already running, and you want an answer in ten seconds.
- One-off reproductions. Walking a reported bug to see it happen is exactly what an agent with a browser is good at.
- Scraping and research tasks. Not testing, but the same tool solves it well.
- Local-only apps with no preview deployment and no auth, where the whole flow is three clicks deep.
If that describes your entire QA surface, you do not need Kery yet. Come back when the app has a login.
Six things the DIY loop cannot do
2. It only runs when asked
Every check depends on someone remembering to request it, in a session, before merging. The pull requests that break production are the ones nobody thought to check.
3. Auth is where it stops
Clerk, Supabase, Auth0, Firebase, magic links, 2FA codes, Vercel preview protection. Most agent browser sessions die at the sign-in page, which is also where the flows worth testing begin.
4. The evidence evaporates
When the context window closes, so does your proof. There is no recording to rewatch, no artifact to link in review, nothing to hand a teammate three days later.
5. Browser transcripts eat your context
Page snapshots and accessibility dumps are verbose. A long flow crowds out the code you were actually working on, and quality degrades right when the flow gets interesting.
6. There is no gate
A chat message is not a status check. Nothing blocks the merge, nothing shows up red on the PR, and nothing stops the change at 6pm on a Friday.
The comparison, without the marketing
| Claude Code + Playwright MCP | Kery | |
|---|---|---|
| Runs on every PR | No — you ask, in a session | Yes, via the GitHub App |
| Decides what to check | You describe it each time | Reads the diff and infers the claim |
| Who judges the result | The agent that wrote the code | A separate pass with no stake |
| Authenticated flows | Manual, fragile, often blocked | Clerk, Supabase, Auth0, Firebase, 2FA, magic links |
| Evidence afterwards | Chat scrollback | Video, logs, and repro context on the PR |
| Merge gate | None | Contradicted checks fail the build |
| Context cost | Snapshots fill your window | Runs out of process; returns a verdict |
| Setup | One MCP command | Install the GitHub App, or Docker locally |
| Open source | Yes (Playwright MCP) | Yes (the engine) |
The honest summary
Playwright MCP is a browser for your agent. Kery is a reviewer for your pull requests. They answer different questions, and the DIY setup only looks like a substitute until the first time something merges unchecked.
Kery speaks MCP too
You do not have to choose a workflow. Kery ships an MCP server, so Claude Code, Cursor and Codex CLI can trigger Kery runs directly and read the results back into the session you are already working in.
The practical arrangement most teams land on: Claude Code writes the change and pokes at it locally, Kery independently checks the pull request against its preview deploy and posts the verdict. One loop for building, one for proving. See Kery for Claude Code for the setup.
FAQ
Claude Code, Playwright and Kery — the usual questions.
Can Claude Code test my app with Playwright MCP?
Yes. Playwright MCP gives Claude Code a real browser it can navigate, click, and read the page from, and for exploratory work it is genuinely good. What it does not give you is a check that runs on every pull request without being asked, an independent verdict, or a recording you can rewatch a week later. Kery adds those.
Is Kery just a wrapper around Playwright MCP?
No. Kery runs on Playwright, but the product is the layer above it: reading a diff to decide what to check, signing into your app, running the flows, judging whether the change did what it claimed, and posting that verdict to the pull request with video. Playwright is the driver, not the answer.
Do I have to stop using Claude Code?
No, and most Kery users do not. Claude Code writes the change; Kery checks it. Kery also ships an MCP server, so you can trigger Kery runs from inside Claude Code and pull results back into the same session.
Why not just ask Claude Code to check its own work?
Because it is grading its own homework. The model that decided what to build is also deciding whether the build is correct, working from the same assumptions that produced the bug. A separate pass that only sees the diff and the running app has no stake in the answer.
What about the token cost of browser automation in context?
That is the practical ceiling on DIY setups. Every page snapshot, accessibility tree, and console dump lands in your context window, so long flows crowd out the code you were working on. Kery runs the browser out of process and returns a verdict plus a link, not a transcript.
Does Kery work on pull requests without CI config?
Yes. Install the GitHub App and Kery picks up each pull request and its preview deployment. There is no workflow YAML to write and no runner to maintain.
Put proof in every pull request.
Connect a repo and Kery starts checking pull requests against their preview deploys. No test scripts, no CI config.