Hacker News Reader

Comment by DanHulton | Hacker News Reader

I’ve caught bugs in code reviews before, but I would agree that it’s probably not the most crucial thing you should strive to do with code reviews.

That said, I think I’ve done a tremendous amount of PREVENTING bugs from being introduced via code review. Caught all kinds of weird code patterns, duplication, wrong levels of abstraction, etc. Essentially, the kinds of places that bugs like to hide and grow in.

I still think that’s valuable, and it’s the kind of thing that models generally aren’t great at, to this day. It generally relies on having a large amount of context about the project and about what’s being solved, so if you wanted to do this via automated review, you maybe COULD, but it would probably get pretty expensive, especially on larger projects.

View on HN

At another level, code reviews also give you the time to really think about what is being built and why. I've often come across looming architectural or strategic failures simply by having to stare at a bunch of code and wonder why it works a certain way. Same goes for writing the code by hand too, though it's harder to see past your own biases and ideas sometimes. I find code reviews deeply valuable for myself and my team.

So - I've done this just by reading LLM code. I mean, yes I'm largely looking for high level architectural smells and bad practices, but I feel like "reading the code" now takes on a lot of the previous roles that code reviews may have done.

I just don't do this at commit time. I might make 100 commits and then dig through code and find some bad architecture stuff.

It's very useful, and actually kind of critical for the way I find code reviews valuable. If the person hasn't reviewed their (agent's) code before I get to see it, then I'm not really talking to that person about their architectural or design ideas, they're just the 'meat proxy'. The agent isn't going to develop deeper opinions about the project and product, and neither is the person if they didn't read the code before review.

It's these kinds conversations and constructive challenging of ideas that I worry for the most when orgs talk about reducing code review bottleneck.

> Essentially, the kinds of places that bugs like to hide and grow in.

I like an ecological-framing, especially as systems get more complex.

Yes, I could hunt cockroaches all day, but it would be even better to have caught how the new wall was missing a metal screen over a low ventilation opening.

I agree with this but the point that I'm making is that there's a huge delta between "I have prevented bugs in code review" or "I have implemented best practices in code review" to "Code review is the line by line gate which prevents bugs"

Reply on news.ycombinator.com