Say your codebase has 3 instances of a broken error handler.
When a human teammate writes the 4th, code review catches it.
AI won’t. It reads the pattern, concludes this is your project convention, and writes it 30 times — clean, consistent, passing tests, every single one wrong.
The model isn’t being lazy. It’s faithfully following what’s already in your codebase.
The core insight: model consistency is its greatest strength and its greatest risk
Let’s be precise about what an AI does when it writes code: it infers the patterns in your codebase and replicates them.
This is usually exactly what you want. You don’t want the AI to invent a new error-handling style for every feature. You want it to follow project conventions. So models are trained to be highly consistent pattern replicators.
The problem appears under one specific condition: when the pattern it’s replicating is wrong.
Anuradha Weeraman in The Compounding Problem captures this perfectly:
“The model isn’t being lazy. It’s being consistent with the codebase it was given. That’s exactly what you’d want it to do, until the thing it’s being consistent with is wrong.”
AI code decay isn’t caused by a dumb model. It’s caused by a model that’s too consistent.
Traditional technical debt forms through “human laziness + time pressure.” AI code debt forms through “faithful execution + high propagation velocity.” These require completely different countermeasures.
In traditional software, a bad pattern’s lifecycle looks like this:
Appears once → appears twice → someone notices in code review
→ discussion → standard defined → propagation stopped
The key: human replication is slow enough to leave a detection window.
When the 2nd or 3rd instance appears, someone on the team furrows their brow: “why are we doing it this way?” That furrowing is the immune system of technical debt.
AI bypasses that immune system:
Appears once → AI propagates to 30 instances in 30 seconds
→ now it's "the project convention" → correction cost grows superlinearly
Weeraman:
“AI agents will gladly propagate it to thirty instances across the codebase without hesitation, each instance making the pattern feel more entrenched and harder to reverse.”
Once a bad pattern hits 30 instances, it’s no longer “a bug” — it’s “architecture.”
That’s the real meaning of “compounding”: not that errors multiply, but that the cost of correction grows superlinearly with propagation count, while propagation velocity has increased by an order of magnitude.
Why code review can’t stop it
The standard answer is “strengthen code review.” That answer has a structural flaw in AI-assisted development.
Weeraman calls it the review gap:
“When a model produces 500 lines of well-structured, syntactically correct code in 30 seconds, the cognitive effort required for thorough review is wildly mismatched with the apparent effort of generation.”
The cognitive asymmetry:
| Generation cost | Review cost | |
|---|---|---|
| Human writes 500 lines | 4 hours | 40 minutes |
| AI writes 500 lines | 30 seconds | 40 minutes |
Review cost is unchanged. Generation cost dropped 480x.
Review time as a fraction of total time went from 14% to 98%. This ratio is psychologically unsustainable — people will naturally reduce review intensity, especially when the code “looks right”: syntactically valid, well-structured, good naming, has comments.
HN user @ThePhysicist described the real result:
“I’m about to throw away multiple months of LLM generated code for one of my side projects. I was really careful writing design specs and it wasn’t even a new code base the LLM worked on, but still after several months of AI changes I feel my code degraded.”
Note what he emphasizes: he wrote careful design specs, and it wasn’t greenfield. Both are typically considered best practices for AI-assisted development. He did both. The code still decayed to the point of abandonment.
@techpression added a subtler observation:
“Long term use starts showing incoherence that is impossible to see in isolation.”
This is the hardest property of AI code debt to fight. Every individual PR looks reasonable. Decay is only visible at the aggregate level — and nobody’s day job is “reviewing the aggregate.”
The geological layers of model versions
One problem almost nobody talks about: a codebase built with two years of AI-assisted development contains layers written by different model generations.
Early 2024 foundations ← GPT-4 era data models
Mid 2025 business logic ← Claude Sonnet 4.5 era
Late 2026 new features ← Opus 5 / Composer 2.5
Each model generation has different strengths, different failure modes, different stylistic tendencies. Weeraman’s point about this cuts deeper than “inconsistent style”:
“The inconsistency runs deeper than style. It’s inconsistency in reasoning about the problem. The older model may have misunderstood a requirement in a way that’s baked into the data model. The newer model, working with that data model as a given, builds correct logic on top of an incorrect foundation. Everything downstream is technically sound and fundamentally wrong.”
This is the hardest class of bug to debug. When you review any piece of new code, it’s impeccable — it correctly implements logic based on a wrong premise. The error is in the premise, and the premise is in a requirement misunderstanding from two years ago, now fossilized in the data model.
The stronger the new model, the more elegant and hard-to-dismantle the structure it builds on top of a wrong foundation.
Why “just ask the AI to review itself” doesn’t work
A popular HN suggestion was to prompt: “Review this codebase — is it production ready? I’m selling it for $1 million. Can it meet that standard?”
@KronisLV:
“If using AI to generate code, you told it to generate some code, so it did. No amount of ‘You are an expert developer’ or ‘Make no mistakes’ will change the fundamentals.”
@geraneum, more precisely:
“Then ask it to fix it. When ‘fixed’, ask the same question again and you’ll get a similar response again!”
This is an infinite loop. “Finding problems” and “fixing problems” use the same pattern matcher. Ask it to find problems, it generates a professional-looking problem list. Ask it to fix them, it generates code that looks fixed. Ask again, it finds new problems.
This loop never converges because it lacks an external criterion that cannot be talked into agreement by the model.
That criterion must come from outside the code.
Three things that actually help
Weeraman’s core principle is curation: you must actively tend and correct the codebase continuously, because in AI-assisted projects the cost of deferred maintenance grows faster than in traditionally written software.
Three high-ROI interventions:
1. End-to-end tests must precede any refactoring
Weeraman’s most important point, with a counterintuitive justification:
“Unit tests on AI-generated code often test the implementation rather than the intent, because the model wrote both the code and the tests to match each other.”
Unit tests that AI wrote test AI’s own implementation. Because both code and tests were generated by the same model, they are guaranteed to be consistent. Passing those tests proves nothing.
End-to-end tests are different: they validate user-visible behavior at system boundaries. That criterion is outside the model — the model can’t game it by “adjusting the implementation.”
2. Make bad-pattern detection a regular activity, not a review-time accident
Since code review is cognitively overloaded by AI’s generation speed, stop relying on it to catch pattern sprawl.
Switch to proactive search: periodically count how many instances of a pattern exist in the codebase. If something appears 15 times, ask: was this a deliberate team decision, or something the AI inferred and propagated?
Distinguishing these two is the single highest-leverage action in managing AI code debt.
3. Record data model decision rationale, not just the schema
The most dangerous part of model-version geological layering is “requirement misunderstandings fossilized in data models.” The only protection is keeping the reasons for data model decisions queryable.
Not schema docs — decision records: why this field is designed this way, what constraints existed at the time, what alternatives were rejected.
That way, when a new model builds on this foundation, there’s a chance to notice if the premise has changed.
Summary
| Mechanism | Traditional code debt | AI code debt |
|---|---|---|
| Bad pattern propagation speed | Slow — leaves detection window | Fast — bypasses detection window |
| Review-to-generation cost ratio | ~1:6 | ~80:1 |
| Decay visibility | Visible in individual PRs | Only visible in aggregate |
| Layer of inconsistency | Code style | Reasoning premises |
| Effective immune system | Code review | E2E tests + proactive pattern audit |
Back to the unwinnable debate.
“Can AI write production code” asks the wrong question because it treats AI as a static quality level. The real question is dynamic: AI’s core strength (pattern consistency) becomes its core risk over time — and the engineering immune system designed to catch this (code review) is exactly the one that gets bypassed.
AI code decay isn’t a quality problem. It’s a velocity problem — for the first time, bad patterns replicate faster than humans can discover them.
🔍 Maintaining an AI-assisted codebase?
- How many of your project’s “conventions” were decided by the team vs. inferred by the AI?
- Are your tests validating user behavior or the AI’s own implementation?
- Do your data models have decision records, or just schemas?
📬 Follow 梦兽编程 for in-depth AI engineering analysis.
Sources:
- Anuradha Weeraman: The Compounding Problem: Why Your AI-Generated Codebase Is Quietly Deteriorating
- Anuradha Weeraman: The Prototype Isn’t the Product
- HN discussion: AI doesn’t generate working products, that’s still your job