alt Hacker News> Have we not learned anything about technical debt and how it bites back hard?
I think LLMs are changing the nature of technical debt in weird ways, with trends that are hard to predict.
I've found LLMs surprisingly useful in 'research mode', taking an old and badly-documented codebase and answering questions like "where does this variable come from, and what are its ultimate consumers?" Its answers won't be as natural as a true expert's, but its answers are nonetheless useful. Poor documentation is a classic example of technical debt, and LLMs make it easier to manage.
They're also useful at making quick-and-dirty code more robust. I'm as guilty as anyone else of writing personal-use bash scripts that make all kinds of unjustified assumptions and accrete features haphazardly, but even in "chat mode" LLMs are capable of reasonable rewrites for these small problems.
More systematically, we also see now-routine examples of LLMs being useful at code de-obfuscation and even decompilation. These forward processes maximize technical debt compared to the original systems, yet LLMs can still extract meaning.
Of course, we're not now immune to technical debt. Vibe coding will have its own hard-to-manage technical debt, but I'm not quite sure that we have the countours well defined. Anecdotally, LLMs seem to have their biggest problem in the design space, missing the forest of architecture for the trees of implementation such that they don't make the conceptual cuts between units in the best place. I would not be so confident as to call this problem inherent or structural rather than transitory.
Replies
> taking an old and badly-documented codebase and answering questions like "where does this variable come from, and what are its ultimate consumers?"
Why do you even need an LLM for this? Code is formal notation, it’s not magic. Unless the code is obfuscated, even bad code is pretty clean on what they’re doing and how various symbols are created and used. What is not clear is “why” and the answer is often a business or a technical decision.
None of what you describe is free.
After the LLM helps untangle the mess, if you leave the mess in place, you will have to ask the LLM untangle it for you every time you need to make a change.
Better to work with the LLM to untangle the technical debt then and there and commit the changes, so neither you nor the LLM have to work so hard in the future.
I’ve even seen anecdotal evidence that code that’s easier for humans to work with is easier for LLMs to work with as well.