AI makes tech debt more expensive
Generative AI coding tools appear to work best on clean, modern codebases that follow common patterns, while struggling with mature systems full of edge cases, legacy frameworks and poorly documented “scars” from real-world requirements. Many engineers report that LLMs are valuable for boilerplate, tests and small refactors but unreliable for complex logic, unfamiliar stacks or deep architectural changes, raising fears that AI-generated code could accelerate the accumulation of technical debt. Others counter that careful use, strong tests and better modular design can let teams benefit from AI on both new and old systems, but warn that it won’t magically erase existing complexity.
AI, Tech Debt, and Codebase Age
- Many agree: AI tools work best on “young, clean, idiomatic” code and struggle with legacy systems full of edge cases and non‑standard patterns.
- Others argue that what’s labeled “tech debt” is often maturity: accumulated fixes and “scars” from real-world bugs and business quirks, not just mess.
- Some say AI doesn’t make tech debt more expensive per se; it just delivers less benefit in high‑debt environments.
Speed vs Quality in Early Stages
- Debate over whether early-stage code “must” be messy to move fast.
- Several argue high-quality code is actually required for sustained speed; cutting corners only gives a brief boost before slowing you down.
- Others note that “clean” young code often just lacks edge cases; complexity grows as real users push requirements.
LLM Strengths and Weaknesses
- Widely seen as strong for: boilerplate, scaffolding, rote transformations, basic tests, small functions, refactors within clear interfaces.
- Weak for: novel or weird architectures, complex legacy logic, devops/config in fast-moving ecosystems, and deep reasoning about subtle edge cases.
- People report frequent “demo-level” solutions: missing pagination, incomplete edge handling, overcomplicated dependencies, or superficially correct but subtly wrong code.
- Many treat LLMs as “smart but unreliable juniors”: helpful, but everything needs review.
Rewrites, “Scars,” and Maintainability
- Strong caution against full rewrites: old complexity often encodes hard-won bug fixes and business logic.
- “Scars/warts” are seen as necessary complexity; removing them without understanding why they exist leads to rediscovering old bugs.
- Good tests and documentation (especially “why” decisions were made) are highlighted as the real enablers of safe refactoring—human or AI-driven.
Productivity, Workflow, and Hype
- Some report real productivity gains, especially in test generation, yak‑shaving tasks, and cross-language snippets.
- Others find verification and debugging of AI output negates any time saved.
- Skepticism about the article’s thesis and about broader AI hype is common: claims of “AI transforming software” are seen as premature, with current tools closer to advanced autocomplete than a solution to tech debt.