There's a pattern showing up in mature codebases that have adopted AI coding assistants. The team ships more code. The pull request volume goes up. And somehow, senior engineers are spending more of their week reviewing, debugging, and rewriting AI-generated output, not less.
The work didn't disappear. It moved. The bottleneck in many engineering organizations has shifted from the creation of code to the verification of it, and the people qualified to do that verification are the most expensive engineers on the team.
What the Research Actually Shows
In July 2025, a randomized controlled trial that became one of the most-discussed pieces of AI productivity research of the year tracked sixteen experienced open-source developers through 246 real tasks in mature repositories they'd contributed to for an average of five years. Tasks were randomly assigned to allow or disallow AI assistance. The headline finding: when AI tools were allowed, tasks took 19% longer.[a]
The story has gotten more nuanced since. A February 2026 follow-up cohort using later-2025 AI tools showed a much smaller effect, roughly 4% slowdown, with a confidence interval that crosses zero.[b] The current researcher position is that AI likely provides modest productivity benefits in early 2026, though the magnitude is uncertain because of selection effects in the newer sample (developers who didn't want to work without AI declined to participate, biasing the pool).
Both studies point to the same underlying phenomenon. The volume of code being produced went up. The verification overhead went up alongside it. Whether the net result is positive or negative on time depends on the codebase, the tooling, and the task. What doesn't change is where the engineering time is going: from writing to reviewing.
The Quality Picture
A separate 2025 analysis of 211 million changed lines of code across five years of repository activity, including projects like Chromium and Visual Studio Code, found several quality-side shifts in AI-assisted development.[c]
- Code refactoring activity dropped from 25% of changed lines in 2021 to under 10% in 2024.
- Duplicated code blocks increased roughly 8× in 2024 compared to the pre-AI baseline.
- Short-term code churn (lines reverted or rewritten within two weeks) rose from 5.5% in 2020 to 7.9% in 2024.
The composition of code is changing. More duplicated blocks, more churn, less refactoring. Each of those signals more work downstream for whoever has to maintain the system, and that work falls disproportionately on the engineers with the architectural context to do it.
The Cost of the Shift
In Seattle, a senior software developer carries a fully loaded cost of roughly $219,000 per year. That figure uses a base salary in the $165,000 range, per federal wage data for software developers in the Seattle-Tacoma-Bellevue MSA, with a 1.3× burden multiplier applied for payroll taxes, benefits, equipment, and overhead.[d] Senior-tier developers run higher than the metro mean, and at the upper end of the band, total compensation reaches well past that figure once equity and bonuses are factored.
Fully loaded annual cost of a senior Seattle software developer. Federal wage data with a 1.3× burden multiplier applied at the senior tier.
That number matters because of where those hours are going. When a senior engineer spends the day reviewing AI-generated pull requests, untangling hallucinated dependencies, or hunting subtle logic errors in code they didn't write, the organization is paying architect-tier rates for quality assurance work. The skill is being applied. The leverage isn't.
The work AI shifted isn't lower-value. It's higher-stakes. Reviewing code you didn't write demands more architectural context than writing the original code in the first place.
What the Structural Response Looks Like
One common instinct is to add tooling. More linting, more automated review, more guardrails on what AI assistants can suggest. Those help at the margin. They don't solve the underlying issue, which is that human verification of AI-generated code is bandwidth-limited and the bandwidth in question is the most expensive bandwidth on the team.
A second approach is to expand engineering capacity specifically positioned for code review, technical debt management, and routine quality assurance. That tier sits inside the team's existing workflow, working under the same architectural standards, but freeing the most senior engineers to stay on the work where their experience compounds. The pattern shows up across organizations that have measurably reduced their AI-driven verification overhead in 2025: not less AI use, but more deliberate allocation of who reviews what, and how reviewer time gets protected.
The structural question isn't whether to use AI tools. That question was settled by adoption rates two years ago. The question is who carries the verification load that AI tools shifted onto the team, and whether that load is concentrated in the most expensive hours of the most senior engineers, or distributed across capacity built specifically for it.
Reading the Signal in a Codebase
The signals that an engineering organization is carrying Comprehension Debt are observable in the data already collected. Pull request review time. Time from PR open to merge. Short-term commit churn. Ratio of senior engineer time spent in review versus authoring. Most of those metrics live in the team's existing tooling, including GitHub Insights, Jira velocity reports, and internal dashboards.
What those metrics show, when read against the productivity and code-quality research above, is whether the AI-tooling shift has produced a net win on engineering output, or whether the velocity gain at the keyboard is being absorbed downstream in verification.
That's a question only the team's own data can answer. The research provides the frame. The numbers in any given codebase tell the actual story.