Worth automating
Regression passes over known flows. Sign-in, checkout, settings, permissions, empty states, mobile layout. The same clicks, after every change, forever. This is where human attention is worst spent and machines are most reliable.
Comparison
Manual QA does not scale to agent-speed shipping.
When one engineer opens six pull requests a day, the bottleneck stops being code review and starts being the person clicking through the app afterwards.
Throughput went up; the clicking did not
Coding agents changed how much gets written, not how much gets checked. A team that used to open five pull requests a week now opens five a day, and every one of them technically needs somebody to open the app and confirm the thing works.
What happens in practice is predictable. The obvious flows get a quick look, the rest gets a shrug, and the definition of "tested" quietly becomes "the diff looked fine". The regressions that reach production are rarely subtle — they are usually a flow nobody had time to open.
What to automate, what to keep human
Keep human
Exploratory testing, judgement about whether a flow feels right, accessibility review with real assistive tech, and deciding which risks actually matter for this release. None of that is a checklist.
Kery is aimed squarely at the first column. It walks the repetitive paths on every pull request so the people who are good at the second column are not spending their week on the first.
Manual smoke testing vs. Kery
| Manual smoke test | Kery | |
|---|---|---|
| Coverage per PR | Whatever there was time for | Every PR, same standard |
| Consistency | Varies by person and by Friday | Same pass regardless of the day |
| Environment | Shared staging, often stale | That PR's own preview deployment |
| Evidence | "Looks good to me" | Video, logs, and repro context |
| Cost per run | Engineer or QA hours | Credits, in parallel with review |
| Catches novel UX issues | Yes — this is the human advantage | Partly; reported, not enforced |
Where the honesty matters
A person notices that a flow is confusing. Kery notices that a flow is broken. Both are worth catching, and only one of them should cost you an afternoon per pull request.
FAQ
Replacing the repetitive part, not the people.
Does Kery replace a QA team?
No. It replaces the repetitive part — clicking the same flows after every merge to confirm nothing obvious broke. Exploratory testing, judgement about what matters, and edge cases a human notices are still human work. Kery buys back the hours spent on regression clicking.
How is this different from a manual smoke test checklist?
A checklist runs when someone has time. Kery runs on every pull request, against that pull request's own preview deployment, and posts the result before review. It also derives what to check from the diff rather than following a fixed list that ages.
What happens when Kery is wrong?
You mark the finding as a false positive and Kery remembers. It keeps a model of your app's paths and conventions, so repeat noise drops over time. Only a contradicted check — one the browser run actively disproved — can fail a build.
Can it test flows that need real data?
Yes, against a configured environment with credentials. Kery signs in as a real user and walks the flow the way a person would, including forms, permissions, and empty states.
How long does a check take?
Runs happen in parallel with review rather than blocking it, so the verdict is typically waiting by the time a human opens the pull request.
Do we still need a staging environment?
Not necessarily. Kery runs against the preview deployment created for each pull request, which is usually a closer match to the change under review than a shared staging box.
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.