Soumendra Mohanty is the Chief Strategy and Innovation Officer at Tredence Inc.
It’s easy enough for large organizations to add agent tooling for their developers and mark the productivity gains. You’re invoiced for generative output; you make the business case based on hours saved. But there’s a second part to that transaction: all the review time that those developers will consume from colleagues whose calendars were already full.
Over the past two years, in particular, I’ve watched some versions of this cycle play out across enterprise delivery organizations. Thanks to the generative power of AI coding capabilities, the volume needing review outstrips the capacity available to provide it. This gets resolved by senior engineers approving changes faster than they can follow them.
As a result, code merges with an assumption that someone understood those changes. Then the cost surfaces months later, when an incident review asks why, to which nobody can provide a good answer. Too often, this is because the decision was made by a model and approved without enough scrutiny.
Why Review Capacity Has Become A Scarce Input
Agile is designed for a world where the scarce input is engineering hours. Standups, story points and the sprint itself all exist to extract more shipped software from a fixed supply of human time. Agent tooling makes generation hours abundant.
What remains is the number of hours in a week during which an experienced engineer can trace the logic of a change rather than skim it for red flags. Today, that number governs how fast an organization can safely ship. Few planning systems record it anywhere.
What the research shows:
• In its 2025 report, Google’s DORA program put AI use among tech professionals near 90%, with about 30% of respondents saying they trust the output little or not at all. The same research found higher AI adoption moving throughput and delivery instability in the same direction.
• Stack Overflow’s 2025 developer survey says two-thirds of developers named “almost right, but not quite” as their leading frustration with AI output; 45% reported that debugging AI-generated code takes them longer than writing it themselves.
• A randomized trial by METR, in which 16 experienced open-source developers worked through 246 real issues, found that it took 19% longer when using AI tools (yet after the experiment, the developers had estimated that AI made them 20% faster).
In a word, adding tooling expands the queue. It’s understandable that, when looking at a review backlog, an executive’s response is to add capacity. In fact, that instinct may compound the problem. Each additional seat raises the volume of change requiring review, while adding nothing to the queue’s ability to perform it.
And of course, the people who can clear that review queue are the ones that most organizations have the fewest of. Senior review time isn’t procured on a quarterly cycle; it doesn’t scale with the licensing budget. Doubling generation capabilities is not the same as doubling review-capable engineers.
So how can organizations build a verification layer that sits inside whatever delivery framework they already run?
Budgeting For Verification
Estimate the hours per week your senior engineers can give for careful code review. That is, the kind of review in which engineers follow a change through the system, rather than skimming it for what stands out. Set that figure against the volume of change your teams now produce. Organizations that run this exercise often find a much bigger gap than they expected.
More likely than not, delivery estimates are already part of your planning sessions. Verification capacity belongs right beside them. When the two figures diverge, it reveals a decision about headcount, scope or risk appetite that would otherwise arrive as a later incident.
Scaling Review To Blast Radius
Uniform review across every change will exhaust the people doing it. Teams under that kind of review tend to reduce review to formality. Instead, review effort should track what breaks when the change is wrong.
Authentication, payment paths, data deletion and anything that touches customer records should earn full manual review by a named owner. Internal tooling and prototypes less so, and they should be labeled clearly enough that they don’t migrate into production unexamined.
Tagging a codebase this way is architecture work. Have an architect assign the tag, store it with the code and treat permissive tagging as the expensive error that it is.
Naming The Owner Who Can Explain
Whatever your current system is, every merged change already carries a name attached. The question is whether that person can explain the logic, side effects and dependencies. Best not to scramble for those answers during a security review, or at three in the morning after an incident. Regulatory exposure resolves to a human being, so your delivery system should be able to show which one and on what basis.
Building The Bench
Engineering judgment used to accumulate slowly, through years of writing code and living with the consequences. In the era of agentic AI, that apprenticeship is compressing. Organizations handling it well are putting junior engineers on verification work deliberately, paired with someone who can explain what they’re looking at. Organizations leaving this to chance are drawing on a supply of senior judgment that’s not currently being replenished.
Waterfall, Agile And Now AVID
We call this AVID: Agentic Verification and Iterative Delegation. It is a working methodology built around four values:
1. Verified trust over blind velocity
2. Judgment budgets over unlimited delegation
3. Owned diffs over anonymous output
4. Blast-radius awareness over uniform review
None of these four values requires new tooling or reorganization. Taken together, they take verification from something that happens when there is time to something that appears in the plan. This will be critical in an era where organizations will need to account for what they’ve built. That capacity has to be budgeted like any other.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?