There is a company I encountered recently that has almost entirely handed its coding to AI. The people there say programming skills no longer matter because "we just trust the results." The mood is confident. The velocity feels real. They believe they are ahead.
They are not ahead. They are early to a failure mode that will arrive on a schedule—set the day the architecture stopped being human, and delivered when the comprehension window closes.
AI does not just write code. It adds complexity faster than it adds capability. And complexity compounds like interest.
GitClear and GitKraken analyzed 623 million real-world code changes from 2023 to 2026. The findings are stark: code duplication is up 81%, while code reuse—measured by how often commits edit existing codebases—is down 70%. Code that catches errors without evaluating their cause (error masking) is up 47%. As Bill Harding, CEO of GitClear, puts it: "Every time you want something, AI creates a new package for it. That general approach to building has all sorts of consequences."
The result is code that is locally correct but globally inconsistent. It passes the immediate test. It looks plausible. But it does not compose. And the interest on that inconsistency accrues quietly.
The obvious objection is that better models are coming. This misunderstands the constraint.
Even a 1 million token context window is not a production system. Google's own documentation states that 1 million tokens equals roughly 50,000 lines of code (at 80 characters per line). A typical production system is one to three orders of magnitude larger. This is not a temporary limitation waiting for a bigger window. It is a structural mismatch.
Your AI can see a room. Your production system is a city.
The deepest loss is not in the code. It is in the humans who are supposed to understand it.
Comprehension debt is the gap between how much code exists and how much any person genuinely understands. It breeds false confidence because the codebase looks clean and the tests are green.
A study from Penn State and USC, published in Scientific Reports, found that passive AI use—copying and pasting AI-generated content—reduced psychological ownership by nearly 20% and self-efficacy and perceived meaningfulness by nearly 10%, relative to manual work. The declines in self-efficacy and meaningfulness persisted even after participants returned to manual work.
Interestingly, passive AI use initially led to higher task enjoyment and outcome satisfaction—up to 29% higher than manual work. It felt better. But when participants returned to manual writing, their outcome satisfaction fell to 21% lower than those who had written manually all along.
The code will still run. The understanding will not. That is the failure. That is why it is on schedule.
It is easy to blame the propaganda. The urgency framing, the "adopt or fall behind" rhetoric—these are real and they work because the fear is rational. Competitive pressure is real.
But the deeper mechanism is internal, not external. Adoption itself produces a feeling of capability that masks the loss of capability.
METR's randomized controlled trial put 16 experienced developers on 246 real tasks in their own codebases. They believed they were 20% faster with AI. After finishing, they estimated they had been about 20% faster. The measured result: 19% slower. As the study's authors put it: people are bad at estimating speedup from AI.
Organizations amplify this. The 2024 DORA report found that AI adoption significantly increases individual productivity, flow, and job satisfaction, but also negatively impacts software delivery stability and throughput. The data showed a drop in throughput of 1.5% and stability of 7.2% for environments where AI had been adopted. And a significant 39% of respondents said they had low or no trust in AI-generated code.
The illusion of capability is not a side effect. It is the mechanism that keeps teams walking toward the edge.
This is not theoretical.
SlopCodeBench, a benchmark designed to measure how coding agents degrade over iterative tasks, tested 11 models across 20 problems with 93 progressive checkpoints. No model solved any problem end-to-end. The highest checkpoint solve rate was 17.2%. More telling: 80% of trajectories showed rising structural erosion, and 89.8% showed rising verbosity. Agent code was 2.2 times more verbose than human code from 48 open-source Python repositories. And a prompt intervention that improved initial code quality could not prevent the degradation in subsequent iterations.
The financial evidence is catching up. Uber burned through its entire 2026 AI coding budget in four months. Its COO, Andrew Macdonald, said the link between token consumption and useful consumer features "is not there yet" and called the CTO's disclosure a "head-exploding moment". He questioned whether the trade—token costs versus headcount—could be justified without a direct line to shipped functionality: "If you're not actually able to draw a direct line to how much useful features and functionality you're shipping to your users, that trade becomes harder to justify."
The brief window is not a runway to better tooling. It is the time between the first AI commit and the moment the system becomes unmaintainable by anyone.
The evidence points to four principles.
Architecture is human work. Cut the system down before AI touches it. AI fills small, bounded blocks—not systems. The architectural decisions about boundaries, interfaces, and invariants cannot be delegated.
Delegate only what you can verify. If a human can easily understand the block, or the outcome is acceptable probabilistically, delegate it. If context, judgment, or consequences matter, do not. The Penn State study shows that collaborative use—workshopping your own ideas with AI—preserves psychological connection and skill, while passive use erodes both.
Externalize the "how." Architectural constraints and acceptance criteria live in stable artifacts—not in conversations that decay. A conversation is the most fragile medium for requirements. It grows, compacts, and forgets.
Every AI-written module needs a human owner who can explain it. If no one can, it is not finished. It is orphaned.
The company that trusts the results is not reckless. It is early to a pattern many will follow.
The failure will not be a crash. It will be a slow closure of the comprehension window—a system that still runs, still passes tests, still ships features, while no one understands it well enough to fix it when it breaks.
When the system breaks at scale, who will understand it well enough to fix it?
If the answer is "the AI," the comprehension window is already closing. If the answer is "no one," it has already closed. All statistics cited in this post are drawn from publicly available research. Primary sources include GitClear's 2026 code quality analysis (623M changes), SlopCodeBench (2026), the Penn State/USC study published in Scientific Reports (2026), METR's randomized controlled trial (2025), the DORA State of DevOps Report (2024), and Google's Gemini API documentation on long context.