Comment by rico735 | Hacker News Reader

Comment by rico735 | Hacker News Reader

Parent Full thread

That's not really my point... my point is that it's an unsettled debate between speed and caution, and devs are not unanimous on it, unlike the claim of the original post that seemed to think everyone was reporting the same gains.

The divide with developers at the moment seems to be about people who believe in review & are being cautious (who are not seeing major time gains according to all reports I have seen), and those who trust it to be able to fix things forever and will no longer have to worry about understanding the code, so are happy to atrophy those skills.

Yes, my code will have mistakes, and I'll use LLMs for some tasks. I also review and have a mental model, which means I can easily fix them, no matter what happens in future with AI. Reviewing also means I'm seeing the limitations and common mistakes of LLMs.

A no-review approach will be far faster than this, obviously, but if scbench.ai is still true on the frontier models, it may come back to bite people when they have no idea how it works and the context becomes too big to maintain.

I think a big part of that divide is between the people who are inherently limited by other factors on the rate of change they can implement.

If I'm being snarky - the people who are happy to run without reviewing the code probably mostly are able to because there isn't significant value attached to it downstream. Not many stakeholders, not high value transactions, not complex downstream integration or impact. And yes, in their friction free lives, AI can massively accelerate things far beyond what it can do for the rest of us. But don't infer that applies everywhere else where those assumptions don't hold.

Would disagree on the terminology, but not the spirit.

I’m sure people are building things that have specific KPIs based on client preferences. As long as those preferences are being met, then their question becomes “why does it matter what the code quality is?”

Perhaps it’s simply liability and penalties? If getting something wrong means your client is going to sue you into oblivion, then perhaps that is where people are focused on making sure its right, as opposed to making sure its fast?

Poor code quality degrades your ability to make future changes without breaking things. Maintenance is the common and I think correct metaphor: the precise location of all the bolts in a machine won’t be part of even the most detailed requirements spec, but if there’s any components you might want to replace in the future you’d better make sure you have non-destructive access to them.

Yup. Also code review is not just there to check your work. It's forced communication, in that at least someone else knows about the changes you're making.

It's also a critical part of your security model. "Nobody can deploy code by themselves" is shockingly effective at preventing rogue actions.

Speaking of communication... Almost no one mentions talking to non-devs. That's one of the reasons I can't just rely on any of these tools, I have to remember and understand everything well enough I know how they work and can explain things and help plan ahead when talking to product people in meetings.

just tell them to point their agents at it /s

Asking AI to review my code is actually pretty useful... but makes the process slower.

Reply on news.ycombinator.com