In this article, we will look at how code verification works, why the rise of AI-generated code puts more pressure on it, along with the extremely useful insights from Andrea on what the future may look like.
Exactly. As AI makes code generation faster, verification becomes the harder constraint.
I built two skills for that:
oleg-koval/agent-skills/lekker-review : Adversarial, evidence-backed GitHub PR reviews with specialist agents, finding verification, and proof-of-bug tests.
oleg-koval/agent-skills/self-critique : Red-teams an assistant’s answer against live sources, finds missed issues, and iterates until the result is trustworthy.
Together, they help close the gap between “the AI generated code” and “we have enough evidence to ship it.”
The reviewer who LGTMs a 5,000-line PR isn't hypothetical, it turns out. Separate research tested exactly that mechanism this month: single-PR review catches roughly 50-60% of injected malicious changes, but batch the same review to 24 PRs at once and detection drops to 16-22%. Volume doesn't just strain attention, it cuts detection to roughly a third of its single-PR rate.
That's a sharper version of the METR point you cite. The 19% slowdown is the cost of doing verification properly; the batching result is what happens when teams don't have the time budget to pay it and compress review instead. The dial you describe at the end is less a choice between static and dynamic checks and more a choice about how much attention any single change gets before someone already decided to route it that way.
I run an e-commerce business on about sixty AI agents, and the part of this I'd push further is the trust gap. We wrote a mutation audit that breaks each of our safety checks on purpose and re-runs it. Three of ten guards stayed green while their underlying check was broken. That's the part DORA and METR don't capture: verification isn't just slower, it can be actively wrong while looking fine. In AI code the pass case is cheap and the fail-closed case is the whole job.
Leaving aside the philosophical part of the problem ("who gets to verify the verifier"), working on both sides of the fence, as a researcher in formal methods for a very long time, and a mobile developer in industry, I would say that verification at a level good enough so that companies can invest in incorporating the existing approaches (or developing new in-house product specific approaches) does not exist. There is a fundamental disconnect between what the academia preaches (toy or small scale problems with interesting theoretical outcomes) and what the industry needs. The current monetization is achieved almost always by relaxing the trust-worthiness of the techniques (e.g. run-time verification vs model checking) so that they have a hope to scale to what the industry needs.
I do agree that the current AI-slop driven development is not tenable and something has got to give, but we are a long way from actually implementing fundamental changes in the current development cycle.
This really resonates. One thing I keep thinking about with AI-assisted development is how quickly the verification stack is growing.
We have tools for static analysis, testing, code review, security, observability, and now AI-based tools layered on top of all of that. Each one is useful, but we're ending up with a lot of different signals coming from different points in the development lifecycle.
At some point, I think the question becomes: do we really need another tool, or do we need one place that understands reliability across the whole application lifecycle?
That's the problem we're trying to tackle with Tomosu.
Instead of adding another point solution to the stack, we're building Tomosu as an end-to-end reliability layer — looking at the application during development, identifying potential production reliability issues, helping engineers fix them, and then connecting that back to what actually happens in production.
The idea is pretty simple: rather than stitching together a bunch of tools and trying to piece together what they all mean, have one system focused on the reliability of the application as a whole.
I think this becomes even more important as AI makes it possible to generate and change code at a pace that our existing verification processes weren't really designed for.
The goal isn't more tools. It's better, more unified visibility into whether the software we're building will actually hold up in production.
Nice & very informative article.
Btw there's an error in your confusion matrix, it should be true negative & true positive in the first row of it.
Thank you Sahil. Fixed.
Verification is the constraint under AI codegen. The investment question is still which systems still work when the demo breaks.
Exactly. As AI makes code generation faster, verification becomes the harder constraint.
I built two skills for that:
oleg-koval/agent-skills/lekker-review : Adversarial, evidence-backed GitHub PR reviews with specialist agents, finding verification, and proof-of-bug tests.
oleg-koval/agent-skills/self-critique : Red-teams an assistant’s answer against live sources, finds missed issues, and iterates until the result is trustworthy.
Together, they help close the gap between “the AI generated code” and “we have enough evidence to ship it.”
Powerful insight, We may not read all the code anymore, but the test process should get even stronger
The reviewer who LGTMs a 5,000-line PR isn't hypothetical, it turns out. Separate research tested exactly that mechanism this month: single-PR review catches roughly 50-60% of injected malicious changes, but batch the same review to 24 PRs at once and detection drops to 16-22%. Volume doesn't just strain attention, it cuts detection to roughly a third of its single-PR rate.
That's a sharper version of the METR point you cite. The 19% slowdown is the cost of doing verification properly; the batching result is what happens when teams don't have the time budget to pay it and compress review instead. The dial you describe at the end is less a choice between static and dynamic checks and more a choice about how much attention any single change gets before someone already decided to route it that way.
I run an e-commerce business on about sixty AI agents, and the part of this I'd push further is the trust gap. We wrote a mutation audit that breaks each of our safety checks on purpose and re-runs it. Three of ten guards stayed green while their underlying check was broken. That's the part DORA and METR don't capture: verification isn't just slower, it can be actively wrong while looking fine. In AI code the pass case is cheap and the fail-closed case is the whole job.
Leaving aside the philosophical part of the problem ("who gets to verify the verifier"), working on both sides of the fence, as a researcher in formal methods for a very long time, and a mobile developer in industry, I would say that verification at a level good enough so that companies can invest in incorporating the existing approaches (or developing new in-house product specific approaches) does not exist. There is a fundamental disconnect between what the academia preaches (toy or small scale problems with interesting theoretical outcomes) and what the industry needs. The current monetization is achieved almost always by relaxing the trust-worthiness of the techniques (e.g. run-time verification vs model checking) so that they have a hope to scale to what the industry needs.
I do agree that the current AI-slop driven development is not tenable and something has got to give, but we are a long way from actually implementing fundamental changes in the current development cycle.
This really resonates. One thing I keep thinking about with AI-assisted development is how quickly the verification stack is growing.
We have tools for static analysis, testing, code review, security, observability, and now AI-based tools layered on top of all of that. Each one is useful, but we're ending up with a lot of different signals coming from different points in the development lifecycle.
At some point, I think the question becomes: do we really need another tool, or do we need one place that understands reliability across the whole application lifecycle?
That's the problem we're trying to tackle with Tomosu.
Instead of adding another point solution to the stack, we're building Tomosu as an end-to-end reliability layer — looking at the application during development, identifying potential production reliability issues, helping engineers fix them, and then connecting that back to what actually happens in production.
The idea is pretty simple: rather than stitching together a bunch of tools and trying to piece together what they all mean, have one system focused on the reliability of the application as a whole.
I think this becomes even more important as AI makes it possible to generate and change code at a pace that our existing verification processes weren't really designed for.
The goal isn't more tools. It's better, more unified visibility into whether the software we're building will actually hold up in production.