top | item 47136287

(no title)

ap99 | 5 days ago

Code has a generation cost and a maintenance cost.

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.

discuss

order

kakacik|5 days ago

I '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.

Majromax|5 days ago

> 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.

kranner|5 days ago

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.

pdhborges|5 days ago

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.

hnthrow0287345|5 days ago

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.

neilwilson|5 days ago

Once writing code is cheap you don't maintain code. You regenerate it from scratch.

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'm not sold on that idea yet.

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

Unless the specification is also free of bugs and side effects, there is no guarantee that a rewrite would have fewer bugs.

Plenty of rewrites out there prove that point.

jimbokun|5 days ago

Tokens aren’t free.

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.