Everyone Open Sourced the Hands This Year. Nobody Open Sourced the Check
Disclosure first, because it matters for how you read this. I work on a product in the verification half of this, so I have a stake in the argument. I have tried to make the case in a way that survives you disagreeing with the conclusion.
Look at what actually shipped over the past year. Tool loops, sandboxes, permission prompts, session state, subprocess providers, plugin trees, sub agent scheduling. DeepSeek published an agent runtime this month and it collected more than a hundred thousand stars inside a week. All of that work is about the body.
None of it makes the code correct, and I think people are assuming a connection between the two that does not exist.
The failure that survives all of it
Here is a real change that came up recently. A developer asks an agent to add a nullable canceled_at field to the subscription model and stop counting cancelled subscriptions in monthly revenue. The request is small, clear and well specified.
The agent opens the billing service, finds the revenue calculation, adds the field, updates the sum, and writes a test. The test passes and the diff looks perfectly reasonable. A reviewer approves it in about four minutes.
It is a production incident, because a mobile client in a different repository decodes the same payload strictly, and an unknown field fails the parse.
Now ask which part of an agent runtime was supposed to catch that. The sandbox was fine, since nothing dangerous was executed. The permission model was fine, since the agent only wrote to files it was allowed to touch. The session log recorded everything faithfully, including the fact that nobody ever opened the mobile repository. Every layer did exactly its job.
The tests passed because tests live in the repository that changed, and repositories do not test each other. Code review catches this only if the reviewer happens to remember that the Kotlin client is strict, which is knowledge that lives in one person’s head and leaves the company when they do.
Why this got worse rather than better
Nobody was checking changes against other repositories before agents existed either. This is an old problem.
What changed is volume and friction. Teams are writing several times more code than two years ago and review capacity did not move. One company I spoke to generates around a thousand pull requests a week from agents, with roughly a third still needing a human to look properly. That third is a lot of senior engineer afternoons.
The friction point matters more. A human writing that change slowly would occasionally stop and think about who else consumes this payload. Not reliably, and not always, but sometimes. An agent never wonders, because wondering requires knowing that the other repository exists, and nothing in its context ever mentioned it.
Agents did not create the problem. They removed the last accidental thing that was partially hiding it.
The evidence I find most convincing
Three things, and only one of them is about my own product.
The first is a benchmark footnote. DeepSeek reported V4-Pro scores of 87.9 on Terminal Bench 2.1, 74.1 on Toolathlon-Verified and 71.1 on DSBench-FullStack, all tested using their harness in minimal mode. Those are not pure model numbers. A frontier lab is publishing agent results where the software layer is part of the measurement, which is a quiet admission that the wrapper moves the score.
The second is what the accompanying paper covers. DeepSeek and Peking University published roughly 88 pages of formal proofs about component composition, with theorems on whether a plugin system converges to the same state regardless of load order. It is rigorous work and it is entirely about the plumbing. There are zero pages about whether the code that comes out the other end is right. That is not a criticism of a paper on composition, and it tells you where the field’s attention sits.
The third is that same paper’s motivating use case, which is a self evolving agent harness where future agents generate and deploy modifications to their own components while continuing to serve requests. Read that and then ask who certifies the output. An agent that rewrites its own tooling at runtime cannot be the thing that certifies its own work, for the same reason you do not let a compiler grade its own optimiser.
The obvious counterarguments
I want to take these seriously rather than knock them over, because two of them might be right.
“Models will just get good enough.” Possibly. But the failure above is not a reasoning failure. The model reasoned correctly about everything it could see, and the missing information was in a repository nobody opened. A smarter model with the same context makes the same mistake with more confidence. This gets solved by giving it the information, not by improving the reasoning.
“Types and contract tests already solve this.” In a monorepo with strict typing across service boundaries, largely yes, and if that is your setup you probably do not need any of this. Most large organisations are not that. They are forty languages, a hundred repositories, three generations of internal SDK, and a service that consumes a payload over HTTP with no shared type at all.
“The runtime vendors will add it.” They might, and it is the risk I think about most. My guess is they will not prioritise it, because their revenue is billed in tokens and verification cuts token use sharply. Asking a company to ship the feature that shrinks its own meter is asking a lot. I could be wrong about that, and if I am, they have distribution I cannot match.
What a check actually needs
A generator needs the files relevant to the task. A check needs something different, which is a durable statement of what every file promised before the change arrived.
That has to be derived from the code rather than from documentation, because documentation is wrong. It has to cover repositories nobody is currently working in. It has to be cheap enough to run on every change rather than only the frightening ones. And it has to sit outside the agent, because a thing cannot verify itself.
None of those four requirements are satisfied by a better runtime, no matter how good the runtime gets.
The limitation in my own argument
The check I am describing can only cover repositories that have been indexed, and an unindexed repository is a silent blind spot rather than a loud one. You get confident answers about the half of your system that was read and nothing at all about the rest, which looks identical to success.
So the first question to ask anyone selling verification, including me, is what happens when the dependency lives somewhere the tool has never looked. If the answer is not a clear statement about coverage, you are being shown a search engine wearing a review badge.
Where we have got to on our side
This is the problem ByteBell works on, and the honest version of our answer to that question is the one I would want asked of us.
We read your repositories once and turn them into a verifiable context layer for code: intent, contracts and cross repository dependencies written out in plain language, with the file and the line kept on every claim. It is derived from the code rather than from documentation, it is indexed once and queried forever rather than rebuilt per task, and it sits outside the agent, so a change gets checked against what the rest of the system was promised rather than against what the model remembers. Forty six Kubernetes repositories, about a hundred and fifty thousand files, roughly eight gigabytes, served over one MCP url and updated per file by SHA-256 diff.
And coverage is a number we will show you rather than a claim. A repository that has not been indexed is reported as not indexed, not answered from vibes. The mobile client in that incident is only caught if somebody pointed us at the mobile client, which is a much less impressive sentence than the ones usually written in this slot, and it is the only kind of sentence a check is allowed to make.