BUILD / AI & Software
AI Didn’t Kill Technical Debt. It Supercharged It.
AI-generated code and technical debt: what happens when we can build software faster than we can understand it?
We spent years trying to make developers write better code faster. Then generative AI solved the faster part almost overnight.
A developer can now sketch a feature, scaffold its components, write tests, and refactor the result before a traditional design review would have finished. That is genuinely useful. It is also an uncomfortable inversion: we can generate code faster than we can properly review, understand, test, and maintain it.
The result is not that AI automatically produces terrible software. Nor is it that every generated line becomes debt. The more important change is economic: the cost of creating software is falling faster than the cost of understanding it.
01 / Definition
First: what technical debt actually is
Technical debt is the future cost created when a decision prioritises what is faster or easier now over what will be easier to change and maintain later. The metaphor, coined by Ward Cunningham and developed in the engineering literature, describes the extra effort we pay whenever today’s shortcut makes tomorrow’s work harder. Martin Fowler calls that extra effort the “interest” on the debt in his useful overview of the technical debt metaphor.
Debt is not simply “bad code”. A conscious shortcut can be a rational product decision when the team understands the trade, limits its reach, and has a plan to revisit it. The dangerous kind is invisible debt: a growing set of assumptions, inconsistencies, and fragile dependencies that nobody chose and nobody quite owns.
02 / Evidence
Is AI actually creating more technical debt?
The honest answer is: it can, and we now have meaningful evidence of the mechanism—but not proof that every AI-assisted codebase is worse than a human-written equivalent.
In March 2026, researchers analysed 304,362 verified AI-authored commits from five widely used assistants across 6,275 public GitHub repositories. Their large-scale empirical study used static analysis before and after each commit to attribute newly introduced code smells, bugs, and security issues. It found 484,606 distinct issues; code smells accounted for 89.1% of them.
| Finding | Measure | Why it matters |
|---|---|---|
| 304,362 | Verified AI-authored commits | A large real-world sample, not a prompt benchmark |
| 6,275 | Public GitHub repositories | The findings span many active codebases |
| 484,606 | Distinct issues attributed | Bugs, security issues, and code smells were measurable |
| >15% | Commits introducing an issue | The threshold was crossed by every assistant studied |
| 24.2% | Tracked issues still present | Some AI-introduced issues survived to the latest revision |
It is the share of tracked AI-introduced issues still present in the repositories’ latest revision. It does not mean AI creates “24% more technical debt”.
The sample also has boundaries worth naming. It covers public repositories and commits where assistant authorship could be verified. It cannot see private enterprise systems, code copied from a chat without provenance, or generated work that was discarded before commit. And issue survival is not the same as hours of maintenance cost. The research is strong evidence of observable problems, not a complete balance sheet for AI use.
Static analysis can detect useful signals, but it cannot fully judge whether a system models the business correctly, fits its architecture, or will be understandable during an incident. The study is neither an apocalypse nor a quality certificate. It shows that measurable problems are entering real codebases at scale, and a meaningful share are not disappearing on their own.
03 / The shift
Why AI makes familiar debt feel different
Technical debt existed long before copilots. AI changes its shape by changing throughput, authorship, and the distance between a code change and the person who understands why it exists.
It also lowers the threshold for adding one more layer. A helper that once felt too expensive to write, a second adapter that avoids learning the first, or a bespoke abstraction for a single edge case can now appear in minutes. Each addition may be defensible. Together they increase the surface area every future developer—and every future model—must navigate.
The review bottleneck
Generation scales almost instantly; careful review does not. Large outputs can make plausible-looking code the default before anyone has tested its assumptions.
Local correctness
A change can compile and pass its tests while duplicating an existing abstraction, breaking an ownership boundary, or introducing a second way to solve the same problem.
Unfamiliar code
When people accept more code than they can explain, the organisation gains output without gaining equivalent knowledge. That gap appears later in debugging and change.
Delayed consequences
Shallow tests, unnecessary dependencies, and inconsistent patterns often look inexpensive at creation time. Their cost arrives when the system must evolve under pressure.
Context is the fault line running through all four pressures. Repository-aware tools can retrieve more code than a blank chat, but access to files is not the same as understanding a system’s history. Architectural decisions often live in incident reviews, abandoned experiments, customer constraints, and the judgement of people who remember why an obvious-looking option failed. A model can produce a locally elegant answer while missing that organisational memory entirely.
04 / Judgement
AI does not replace engineering judgement. It moves it downstream.
Google’s 2025 DORA research describes AI as an amplifier of an organisation’s existing strengths and weaknesses. Greater AI adoption was associated with higher delivery throughput and product performance, but also lower delivery stability. Faster change magnified the quality of the system around it.
This is the central management lesson. AI can reduce the labour required to produce a change, but the saved effort does not vanish. Strong teams reinvest it in sharper constraints, smaller reviews, better tests, operational feedback, and shared understanding. Weak systems simply push more change through the same fragile controls.
Review capacity is not elastic. When generated output expands but experienced attention does not, teams face a quiet choice: review more shallowly, queue work for longer, or narrow the amount generated at once. The answer is rarely another blanket instruction to “use AI responsibly”. Teams need explicit limits on change size, ownership, acceptable dependencies, and the evidence required before a change can move.
The scarce engineering resource is no longer code production. It is confident understanding.
05 / A working test
Run every AI-assisted change through the debt test
Treat AI-generated code as the beginning of an engineering decision, not the end of a prompt. At each stage, ask one question that keeps comprehension moving with production.
None of these questions is a box for the model to tick. Each needs a human owner and evidence proportionate to the risk. A small internal script may need a readable diff and a few behavioural tests. A permission boundary or payment flow needs deeper review, threat modelling, release controls, and monitoring. The principle is consistent even when the ceremony is not: cheap generation must not make consequence invisible.
- Generate
Did we define the boundaries before asking for code?
- Review
Can an owner explain the change without leaning on the prompt?
- Test
Did we test behaviour, failure modes, and edges—not just the happy path?
- Release
Is the change small, observable, and easy to reverse?
- Operate
Will we notice if it raises errors, latency, or support demand?
- Maintain
Can the next engineer safely change it six months from now?
06 / Practice
Eight habits that keep speed from becoming drag
Give constraints, not just tasks.
State ownership boundaries, approved dependencies, security needs, performance limits, and error semantics before asking for an implementation.
Keep the change small.
Small batches are easier to understand, test, reverse, and learn from. DORA identifies working in small batches as a critical countermeasure to AI-related instability.
Ask for the architecture explanation.
Require the model—and then the human owner—to explain where the change fits, what it reuses, and which trade-offs it introduces. Treat that explanation as a claim to verify.
Review it like a stranger wrote it.
Plausibility is not provenance. Check the diff, existing conventions, data flow, failure paths, permissions, and dependency choices with the same care as an unfamiliar PR.
Test behaviour and edges.
Test the promise the feature makes: empty states, invalid input, retries, concurrency, permissions, and recovery—not only the path demonstrated in generated tests.
Do not let code establish architecture by accident.
A generated pattern becomes precedent the moment it is copied. Make decisions about abstractions and boundaries explicit before repetition turns them into policy.
Track rework and instability, not lines produced.
Watch rollback rate, escaped defects, review time, support demand, and repeat edits. Keep prompts and AI configuration in disciplined version control when they shape production work.
Pay debt down while the context is warm.
Record intentional shortcuts, assign ownership, and schedule the clean-up close to the change. A backlog entry without a trigger or owner is not a repayment plan.
These habits are not an argument for rebuilding old bureaucracy around a faster tool. They are a way to spend attention where it has the highest leverage. If AI removes thirty minutes of typing, using ten of those minutes to reduce the diff, inspect a boundary, or add a meaningful failure test is still a net gain. Speed is useful when it shortens the whole path to a safe change, not just the path to a plausible first draft.
07 / Conclusion
The advantage is not generating the most code
AI did not make technical debt obsolete. It changed the rate at which we can take it on—and made it easier for that debt to arrive wrapped in code that looks polished, tested, and ready.
The organisations that benefit most will not be the ones that generate the largest volume. They will be the ones that keep understanding, ownership, and feedback close to every change. The future of software may involve far more generated code. It still depends on people who can explain why that code belongs.
This is not a case against AI-assisted development. Used inside a healthy engineering system, it is extraordinary: it can expose options, remove repetitive implementation work, help people learn an unfamiliar API, and make small improvements affordable. But the tool earns its place by improving outcomes, not by maximising output. The test is whether the software becomes easier to trust and evolve after the novelty of generation has passed.
Sources & further reading