Field note · May 16, 2026
AI Is a Tech Debt Multiplier
AI does not create a healthy codebase.
It amplifies the one you already have.
That is the uncomfortable part of AI-assisted development. In a clean, typed, well-tested system, agents can move fast because the codebase tells them what "good" looks like. In a tangled, undocumented system, agents still move fast. They just move fast in the wrong direction.
This is the third pillar in AI readiness: codebase health.
The demo hides the compounding effect
Most AI coding demos happen in a small context. A new component. A bug with a clear stack trace. A function with obvious inputs and outputs. The agent does well because the problem is bounded.
Real product code is different.
There are old behaviours nobody remembers. Half-migrated patterns. Weak types. Tests that cover the easy path but not the business rule. Naming conventions that changed three times. One service that only works because another service sends data in a shape that was never documented.
Humans survive this with memory and judgment. They know which module is weird. They know which test lies. They know not to copy the old billing code because it predates the current pricing model.
AI does not know that unless the codebase says it.
So it copies what it sees.
If the local pattern is healthy, that is useful. If the local pattern is debt, AI turns debt into more debt.
Technical debt used to accumulate slowly
Before AI, technical debt often took years to reach the point where delivery became visibly painful.
Every shortcut added a little friction. Every undocumented workaround made onboarding slower. Every weak test made future changes riskier. The team could still ship, so the debt remained abstract until a major feature, migration, or incident forced the conversation.
AI compresses that timeline.
The team can now generate more code in the same calendar time. More code means more surface area to review, test, own, and understand. If the codebase is healthy, that surface area is manageable. If it is unhealthy, the team can hit a wall much faster: every new change breaks something old, or requires days of manual testing, or creates so much review uncertainty that seniors stop trusting the agent.
In our audits, this pattern often shows up within a quarter or two of broad AI rollout. The first month feels fast. Then review load rises. Then rework rises. Then the senior engineers quietly return to writing critical changes themselves.
That is not an AI adoption problem. It is a code health problem exposed by AI pace.
The research signal is already visible
Be careful with AI quality claims. The field is young, and vendors have incentives.
Still, the direction is clear enough to act on.
CodeScene's AI code health work reports that defect risk rises by at least 60% when AI works on unhealthy code, based on its published research summary on preventing AI-generated technical debt. Its broader code quality research has also connected unhealthy code with higher defect density and slower issue resolution; see the paper summary for Code Red: The Business Impact of Code Quality.
GitClear's 2024 report, Coding on Copilot, analyzed code operation trends and projected a sharp rise in code churn compared with the 2021 pre-AI baseline. Treat vendor research with judgment, but the operational warning matches what many engineering leaders now see: more generated code does not automatically mean more durable code.
The practical takeaway is simple. AI output quality is not independent of codebase health.
The debt AI amplifies
Not all technical debt blocks AI equally. These are the categories that matter most.
| Debt type | What it looks like | How AI amplifies it |
|---|---|---|
| Comprehension debt | The team cannot explain how important parts work without one specific person | AI guesses intent from code shape and misses hidden business rules |
| Undocumented conventions | "We always do it this way" lives in senior engineers' heads | AI copies inconsistent examples and reviewers rewrite the result |
| Weak tests | Tests pass but do not protect critical behaviour | AI treats green tests as proof even when they are not |
| Weak types | Important data flows through any, maps, strings, or unvalidated blobs | AI widens contracts and hides mistakes until runtime |
| Architecture drift | Multiple patterns solve the same problem in different parts of the codebase | AI picks one at random and spreads inconsistency |
| Code churn | Recent code is rewritten or deleted soon after merge | AI creates output that looks done but returns as rework |
| Large modules | One file or service owns too many responsibilities | AI cannot fit the true context into a useful working set |
This is why "garbage in, garbage out" is too soft. With AI, it becomes garbage in, more garbage out, faster.
The senior engineer smell
The clearest signal is this sentence:
"It's faster to write it myself than to brief the AI."
When your best engineers say that, listen carefully.
They are not saying the model is useless. They are saying the codebase does not expose enough context for the model to be useful. The senior can navigate the undocumented rules because they carry the map in their head. The agent cannot.
That means the missing asset is not a better prompt. It is explicit context:
- architecture notes,
- decision records,
- module-level READMEs,
- testable business rules,
- narrow interfaces,
- reliable local setup,
- examples of the right pattern,
- examples of patterns to avoid.
AI-ready codebases are not magic. They are codebases where the repo contains enough truth for an agent to operate without interviewing the senior engineer every five minutes.
Vibe coding debt is still debt
"Vibe coding" is useful as a phrase because it names a real behaviour: accepting code because the interaction felt productive, not because the result was understood.
The danger is not that engineers use AI to move faster. The danger is that they stop owning the code after the assistant writes it.
In healthy teams, AI output is draft material. The engineer still understands the change, runs the checks, reads the diff, and owns the consequences. In unhealthy teams, AI output becomes a way to bypass understanding. The code lands because it compiles and the demo path works.
That creates comprehension debt immediately. The team now owns code nobody fully understands.
Do that ten times in isolated areas and the product still works. Do it for a quarter across core systems and the codebase starts resisting change.
How to audit codebase readiness before scaling AI
Use this checklist before encouraging broad AI-generated implementation work.
| Question | Ready signal | Risk signal |
|---|---|---|
| Can a new engineer run the app from a fresh checkout quickly? | Setup is documented and reproducible | Setup requires tribal knowledge |
| Are critical business rules covered by tests? | Tests fail when money, permissions, or data flows break | QA or seniors validate manually |
| Do types describe real contracts? | Interfaces narrow what is possible | Broad any or unvalidated data shapes |
| Are conventions written down or enforced? | Linters, examples, READMEs, ADRs | "Ask the senior" |
| Are modules small enough to reason about? | Clear ownership and boundaries | Large mixed-purpose files |
| Can AI identify the right pattern from nearby code? | One dominant pattern per concern | Several conflicting patterns |
| Is recent rework visible? | Churn is measured and discussed | Rewrites are treated as normal noise |
If the answer is weak in the bottom half of this table, AI will produce more code than the organisation can understand.
What to fix first
Do not start with a heroic rewrite. Start by improving the substrate where AI is already being used.
Good first moves:
- add tests around the highest-risk workflows,
- strengthen types at API and database boundaries,
- document the conventions reviewers keep repeating,
- split the worst large modules when they block active work,
- add ADRs for architectural decisions AI is likely to rediscover badly,
- measure code churn and review rework instead of only PR count.
The goal is not aesthetic purity. The goal is making the next AI-generated change easier to verify.
Every code health improvement compounds. Better tests make agents safer. Better types make prompts shorter. Better docs reduce review explanation. Better module boundaries keep context small.
AI is a multiplier. That is only good if the thing being multiplied is healthy.
About Mavka. We score codebase health as part of the Mavka AI-readiness diagnostic: tests, types, context, conventions, module boundaries, churn, and review friction. The output is a one-page report showing whether AI will create leverage in your repo or multiply debt.
Book an audit call