Agents turned software delivery into a production line. The part that confirms the output actually works is still a person opening the app when they have a spare twenty minutes.
For twenty years the constraint on shipping was how fast people could write code. Every tool worth buying attacked that constraint — frameworks, CI, platform teams, and finally agents that write the change for you.
It worked. The constraint moved. A team that used to open five pull requests a week now opens five a day, and the thing standing between those changes and production is the same thing it was in 2015: a reviewer reading a diff, and somebody clicking through the app if there is time.
That is the shape of the problem. Production got industrialised. Proof did not.
It helps to be precise about which layer does what, because the argument for a verification layer is that the other three structurally cannot cover it.
| Layer | Question it answers | Status in most factories |
|---|---|---|
| Generation | Can we produce the change? | Solved, and then some |
| Review | Is the code sound? | Automated and human, working |
| Verification | Does the product do what the change claimed? | Manual, sampled, or absent |
| Release | Can we ship it safely? | Solved — flags, canaries, rollback |
Three of those scale with volume because they are machine work. Verification is the one still priced in human attention, which is why it is the first thing dropped when the line speeds up.
A reviewer reads what the code says it will do. That catches bad abstractions and unsafe queries. It cannot catch a flow that breaks in a browser, because the diff does not contain that information — no amount of reviewer skill extracts it.
A suite checks the properties somebody predicted mattered, at the time they wrote it down. That is valuable and worth keeping. It is also a fixed asset depreciating against a codebase that now changes faster than the suite is maintained.
Review and tests both work from a description of the software. Verification works from the software. When output volume rises, only the second one scales, because it does not require anyone to have anticipated the change.
Not every automated check qualifies. A verification layer that fails any of these degrades into noise, and a noisy gate is worse than none — teams disable it and lose the signal entirely.
Kery occupies exactly that layer. It reads a pull request, works out what the change is claiming to do, signs into the preview deployment built for it, walks those flows in a real browser, and posts a verdict with video of what actually happened.
It does not need a suite, because the checks come from the diff. It does not need CI configuration, because it runs off the GitHub App. And it fails a build only on a contradicted check, so it stays switched on — which is the property that decides whether a verification layer exists in six months or was quietly disabled in week three.
The practical starting point is one repository and one pull request. See what a check posts back, or how this compares to what you run today.
A delivery setup where shipping software is an industrialised, repeatable pipeline rather than a series of hand-built releases. The term is borrowed from manufacturing and has been used in enterprise and defence delivery for years. It has been revived because coding agents finally made the production line real: code now arrives faster than any team can hand-inspect it.
The stage that answers whether a change actually does what it claims, by observing the running software rather than reading the source. It is distinct from review, which inspects intent, and from tests, which check the properties someone thought to write down in advance.
Review verifies the code. It cannot verify the product. A reviewer reading a diff has no way to know that the submit button now sits behind a modal, that the redirect loops for signed-out users, or that the empty state renders blank. Those are facts about a running browser, and they need one.
They cover the assertions someone wrote in advance, which is exactly the thing that does not scale with agent output. When a factory produces changes faster than people can author tests, coverage drifts further behind every week. A verification layer derives what to check from the change itself.
No. It replaces the repetitive regression pass after every merge. Exploratory testing, risk judgement, and deciding what actually matters for a release stay human — they are the parts that were always underserved when QA time went on clicking through the same flows.
By setting a deliberately high bar for stopping a release. Kery fails a build only on a contradicted check — a claim the run actively disproved. Everything else is reported for a human to weigh. A gate that fires on uncertainty gets switched off, which leaves you with no layer at all.
Connect a repo and every pull request gets checked against its preview deployment, with video of what actually happened.