undefined

points

[-]

Quality code is easy to make changes to. What makes terrible code terrible is that changes become harder and harder to make over time. LLMs haven’t solved this, but the marketing acts as if it has, and many engineering orgs seem to have instantly forgotten the things we’ve learned from the last few decades of building software.

Yes you can have your agents do refinement and refactoring. If you don’t know what they’re doing when they are doing that, they can and do introduce massive churn. The “build it fast and fix it later” crowd seemingly has never had to actually go try to fix it later, or dealt with production incidents when people have no idea how their code works. These folks are frequently promoted fast for their “productivity” and massive promises by clueless management and move on to let others have to clean up their stuff.

by lelanthran1 hours ago|

prev|

[-]

> Even on personal projects, if I go through a few major features without reviewing the code, I always end up doing massive revisions that steal hours of my time and fill me with rage in the process.

Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).

Talk with an LLM, ask them to rate both code and estimate dev experience based on that code, and you will see what they value: Code that passes all the tests is a 10/10, while a codebase designed with opaque data types, Parse-Don't-Validate for all data, isolated interfaces, a built-for-replacement-not-for-extension philosphy will get a 6/10 because an out of bounds error was found.

IOW, they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way - we very highly value code that is easy to maintain, even if they do have a few errors picked up by the linter.

by zem48 minutes ago|

parent|

[-]

I have found that claude (opus 4.8 and 5) can do a very good job of implementing good architecture and system design if I can just steer it right. left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code, claude will go do it the right way, and can even have a pretty sensible discussion about the tradeoffs involved. so it does know about good code architecture and patterns, it just doesn't have the taste and initiative to use them without being told.

by lelanthran38 minutes ago|

parent|

[-]

> left to its own devices it does produce less than optimal code, but if I just spend a few minutes explaining how some pattern will improve the code,

But that requires actually reading the output, which I am pretty certain only a rounding error of programmers are doing at this point.

by re-thc59 minutes ago|

parent|

prev|

[-]

> Where LLMs excel is in code-level bugs (as opposed to system bugs, design bugs, architecture bugs, integration bugs, etc).

Blame the benchmarks game. They're optimizing for that and that's what those things are measuring.

by jve2 hours ago|

prev|

[-]

> saves much time

Reviewing and reading everything makes this feeling, yeah.

However where I can say 100% it saves time is discovery by answering these questions:

  - At what state does bug X manifests?
  - Explain how integration/feature works.
  - I want to integrate with system X: Audit what items/features are used and what model changes are needed on my side

by recursivecaveat2 hours ago|

prev|

[-]

I'm genuinely not convinced it actually saves time once a full accounting has been made. You get the initial result faster, but then you inflict a super slow and torturous review process on yourself or a teammate. Even if the review manages to bring it up to parity, over time you will keep slowing down as more and more code was never written by the humans directing the agents, so their understanding decays.

I at least give the new interns a stern warning: it is easy to speed yourself up by slowing others down if you pump a lot of slop.

by whstl2 hours ago|

parent|

[-]

My team experimented with re-writing from scratch the prototype of complex functionality made by a non-engineering vibe-coder from another team. We didn't look at the code, and barely looked at the result.

It took about 4 days to get a production-ready reviewed code, while it took them 2-3 months to deliver something that another team judged "impossible to review".

The PR for the prototype was closed.

It helps that I'm a domain expert here, as I have a minor degree in the domain, so I can judge better. But the discrepancy is just too high to ignore.