Claude Code builds it. Kery test-drives it.
The bottleneck in agent-assisted development stopped being how fast code gets written. It is how quickly anyone can confirm the change actually does what it says.
Claude Code can open more pull requests than you can click through
A good session produces real work — three or four pull requests, each touching flows you have not personally opened in a browser for weeks. The diff reads fine. It usually is fine. The question is what happens on the tenth one, on a Friday, when you skim instead of check.
Asking Claude Code to verify its own change does not close that gap. It is working from the same reading of the task that produced the code, which means a misunderstanding at the start survives all the way through the check.
Write with the agent, verify with something else
- Claude Code opens the pull request the way it already does.
- Kery reads the diff and works out what the change is claiming — a new checkout step, a fixed validation error, a redesigned settings page.
- It signs into the preview deployment for that PR, including Clerk, Supabase, Auth0, Firebase, 2FA codes, magic links, and Vercel preview protection.
- It walks the flow in a real browser and records the whole thing.
- It posts each check back to the PR with a verdict and a video that seeks to the deciding step.
Only a contradicted check fails the build — a claim the browser run actively disproved. Everything else is reported so your merges do not get blocked on a maybe.
Kery from inside Claude Code
If you would rather stay in the terminal, Kery works as an MCP server. Add it once and Claude Code can start runs, look at route coverage, and read results without you switching context.
claude mcp add kery -- npx -y @kery/mcp
# then, in the session
> use kery to check the signup flow on this branch
Exact install commands live in the GitHub repository, alongside the Docker setup for running the whole engine locally.
What to hand to which
| Task | Claude Code | Kery |
|---|---|---|
| Writing the change | Yes | No |
| Poking at it locally | Yes, fastest loop available | Optional, via MCP |
| Checking every PR unprompted | No | Yes |
| Independent verdict | No — same assumptions | Yes — separate pass |
| Durable evidence | Chat scrollback | Video and logs on the PR |
Running Kery alongside Claude Code.
How do I test code that Claude Code wrote?
Let something other than Claude Code check it. Kery reads the resulting pull request, works out what the change claims to do, runs those flows in a real browser against the preview deployment, and posts a verdict with video. The agent that wrote the change has no say in whether it passed.
Does Kery work as an MCP server in Claude Code?
Yes. Kery ships an MCP server, so you can start browser checks, inspect route coverage, and pull results back into the session you are already working in.
Should I use Kery instead of Playwright MCP?
They solve different problems. Playwright MCP is a browser your agent can drive while building. Kery is an independent check that runs on every pull request whether or not anyone asks. Plenty of teams run both.
Do I need to write tests or acceptance criteria first?
No. There is no script, no ticket, and no acceptance criteria to fill in. Kery infers the intent of the change from the diff itself.
Which model providers does Kery use?
OpenAI, Anthropic, Google Gemini, and OpenRouter. Running the open-source engine locally, you bring your own provider keys.
Will it slow down my Claude Code loop?
No, because it is not in the loop. Checks run out of process against the pull request's preview deployment while you carry on working, and the result lands on the PR.
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.