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.
[–] keybrd-intrrpt 3 days ago
[–] rafaelRiv 3 days ago
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
[–] marcus_holmes 3 days ago
I cannot read a 50K LOC code base at once. I mean, obviously, I can physically do it, but I don't have the patience, etc. I need mental shortcuts like abstractions layers to hold even parts of the code base in my head. LLMs don't. They can read that in seconds and hold the whole thing in context.
[–] gadsdengrappler 3 days ago
[–] keybrd-intrrpt 2 days ago
That's an assumption.
And is that what we really care about anymore? Maybe we are ok accepting some "inefficiencies" in the code for the LLM but we get better CPU utilization or cache/RAM usage
[–] gadsdengrappler 2 days ago
So is that ;) But yeah, the link between context length and performance reduction is well researched. Automatic context management has been getting better, but it’s not a panacea, especially in very large codebases and long sessions.
> Maybe we are ok accepting some "inefficiencies" in the code for the LLM but we get better CPU utilization or cache/RAM usage
If by ‘inefficiencies’ you mean choosing hardware-friendly architectures over those that correspond to a human-friendly world model, then I would agree with you (this was already required in my domain pre-LLMs). Even still that does not stop one from adhering to DRY, KISS, etc as the abstractions required are often either free or close to free at runtime.
[–] ern 3 days ago
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.
[–] iamveen 3 days ago
Now, I wonder if it actually agreed, or if it sensed that I preferred the robust solution and was trained to make me happy.
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?