Two years ago the difficult part of AI-assisted development was getting a model to produce code that looked correct, and for many teams that is no longer the main constraint, with agents now opening pull requests faster than their review processes can absorb. What replaced it is a harder and less visible problem that begins the moment the code exists and someone has to decide whether to trust it.
“The part nobody solved is what happens after the code is written,” says Gal Vered, CEO and co-founder of Checksum, whose work with engineering teams centers on the testing infrastructure that determines whether generated code holds up against a real database, a rate-limited API, and a permission system nobody documented.
Checksum’s research shows how wide that gap has become. Over the previous 90 days, 61% of surveyed engineering leaders reported a production incident caused by AI-generated code, and 74.3% had rolled back an AI change that their own unit tests never flagged. These findings do not describe teams that simply skipped every safeguard, because respondents reported writing tests, conducting code review, and using AI tools to check AI output, which suggests the problem lies in the design of the verification loop rather than in the diligence of the people operating it.
AI code debt looks correct and passes every check you have
“That spread is the signature of a blind spot, not a bug type.”
Gal Vered
Vered draws a distinction that changes what teams think they are accumulating when they scale up generation.
“It’s not sloppy code,” he says of what he calls AI code debt. “It’s code that looks completely correct and passes every check you have, but was never tested against the conditions it will actually run in.” The model wrote it without ever seeing the production database, the third-party rate limits, or the business logic that lives only in a senior engineer’s head, so it can pass the available checks and still fail under the conditions that determine whether the system works.
The root-cause data from the same research supports that framing because the incidents did not cluster around a single failure category. When Checksum asked leaders what caused their most recent AI-related incident, no single cause dominated, and performance issues at scale, logic errors, and integration failures the model could not have anticipated all clustered together in the high teens to low twenties.
For Vered, that flat distribution is the finding rather than a gap in the data, because it points to a blind spot rather than a single bug type. “You don’t fix a blind spot by writing more unit tests,” he says. “You fix it by giving the agent visibility into the environment before the code ships, not after.” Vered uses the CrowdStrike and Cloudflare incidents as examples of the same pattern at scale, where individually tested components can still fail through their interaction at runtime.
For leaders who want to act on that reading rather than file it away, one practical move is to change how incidents get classified after the fact. Instead of sorting them only by bug type, sort them by whether the failing condition was observable anywhere in the pre-merge environment, because that distinction shows whether the team needs another test or a more realistic verification environment.
Review time absorbs the volume gains from AI code generation
The workflow most teams followed a few years ago moved from writing code to reviewing it to shipping it, and the current one looks closer to prompting, generating, reviewing, re-prompting, and reviewing again. Review never went away under that shift, because it quietly absorbed the hours that used to go into writing along with a share of the hours that were never budgeted anywhere.
Checksum’s data puts the cost in plain terms, with 64.8% of leaders reporting that AI-generated code takes more review time than human-written code rather than less, and half reporting that their review cycles have grown by 25% or more since adopting AI coding tools. Faros AI’s telemetry, which Vered cites, reports that teams with high AI adoption merge 98% more pull requests while review time on those pull requests rises 91%.
“The volume gains on the writing side are getting paid back with interest on the review side,” Vered says.
Adding reviewers is the obvious response, and the same research suggests many leaders do not think it will hold, because only 28.6% believe they could hire their way out of the review burden and a comparable share describe it as a structural problem that headcount cannot solve. Those responses reflect a review task that differs from reading a colleague’s pull request, because engineers must search for subtle mistakes inside code that often appears locally plausible.
What works instead is a change in sequence rather than staffing, and Vered describes the target state in terms most teams will recognize from their own product usage. He expects the same prompt, generate, and verify loop used in vibe-coded applications to shape enterprise software within the next 12 months, with verification becoming a simulation layer that tests the application under realistic conditions before it ships.
Vered argues that teams getting this right move verification ahead of the human, so that by the time an engineer opens a diff the automated checks have already covered the mechanical questions and review can focus on design and intent. Practically, that means setting a rule about ordering, where no pull request reaches a human reviewer until automated verification has completed and reported what it found.
Coding agents cannot see what actually decides runtime behavior
Underneath both the debt and the review tax is a visibility gap that Vered calls the “Context Void,” and naming it matters because it changes what kind of problem leaders think they are solving.
A coding agent sees code, but it does not see database state, API behavior under load, the permission system, feature flags, or the actual shape of production traffic. Everything that determines runtime behavior remains outside what the agent can observe, and Vered is explicit that this is structural rather than a temporary limitation that better models will close, because a more capable model still cannot reason about a system it was never shown.
That is where his comparison to autonomous vehicles becomes more than a convenient analogy. “Nobody would put a self-driving car on the road without a world model,” he says. “You don’t make the driving model safe by making it smarter in isolation, you give it millions of simulated miles to practice on first.”
In Vered’s comparison, autonomy in the physical world depends on simulation rather than trust in the model alone, with varying weather, traffic, pedestrian behavior, and sensor noise rehearsed before anything touches a public road.
Vered argues software carries the harder version of that problem, since a production system’s state space, meaning every combination of configuration, data, and timing, is arguably larger than what a car encounters on a city block and cannot be exhaustively enumerated. Because teams cannot exhaustively enumerate that state space, they have to simulate representative conditions, which is why Vered expects the next few years of software development to resemble autonomous vehicle development more than the review-heavy process most teams use today.
Verification belongs in infrastructure rather than at the end of the pipeline
Vered’s central recommendation to engineering leaders is to reclassify verification as infrastructure, because that changes both where it operates and what gets funded. That means making it as permanent and automatic as a CI pipeline, because most teams currently have AI writing code and a patchwork of humans and point tools trying to catch what it missed, and that patchwork does not scale as generated-code volume grows.
The concrete starting point is an audit of which stage each existing check occupies and what environment it can see. Unit tests, code review, and security scanning all earn their place, and Checksum’s research found that AI unit-test generation, which Vered describes as the most direct counterweight to AI-written code, remains the least adopted of the major verification categories at 48.6%. Adoption is only half the question, because none of those layers can see what production sees, and a team can raise coverage across all of them while leaving the actual blind spot untouched.
The standard Vered suggests leaders hold themselves to is the one they already apply to their toolchain without thinking about it, which is trusting code the way they trust a compiler, not by reading every line but by trusting the verification underneath it. Reaching that bar is what makes the volume sustainable, and teams that set it now will get there before the rate of generated code outruns anyone’s ability to review it by hand.
Three stages take a team from manual QA to simulation-driven validation
For teams relying on manual QA today and looking at simulation-driven validation as the destination, Vered describes a sequence rather than a leap, and each stage produces value on its own.
The first stage brings verification inside the loop the AI already uses for writing code, with tests generated and executed automatically on every pull request and targeted to what actually changed, so that nothing merges on the strength of code review alone. Teams that complete only this stage can still reduce failures caused by approving a diff that nobody executed.
The second stage moves from testing code in isolation to testing it against production-like conditions, meaning real data shapes, real API behavior, and real load rather than mocks. Checksum’s research shows that 69.5% of teams already verify against production-like conditions in some form, although those checks often remain bolted onto a process that cannot fully see the interactions between systems where the expensive failures emerge.
The third stage closes the loop so that the agent receives more than a pass or a fail. It gets told what broke and why, in terms it can act on, so it can fix the problem and re-verify without a human in the middle of every cycle. The payoff at that point is not only a lower incident count, because the larger return appears in how the team uses its most expensive engineering hours.
“They’ll get their senior engineers back,” Vered says, “because those are the people currently absorbing the gap by hand.”
Gal Vered is CEO and co-founder of Checksum, which builds AI-generated end-to-end Cypress and Playwright tests. This is not a sponsored article. Research cited in this article was conducted by Checksum unless otherwise noted.
I see this pattern with engineer clients: they invest in AI tools without budgeting the review tax, then wonder why velocity stalls.
Verification isn't a headcount problem — it's a capital expense, like planning for medical inflation in retirement.
Treat it as a fixed cost line item, or the interest compounds.