Technical Debt

In the AI Story

AI produces a new variant of technical debt, specific to AI-generated codebases. In team-based development, technical debt accumulated because different team members made different assumptions, or because expedient shortcuts were taken deliberately under schedule pressure. In AI-augmented development, technical debt accumulates because different prompts produce different local optima, and the local optima do not compose into a global optimum. Each prompt produces a locally competent component. The components do not share architectural assumptions, because the AI does not maintain a persistent architectural vision across prompts unless the builder provides one.

The builder who does not maintain a concept document — who does not evaluate each AI-generated component against a consistent architectural vision — accumulates this debt invisibly. The code compiles. The components work. The system functions in the cases the builder tested. The debt surfaces when the system must be modified, and the modifications reveal that components do not fit together in the way a coherently designed system's components would. At that point the maintenance cost explodes, because understanding the system requires reconstructing a coherence that was never there.

This AI-era debt is harder to detect than traditional technical debt. Traditional debt was often visible in the code itself: shortcuts were marked with comments (TODO: fix this properly), hacks were known to the person who wrote them, and experienced reviewers could spot the patterns. AI-generated debt is invisible at the code level because each component is locally competent. The debt exists only in the relationships between components — in the assumptions that one component makes about another, assumptions that the AI did not explicitly articulate and that the builder, not having written the code, does not know.

The architect's notebook is the primary instrument for preventing AI-era technical debt. An explicit concept document, maintained throughout the project, forces the builder to articulate the assumptions each component should respect and provides a standard against which new components can be evaluated. Without the notebook, the debt accumulates silently. With the notebook, the debt becomes visible and manageable, though not eliminated — the notebook itself can become out of date, and maintaining it requires discipline that the AI's speed makes easy to skip.

Origin

Ward Cunningham coined the term in his 1992 OOPSLA paper The WyCash Portfolio Management System, using it to explain to managers why his team was spending time on refactoring rather than on new features. The metaphor spread quickly through the software engineering community and became standard vocabulary by the early 2000s. Its AI-era variant emerged in 2024–2025 as teams began cataloguing the specific patterns of incoherence in AI-generated codebases.

Key Ideas

The metaphor makes invisible costs visible. Financial language communicates to non-technical stakeholders what technical language could not.

Well-managed debt is rational; unmanaged debt compounds. The discipline is documentation and systematic paydown, not debt avoidance.

AI produces a new debt variant. Local optima from independent prompts do not compose into a global optimum without explicit architectural direction.

AI-era debt is invisible at the code level. Each component is locally competent; the debt lives in the relationships between components.

The architect's notebook is the primary preventive instrument. An explicit concept document makes architectural assumptions legible and evaluable.