Hacker News Reader

Comment by dominotw | Hacker News Reader

> I think senior engineers find it very difficult to give up on line-by-line review

i am pretty senior. I hate code reviews so much. They are so boring, easily the most tedious part of my job. Its such a chore. Who is clinging to line-by-line review. Ppl dont really give that much about their employers.

View on HN

You don’t sound very senior.

Code review isn’t a quality gate, it’s a way to maintain shared understanding of a codebase.

Throwing out code review is equivalent to throwing your hands up and saying you don’t need to understand anything about what your code is doing in its black box.

I don’t think anyone on this forum is half as smart as they think they are, especially in terms of systems engineering a black box solution. Myself included. Someone needs to understand what’s going on inside the Widget Factory until we have full Artificial General Intelligence.

>Throwing out code review is equivalent to throwing your hands up and saying you don’t need to understand anything about what your code is doing in its black box.

I think that is what the C-suite is currently wanting out of our engineers. Prompt, don't write, maybe read a bit, don't stop, ship, ship, ship.

This will vary by company focus and size, but sometimes the C-suite just doesn't want to believe that software-engineering has important overlap with business-analysis or product-design.

Is the C-suite ready to sack the engineers and prompt Claude themselves with their business requirements? Why not cut out the middlemen if that's how they now perceive engineers?

If they can do that, why doesn’t someone else do it first, for half as much money? What’s their moat if their business can be replicated with a few prompts?

doesnt mean its not boring

I initially pivoted to fully automated code reviews, sometimes with a brief skim of things. I've been shifting back to mostly manual review. In the background I'll also run some agentic scans, and once I'm done I'll look to see what the agents had to say. And then I go back in by hand armed with that knowledge and verify it & come to my own conclusion.

Why? Because I started to run into way too many AI generated messes in codebases. The agents are really good at some things and complete ass at others.

So you’re not writing the code, and you’re not reviewing the code…

What exactly would you say it is you do around here?

where did you get that i am not reviewing code? ironically this is an example of some ppls' brain falling apart even reading a 3 english sentences so you can only extrapolate how bad they are at reviewing code.

> Who is clinging to line-by-line review.

It really depends on the context. A react button background color - meh - the critical part of the backend where a new 300ms delay will cost the company millions then yeah.

> new 300ms delay will cost the company millions

these might be 1% typically

> the critical part of the backend where a new 300ms delay will cost the company millions then yeah.

If it is so critical, why don't we have tests and benchmarks for it?

Oh right, because "Greg the super-coder" never wrote any of this down and it lives in his head so he can be the arbiter of change.

It was toxic before agentic coding, it's still toxic now.

Document your systems. Add tests and benchmarks for what is important.

We've always known this, we have a dozen or more textbooks written about it. But we always gave it a pass because "Greg the super-coder" was producing more value than he was hurting.

That's no longer the case. Your best coder is now Opus or Astra

Good thing you reviewed the PR so you could catch the gap in Greg’s documentation and force him to write it before approving his PR!

> Your best coder is now Opus or Astra

No, that's our _fastest_ coder, which is a different thing than _best_

> If it is so critical, why don't we have tests and benchmarks for it?

Thats a fair point, but Ive seen LLMs modify the surrounding environment to “pass the test”

A human still has to be responsible at some point.

> he critical part of the backend where a new 300ms delay will cost the company millions then yeah.

If a performance regression like this isn't caught by an automated testing suite, you have made a horrible mistake.

Reviewing the PR gives you a chance to identify this gap in the performance regression suite.

The agent could also do that part while its still in draft. If the rigorous tests already exist of course.

Absolutely. And also the idea that this is somehow the last bastion against introducing bugs? Maybe run a test

> Maybe run a test

One of those things made of code that we should neither be writing nor reviewing? Shouldn't I just assume that the LLM did that or whatever?

I also hate reviewing my own ai generated code. Worse; it’s impossible for me to keep focus. So I created a skill to keep it interesting. It’s nothing more than a prompt that asks the ai to ask me questions about the code. Starting at high level, like ‘Describe the core responsibilities of X, Y, and Z in a sentence or two. From that it goes deeper. It is also instructed to summarise based on my answers. If I give a wrong, or vague answer it will flag it as code that might be problematic.

Mostly, this helps to keep me focused and really understand the code. It’s not perfect. On two occasions a secondary human review found a critical bug, like calling a non-user-facing endpoint (but with similar name).

I hate code reviews, but I owe it to my coworkers that I know will read my PRs to review my own generated slop line by line. Most of these agents are still overly verbose and I'm in a situation where no, not every single edge case is relevant enough to warrant the additional loc or complexity introduced.

Reply on news.ycombinator.com