Hacker News new | past | comments | ask | show | jobs | submit
It doesn't have to be that way. You can use llms to greatly improve the quality of the code. You do this by focusing on one part of the design use the LLM to explore alternatives, use it to poke holes in what you have. I think the engineering cultures that embrace this way of using AI will far outperform everyone else in the long term.
I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later - because the time to test the possible regression cases of the original code wasn't available right now.

I could have worked through all that on my own, but having the AI as a rubber duck to talk to - plus the edge cases it was able to point out - was really helpful.

> I just had a discussion with the AI recently about whether to duplicate the code something used or refactor it so both places used the same code. The decision was to duplicate the code, but make notes (and a ticket) to refactor it later

I wonder if a refactor is even necessary.

Concepts like KISS, DRY, etc. are largely human-centric. They're meant to make code easier to write, understand, and maintain - for people.

Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.

But with coding agents, some of those tradeoffs start to change. An agent can find and update duplicate implementations in seconds. It doesn't need to maintain the same mental map of a codebase that a human does.

And if we have good specifications and comprehensive tests, behavioral divergence should be detectable and correctable. In fact, duplication can offer an advantage over shared abstractions: isolation. Changes to one implementation don't risk breaking unrelated consumers of shared code, and each implementation can evolve independently.

Maybe we won't need as many high-level abstractions, or eventually even some of the architectural patterns we consider best practices today.

If the cost of writing and maintaining code approaches zero, perhaps we should optimize less for human readability and more for runtime performance, memory efficiency, isolation, and correctness.

We might even regain some CPU and memory efficiency by eliminating layers of indirection, virtual calls, and abstractions that primarily existed to make code manageable for humans.

Perhaps the optimal architecture for AI-maintained software is fundamentally different from the optimal architecture for human-maintained software.

A lot of our software engineering best practices are based on the economics/ergonomics of human maintenance. What happens when those fundamentally change?

> Duplicating code was traditionally "bad" because it increased maintenance costs, risked divergence, and added cognitive overhead for human developers.

Until proven wrong by coding agents, this is still the case even for agents. Not sure why you are assuming this doesn't apply for the machine

loading story #50373842
>because the time to test the possible regression cases of the original code wasn't available right now.

The models don't know that they're not human when they estimate. It's worth telling them that all estimates need to be made in the context of an agentic AI doing the work.

It's funny, I've had similar conversations, where the agent would recommend the 'lazy' solution because the robust one took too long. More often than not, it was assuming human-hours of work though. Once reminded that a clanker would be doing the work it's conclusion shifted to the robust one.

Now, I wonder if it actually agreed, or if it sensed that I preferred the robust solution and was trained to make me happy.

It’s jarring when the bot tells you something will take a “week of work”. A good reminder I guess that it doesn’t have self awareness as we usually think of it.
loading story #50371864
Yeah, I've seen that, too. In my case it was less about the dev time and more about the regression testing time (much of which would fall on QA and involved reading from external feeds, etc - so, complicated). But your point is fair. The AI is ... notoriously bad at LOE. Not that it's always wrong, but frequently enough (and by a large enough amount) that tradeoffs like that really need humans considering them.