Kery Shows PR Features Working

Kery is Kery-HQ’s open-source project for testing web-app pull requests with an AI agent that drives a real browser. It deals with a very specific pain: agent-written code can pass review and still break the UI. The useful takeaway is simple: pair code review with evidence from the running app, especially when Cursor subagents and skills are changing front-end behavior.

Kery is an evidence layer for AI-written web changes: it reads the change, exercises the app in a browser, and reports whether visible claims are verified or contradicted. Cursor, Anysphere’s AI code editor, already gives developers strong reviewable workflows through agents, cursor rules, and IDE context. Kery is interesting because it moves part of the review from “does the diff look right?” to “did the feature actually appear on screen?”

Start with the Show HN problem

The Show HN pitch landed because the problem is now familiar. A developer can have several AI coding sessions running at once, often across different worktrees, and the first reliable signal that something broke may be a failed deployment, a QA pass, or production noise.

The author described shipping code through agents such as Claude Code, Anthropic’s coding agent, and Codex, OpenAI’s coding agent. They were already using code-level PR review, but that still missed UI and UX failures. A review can catch a bad import and still miss the “entire section rendered orange” kind of bug.

That is the gap Kery is trying to sit in. It reads the PR and its description, generates checks, drives the preview app, and produces visual evidence. The repository README describes verdicts like verified or contradicted, backed by annotated screenshots where the relevant element is boxed and the expected-versus-observed result is shown.

The Show HN title emphasized a PR comment with a video of the feature working. The repository’s current public framing, as of August 2026, is broader: AI agents that test a web app and prove what works with annotated screenshot evidence. That distinction matters. The durable idea is not “add another bot comment.” It is “make the browser run part of the review.”

Why developers cared about the evidence

Kery’s trick is not that it replaces tests. It removes some of the ceremony around first-pass UI verification.

Traditional end-to-end tests are precise, but someone has to write selectors, keep them stable, and decide which paths deserve coverage. Kery’s pitch is that it can infer checks from the PR itself, then use a real browser to inspect the result. That is a tempting fit for agent-generated changes, where the shape of the work can be wide and a little unpredictable.

A concrete example: imagine a PR says “Add billing plan badges to the account settings page.” A code reviewer can inspect the component and the data mapping. Kery’s more useful question is whether the preview page actually shows the badges where a user would look for them.

The trap is treating visual evidence as correctness. A screenshot can prove that something appeared. It cannot prove the billing rules are right, that accessibility is complete, or that the backend state transition is safe. Evidence is strongest when it is attached to a clear claim, not when it is asked to bless the whole PR.

Use it where Cursor review stops at the diff

Cursor users already have a natural place to define review boundaries. Put durable expectations in Cursor rules, keep repo-specific constraints in an AGENTS.md, and let specialized agents or skills handle repeatable review work. If you are mapping that world, our topic page on Cursor subagents and skills is the right companion.

Kery fits best after the code has landed in a preview environment and before a human reviewer gives the final “looks good.” That is when the diff is available, the app can be opened, and the PR’s claims can be turned into observable browser checks.

Here is the useful mental boundary:

This is also where a related pattern shows up: browser automation is becoming a review surface, not just a test surface. We saw the same pressure in brave-devtools-mcp Connects Brave to Agents, where the browser becomes something an agent can inspect instead of something humans must manually replay.

Try Kery safely on one PR

Do not start by asking Kery to validate every web change. Pick one UI-heavy PR with a clean preview URL and a description that says what should be visible.

Use a small Cursor rule to keep the experiment honest. This gives your agent a boundary: Kery evidence can inform review, but it does not replace tests, accessibility checks, or human product judgment.

---
description: Use Kery evidence only for UI-visible PR claims
alwaysApply: false
---

When reviewing a web UI PR:

- First identify the user-visible claims in the PR description.
- Ask for browser evidence only for claims that can be observed in the preview app.
- Treat Kery screenshots or video as supporting evidence, not approval.
- Still require existing unit, integration, accessibility, and security checks.
- If evidence contradicts the PR claim, ask for a fix or a narrower claim.

A safe first run looks like this:

• Choose a PR that changes one flow, such as signup, settings, checkout, or onboarding.
• Make sure the PR description states the expected UI behavior in plain words.
• Run Kery against a preview environment, following the project’s README quick start.
• Compare each verified or contradicted result to the PR claim.
• Leave a human review note that says what the evidence proves and what it does not prove.

The trap is giving the tool vague work. “Test the dashboard” is mush. “Verify that the billing page shows the Pro badge after selecting the Pro plan” is something a browser agent can actually investigate.

When Kery is overkill

Kery is a better fit for web apps with meaningful UI state than for libraries, CLIs, data jobs, or backend-only services. If the change cannot be observed in a browser, the evidence layer will not add much.

It is also overkill when a deterministic test already covers the exact behavior cheaply. If a Playwright test catches the regression in five seconds, keep the Playwright test. Kery is more interesting for exploratory PR evidence, smoke checks, and agent-written UI work that has not yet earned a permanent test.

There is another practical limit: Kery depends on an LLM provider and browser automation. That means cost, flakiness, and environment setup matter. As of August 2026, the public repository is mainly TypeScript, Apache-2.0 licensed, and early enough that readers should treat it as something to inspect and trial, not a boring mature dependency.

Common questions

• Does Kery replace Cursor rules?

  No. Cursor rules describe how the agent should work inside your repository; Kery checks whether a web-app change behaves visibly in a browser. A good setup uses rules to define review expectations, then treats Kery evidence as one input in the PR review.

• Can Cursor subagents use Kery evidence?

  Yes, conceptually. A Cursor custom agent or subagent can be given a review job that asks for user-visible claims, then compares Kery’s verified or contradicted evidence against those claims. The important caveat is that the agent should summarize the evidence, not silently approve the PR.

• Is Kery just another end-to-end test framework?

  No. Kery is closer to AI-assisted browser verification than a classic scripted E2E framework. The README’s pitch is “no selectors to write” and evidence generated from the PR, while traditional E2E tests are explicit scripts you maintain over time.

• When should I try it on a real project?

  Try it when a PR changes a visible web flow and already has a preview URL. A good first candidate is a contained UI change with three to five observable claims, because you can quickly compare Kery’s evidence with a human reviewer’s expectations.

• What should I not trust it to catch?

  Do not trust it to catch everything behind the screen. Business logic, authorization, data migration safety, accessibility depth, and security review still need their own checks. Kery’s strongest artifact is visual proof for a specific claim, not a full correctness certificate.

Best ways to use this research

• Best for: Cursor users reviewing agent-written web UI changes where the diff looks plausible but the browser outcome still needs proof.
• Best first artifact: Add a small .mdc review rule that says when browser evidence is useful and when normal tests still win.
• Best comparison angle: Compare Kery against your existing PR review flow, not against your whole test suite. The question is whether it catches UI regressions earlier.
• Best practical next step: Pick one PR with a preview URL, run Kery from its source instructions, and record which claims were verified, contradicted, or still unproven.

Further reading

• Cursor — Agent
• Cursor — Rules
• Kery — source

Try one evidence-backed review

Pick one active UI PR and write down the user-visible claims before you run anything. Then use Kery as a browser evidence pass, and let Cursor keep the review disciplined with a small rule that says exactly what that evidence can and cannot prove.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.