Redefining Technical Debt
What became cheaper and what became more expensive in the AI coding era.
Key takeaways
- The cost structure of technical debt flipped: boilerplate, CRUD, tests, types, and docs became cheap, while over-abstraction, deep inheritance, decorator magic, and metaprogramming became expensive.
- New debt is not only "bad code" but code humans understand through local memory that AI cannot reason about from explicit context.
- DRY still protects business rules and shared truth, but when generation is cheap, premature abstraction can cost more than duplication, making WET reasonable again for unstable UI helpers.
- AI-friendly code favors explicit types, shallow call chains, locally visible behavior, behavior-describing tests, and clear boundaries between business logic, IO, and framework code.
- The debt checklist asks whether a new developer or AI can safely modify a file without oral history and whether agent instructions and project rules are versioned as infrastructure.
Technical debt still matters, but the cost structure has changed. Some work that used to be expensive is now cheap. Some code that once looked elegant has become expensive because AI cannot understand or modify it safely.
Cost Shift
Boilerplate, CRUD, tests, type definitions, and documentation became cheaper. Over-abstracted systems, implicit rules, deep inheritance, decorator magic, and metaprogramming became more expensive because they require context that AI often cannot infer.
New debt source
In the AI era, technical debt is not only "bad code." It is also code that humans understand only through local memory and AI cannot reason about from explicit context.
Example: Generic Cleverness
type PathKeys<T> = T extends object
? { [K in keyof T]: K extends string
? T[K] extends object ? K | `${K}.${PathKeys<T[K]>}` : K
: never
}[keyof T]
: neverThis can be impressive, but it is hard for both humans and AI to modify safely.
A concrete alternative can be cheaper:
function updateUserProfile(
user: User,
field: 'name' | 'email' | 'phone',
value: string
): User {
return { ...user, [field]: value }
}| Item | Clever generic abstraction | Concrete function |
|---|---|---|
| AI comprehension | Low | High |
| Local modification cost | High | Low |
| Blast radius | Broad | Narrow |
| Future change | Hidden | Explicit |
DRY Reconsidered
DRY remains important for business rules and shared truth. But when code generation is cheap, premature abstraction can cost more than duplication.
| Area | Better default |
|---|---|
| Business rules | Centralize and test |
| Configuration constants | Centralize |
| UI formatting helpers | Allow repetition until stable |
| Boilerplate | Re-generate when needed |
| Validation schemas | Domain-specific, explicit |
| Type conversions | Prefer clear local functions over magical utilities |
WET becomes useful again
"Write Everything Twice" becomes more reasonable when repeated code is cheap and premature abstraction increases context cost.
AI-Friendly Code Traits
- Explicit types and named domain concepts.
- Shallow call chains.
- Local behavior visible in the file.
- Tests that describe behavior, not implementation.
- Comments explaining why, not what.
- Few hidden side effects.
- Clear boundaries between business logic, IO, and framework code.
Debt Review Checklist
| Question | Why it matters |
|---|---|
| Can a new developer understand this file without oral history? | AI also lacks oral history |
| Are business rules explicit and tested? | AI can preserve what tests define |
| Does abstraction reduce real duplication or hide intent? | Hidden intent becomes context cost |
| Can we ask AI to modify this safely with local context? | If not, maintenance cost rises |
| Are agent instructions and project rules versioned? | Prompts and rules are now infrastructure |
Next
Read Team Workflow Change to move from individual habits to team operating policy.