|
|
|
|
|
|
by topherhunt
37 days ago
|
|
|
I don't buy the math here because it seems to only model half of what AI coding agents do. The entire argument treats AI as a code-generation accelerant -- more output, therefore more maintenance burden, therefore compounding debt. But in my experience (solo dev, ~30k LOC apps), Claude Code has decimated my maintenance costs. I throw broken tests at it. I use it to diagnose bugs, trace data flows, reason through unfamiliar code, and refactor when things get unwieldy. AI isn't just a faster typist -- it's a faster debugger, reader, refactorer. Modeling AI's impact on codebase growth without modeling its impact on maintenance speed seems like a very selective way to model the future. The maintenance cost curves cited here come from pre-AI dev data; using them to predict post-AI outcomes assumes the answer to the most important question (does AI reduce per-line maintenance cost?) rather than investigating it directly. Nobody has nine years of data on this because halfway-decent coding agents have existed for < 6 months. I like the cautionary advice -- watch out for how much maintenance burden you're incurring with all that delicious AI code slop, folks -- but I don't think his confident quantitative predictions ("gains erased after 5 months") are justified. Am I missing something obvious here? |
|
|
Some of the maintenance costs you mentioned are primarily read-only, slam dunk AI use cases. Input from AI to diagnose bugs, trace data flows, and help with reasoning. Tests are something of a gray area in the sense that they are not read-only but they don't affect the logic of the app itself.
The "write" use cases (you mention refactoring and the author seems to primarily focus on writing code) is where the author's point seems to be primarily aimed at.
Definitely agree on the read-only improvements to maintenance. Those are unquestionable slam dunk, high value improvements.