Every pull request in your repo ends the same way: a row of green checks. Lint passed. Types passed. Unit tests passed. And yet the question your reviewer actually cares about — does the feature work? — is answered by none of them. Green means your scripts ran. It says nothing about the button you added yesterday, because no script has ever heard of it.
The coverage gap AI-speed teams actually have
Teams shipping with coding agents merge features in hours. Test suites grow in weeks. That gap is where production incidents live: the checkout CTA that stopped navigating, the count badge that stopped updating, the form that silently drops a field. None of these fail a unit test, because unit tests encode yesterday's assumptions and these bugs are in today's code.
End-to-end scripts don't close the gap either. Someone has to write them, they lag the product by sprints, and they break whenever the UI breathes. The result is a strange inversion: the newest code — the code most likely to be broken — has the least coverage of anything in your repo.
Evidence-first CI: prove the change works
Kery takes a different contract with your pull request. Instead of a bug list bolted onto a green check, the check itself is a verification report. When a PR opens, Kery reads the diff, works out what the change is supposed to do, and tests exactly that on the preview deployment — clicking, typing, logging in, watching what actually happens in a real browser.
The check that comes back leads with proof, not vibes:
- A verification checklist — every claim about the change graded verified, failed, or not testable
- Cited evidence per claim — the exact steps and observed effects that decided the grade
- A full video recording of the session as proof
- Bugs found around the change, filed with screenshots and repro context
A real example from a wishlist feature: "Move to cart adds the item to the cart while leaving it in the wishlist — clicked in step 8, item still present in step 9 while only the cart count increased." That's a failed check a reviewer can act on in ten seconds, with the video one click away.
The rules that make the evidence trustworthy
An AI tester is only as good as its skepticism. The hard lessons are baked into how Kery grades every run:
- No observation, no verdict. After every click or submit, the agent must record what visibly changed. A claim without observed effects is never marked verified.
- Silent controls are failures. A button that produces no navigation and no DOM change isn't "untested" — it's broken, and it fails the check.
- The PR description is a claim, not a fact. If the description frames removed behavior as intentional, Kery still exercises the affected flow and reports what actually happens.
- Derived numbers must reconcile. Totals, rates, and counts get recomputed against the underlying data the agent saw — a dashboard can't grade its own homework.
- Inputs get probed, not petted. Searches and filters are tried with case variants, partial terms, and alternate identifiers, because that's how users type.
What it catches that scripts never will
Because Kery derives its test from the diff, it covers code written an hour ago. In practice that surfaces the class of bugs that ship most often: dead primary CTAs, counters that stop syncing, case-sensitive search, options whose saved value doesn't match what was selected, data silently dropped from a confirmation page. On brand-new features it routinely finds integration seams the author never considered — the Escape key that doesn't close a dropdown, the state that leaks across views.
Built for the modern stack
Kery Cloud connects as a GitHub App and tests Vercel preview deployments automatically, including protected previews and logged-in flows — token-based auth for Clerk, Supabase, Auth0, and Firebase, or plain email-and-password through your real login form. When authentication can't complete, the check says exactly that instead of pretending the app was tested.
The engine is open source: run it locally against any URL, wire it into your editor as an MCP tool, and inspect every step it takes. The cloud adds the PR pipeline — managed browser workers, team review, scheduled regression checks, and the verification checks described here.
Stop reading green. Start reading proof.
CI that proves your feature works is a different daily experience from CI that reports your scripts ran. Reviewers stop clicking through previews manually. Authors find out about dead buttons before the demo. And the question "did anyone actually try this?" always has the same answer: yes — here's the video.
Kery is open source at github.com/Kery-HQ/Kery, and Kery Cloud is onboarding teams from the waitlist at kery.dev.