Extremely valuable. It's the best way to transfer knowledge among engineers and control damage.

It's more vital in bigger teams and teams that have something in production, used by a lot of people. A bad push breaks things on multiple levels, and the damage is multiplied by number of users. One person making two build breaking mistakes a year in a team of about 25 would break the build every week - CI/CD and auto review catches some of this, but PRs are good at catching the obvious.

Plus regressions. I've been commenting that "this line prevents the logo printing bug for PNG in HN-1345". Often people don't know why the line is there and why it looks funky. But the new era hates comments. So we're reliant on humans who have faced bug HN-1345 to remember. In some cases, they've faced similar bugs in other jobs.

I think most places overdo it though. 80-20 rule. Less than 20% of time should be spent on this. Most should be automated.

I just check that it works. That it does what it should. That there's no gotchas ("triBeep() rings at 3 frequencies, not three times"). That it's not an architectural problem ("we don't put strings in the async because it leads to a memory leak and/or makes translations harder in the future")

There's some quality control, but it often involves the above - don't name functions triBeep() and so on. Code style should be controlled by the linter.

I never comment on whether it should be onChange vs onChanged, this is all bikeshedding and doesn't prevent bugs or increase productivity.

Human reviews do still matter a lot. our goal is to speed this up, not replace it completely with AI reviews.

I think AI should complement the human review, not replace it, and I think everyone already agrees with me on this.

The problem with AI reviews, is that they add a lot more text to read, the PR description is another wall of text, test steps are very verbose, most comments are just noise.

I believe AI should instead help pointing the dev to the important stuff and help identify noise, this would actually make the review go faster.

since the introduction of AI, the bottleneck for shipping code shifted from producing code to reviewing it, and the PR reviewing experience on Github is lackluster, leaving a lot to be desired.

my team now ships too much code and it sits in review for too long, reviewing AI code is not easy and we need a better tool to review code, especially on large PRs, Github no longer meets my needs or use cases so I had to build something myself.

I got frustrated enough that I built my own reviewer around this idea: instead of adding commentary, it groups files into folders by complexity, surfaces the handful of changes that actually need deep review, and marks the mechanical noise so you can blow through it. On migration PRs it cut my review time down a lot.

With AI shipping code quickly we got to some of the long awaited migration work that we wanted to do long ago. And now we're pushing PRs with 10K and 20K lines of code. And that actually helped speed up the review process immensely. Instead of AI adding a new summary article, it just helped me to identify the noise and the repeated patterns. In these migration PRs and skim them quickly, then focus on the important parts of the migration that need a closer look. Since all these files are grouped now, I can just toggle a whole folder as viewed so I can focus on leaving comments on the other files and addressing them while not affecting the parts that are already viewed in the PR. That also made the feedback loop more efficient.

I can share more if people are curious, I'd rather not turn this into an ad.

Not really. Especially with LLMs. Most engineers have a backlog of reviews. I'd much rather focus on building great test infrastructure, and ways to verify test results.