alt Hacker NewsI 'love' that folks are seemingly inching slowly towards more acceptance of crappy llm code. Because it costs marginally less to produce to production if you just pass some smoke tests? Have we not learned anything about technical debt and how it bites back hard? Its not even seniority question, rather just sane rational approach to our craft unless one wants to jump companies every few months like a toxic useless apple (not sure who would hire such person but world is big and managers often clueless).
There are of course various use cases, for few this is an acceptable tradeoff but most software ain't written once and never touched (significantly) again, in contrary.
Replies
The inching-towards-acceptance of crappy processes is quite influencer-driven as well, with said influencers if not directly incentivised by LLM providers, then at least indirectly incentivised by the popularity of outrageous exhortations.
There's definitely a chunk of the developer population that's not going to trade the high-craft aspects of the process for output-goes-brrr. A Faustian bargain if ever I saw one. If some are satisfied by what comes down to vibe-testing and vibe-testing, I guess we wish them well from afar.
I wouldn't say acceptance of crappy code. I think the issue is the acceptance of LLM plans with just a glance and the acceptance of code without any code review by the author at all because if the author would waste any more time it wouldn't be worth it anymore.
People aren't interested in long-term thinking when companies are doing layoffs for bullshit reasons and making vague threats about how most of us will have to go find a new career which causes a heck of a lot of stress and financial costs. That isn't being petty, it's having self-respect. They get the quality when the companies treat the craftspeople with respect.
> 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.