(no title)
ap99 | 5 days ago
If you just look at generation then sure it's super cheap now.
If you look at maintenance, it's still expensive.
You can of course use AI to maintain code, but the more of it there the more unwieldy it gets to maintain it even with the best models and harnesses.
kakacik|5 days ago
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.
Majromax|5 days ago
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.
kranner|5 days ago
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.
pdhborges|5 days ago
hnthrow0287345|5 days ago
neilwilson|5 days ago
What you maintain is the specification harness, and change that to change the code.
We have to start thinking at a higher level, and see code generation in the same way we currently see compilation.
simonw|5 days ago
I don't just have LLMs spit out code. I have them spit out code and then I try that code out myself - sometimes via reviewing it and automated tests, sometimes just by using it and confirming it does the right thing.
That upgrades the code to a status of generated and verified. That's a lot more valuable than code that's just generated but hasn't been verified.
If I throw it all away every time I want to make a change I'm also discarding that valuable verification work. I'd rather keep code that I know works!
manuelabeledo|5 days ago
Plenty of rewrites out there prove that point.
jimbokun|5 days ago
Far more expensive than compilation and non deterministic so you’re not sure if you will get the same software if you give the AI the same spec.