A study from Info-Tech Research Group published July 20 asked 578 developers and engineering leaders how AI is affecting their work. Ninety-four percent reported productivity gains. The same study found that AI-generated code requires more testing than hand-written code.
Both of those things are true simultaneously, and the gap between them is the finding worth paying attention to.
If AI tools make you meaningfully more productive, you'd expect to do less work downstream, not more. The testing overhead is a cost the productivity number doesn't account for. There's a mechanical explanation for why that cost keeps rising even as the output numbers look good, and it has less to do with code quality than with what happens to your understanding of your own codebase when you stop writing most of it yourself.
What Approving Code Actually Gives You
When an agent produces 200 lines that implement the feature you asked for, you do a review. The diff looks right. The tests pass. The logic holds up on inspection. You approve it and move on.
What you didn't do is trace through every branch, internalize every edge case, or build the mental model you would have built if you'd written those 200 lines yourself. You verified the output. That's not the same as understanding it.
This seems like a minor distinction until you need to modify that code three months later. Or debug a production issue that originates in an assumption the agent made that you didn't catch during review. Or onboard someone who asks why a particular design decision was made. Your answer, if you're honest, is that you're not sure — you approved it, and at the time it seemed fine.
The Codebase Knowledge Problem
A May 2026 ACM paper on coding agent autonomy included a formative study with 21 software engineers who use agents regularly. The researchers asked them to describe their leading concerns. Subtle bugs that pass review was first, cited by 13 of 21. Erosion of their own understanding of the codebase was second — 12 of 21.
Not code quality. Not security vulnerabilities. Their own decreasing ability to understand code they nominally own.
That's a specific concern that doesn't show up in any of the metrics teams currently use to measure AI-assisted development. Commit count looks fine. PR velocity looks good. Test coverage might even be high, because they're writing more tests to compensate for the understanding they're not accumulating. But the developer's mental model of the codebase — the thing that lets them move fast without breaking things, spot architectural drift before it becomes a crisis, debug production issues by reasoning about the system rather than staring at logs — is quietly degrading.
It's not gradual skill atrophy in the sense of "I'm less good at writing code than I used to be." It's specifically this: the code in the repository is no longer the code in your head. Each approval that happened faster than full comprehension widens that gap.
How the Compounding Works
Early on, the gap is small and recoverable. You approved a PR you didn't fully trace through. If you needed to, you could sit down with it for an hour and understand it. The layer is thin.
After a year of heavy AI-assisted development, the layers stack. Every week you've been approving work at a rate your comprehension couldn't keep up with. The codebase grew faster than your understanding of it. When you now need to understand a piece of that code, you're not starting from a thin layer — you're starting from a system where your mental model is months behind the actual state of things.
This is why the Info-Tech study found that AI code requires more testing even when developers report being more productive. Testing is compensating for the understanding developers used to build by writing the code themselves. The two things are substitutes. When you stop building understanding one way, you have to replace it with something else — and formal testing is the visible, process-able proxy for the tacit knowledge you're no longer accumulating.
The problem is that testing is a less efficient substitute. You can write tests that pass for incorrect behavior if you don't understand what the correct behavior actually is. Tests verify that the code does what you specified. They don't verify that what you specified was right.
The Metric Nobody Is Tracking
Every developer productivity dashboard I've seen tracks output signals: commits per week, PRs opened, lines generated, acceptance rate for AI suggestions, PR cycle time. Some better ones track downstream signals: revision rate, post-merge bug rate, PR cycle time versus review turnaround.
None of them track the developer's decreasing ability to reason about their own codebase.
This doesn't appear in the metrics until it causes something: a production incident that took longer to diagnose because the on-call engineer didn't have a working mental model of the affected service. A refactor that went wrong because the developer didn't understand a dependency the agent had introduced six months earlier. An onboarding experience where the senior engineer can't answer questions about their own code.
At that point, it's not a productivity problem. It's a reliability problem. And tracing it back to the approval pattern that created it requires looking at data that most teams aren't collecting.
The Governance Gap Is an Understanding Gap
Info-Tech's finding on governance is relevant here in a specific way. Only 37.4% of developers using AI at the build stage describe their AI maturity as formal or better. The study frames this as an organizational process failure: teams need SOPs, production-readiness criteria, review requirements for AI-generated code.
All of that is true. But the process failures downstream are in part a consequence of the understanding gap upstream. You can write a policy that says "all AI-generated code must be reviewed." That policy doesn't change what "reviewed" actually means in practice — which is often "I read it, it looked fine, I approved it" without the deeper comprehension that writing it yourself would have forced.
Governance maturity, operationally, looks like: developers who are actually slowing down to understand the AI-generated code at the same depth they'd understand code they wrote, and teams that track whether the understanding gap is growing. The first requires a different relationship to review. The second requires data most teams aren't capturing.
What Would Show You the Gap
The signal for this doesn't come from your AI tool or your version control system. It comes from how you spend time in the codebase that isn't generation.
Reading time. Time navigating files, following call stacks, reading documentation you didn't write. If your AI usage goes up but your reading and navigation time goes down proportionally, you're generating more and understanding less. The ratio is a candidate measure of whether your mental model is keeping pace with the codebase.
At xeve, we track this boundary — the split between generation-heavy sessions and the reading and debugging that follows them. The ratio of AI generation time to terminal time and file navigation time in the same workday is one of the more consistent signals we've found for whether a toolchain change is compounding understanding or substituting for it. More generation without corresponding reading is the fingerprint.
There's no benchmark for what a healthy ratio looks like. It varies by codebase complexity, team structure, how long you've been on a project. But the direction matters more than the absolute number. If the reading-to-generation ratio is declining month over month, that's what knowledge erosion looks like in session data.
The Productivity Number Is Real. So Is the Cost.
I don't think the 94% who reported productivity gains in the Info-Tech study were wrong. The velocity improvement from AI-assisted development is real and it shows up in their work.
The testing overhead is also real, and it also shows up. The two coexist because the productivity gain and the knowledge cost are coming from the same source: generating code faster than you're building understanding of it.
Neither number is the full story. Productivity went up. Understanding your codebase got harder. Both are happening, in the same workflows, at the same teams, measured by different instruments — and usually reported separately.
The question worth asking isn't whether AI made you more productive this quarter. It's whether the codebase you'll be maintaining next year is still one you understand.