[20k]

>I (and many other engineers) already automated it. My agent responds to review requests and reviews as me. Company policies enforcing human code review are futile.

This is also known as being a terrible engineer. If a company enforces human review and someone deliberately tries to circumvent this with an LLM, I'd fire that person in an instant

The reason for human code review is:

1. So *you* understand what's going on, not the LLM, and people can ask you questions about it

2. Because LLMs are not that good at code review

It seems weird to brag about literally not doing your job. It sounds like you could be replaced with a python script, what value do you bring?

[dhorthy]

blake smith has a really good post on this - that mental alignment among the team is the primary purpose of code review - https://blakesmith.me/2015/02/09/code-review-essentials-for-...

[4lx87]

That is a good post. Thank you for sharing.

I can't help but notice that this person is speaking as a programmer, not the person in charge of employing programmers. Is that what the business values code review for? In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid. And LLMs are already better than human reviewers at the "Find Bugs" part. Design and alignment with PMs and sales can happen before and after software delivery. At least that's how my employer sees it (and I suspect most other businesses).

It's a rough time to be a programmer who cares about the code, who understands software is a creative process, who understands that designing the software is intertwined with the code, who cares about systems. The hyper-focus on delivery was already a lot to deal with before LLMs.

[RamblingCTO]

I can tell you that, because I'm that person.

What I care about with my department:

- alignment on new stuff being introduced into code bases (the bigger it is, the more important to consider promixity on things the teams are working on tho). also: maybe finding a more optimal solution together, implies a proper PR process (which I always created with my teams, it takes time and we plan for that)

- code quality assessment: maintainability, regression tests, taste, security etc. etc.

- code is improved by expecting a review in the end. if you know you're not reviewed, you might rush and push out suboptimal code. hurts the baseline

Maintainability, bugs, incidents, team understanding, complexity (all impacting future delivery, uptime, user retention, onboarding etc.) are all metrics I care about as they impact the software and the company as a whole directly. A lot of CTOs or other execs/managers might not care, but there are a lot of bullshitters out there. Or maybe I'm just used to complex software in regulated/hard fields, I don't know.

[DaiPlusPlus]

> In my experience, managers enforce code review as a quality control mechanism: the "Find Bugs" step in the article's pyramid.

Nope.

To reduce it down to a single word, I'd say we do code-reviews to assess "taste".

-----

Code-review is one part of a larger process (the SDLC!), and while review does help with "finding bugs" it is not the singular reason why we do it; and other parts of the SDLC are concerned with finding bugs in the first place, namely the various Test and QA steps in the process; when your code is in the (peer) code-review step then there's an expectation that the author already identified and resolved actual bugs/defects (i.e. where actual-program-behaviour deviates from the spec[1]), so a PR for new functionality is expected to include unit and integration tests to demonstrate that.

Now Claude will gladly take a Jira ticket, write-up a plan/spec, write tests, implement the feature, verify the tests pass, address static-analysis issues, push branch, and submit the PR - and if-the-program-works then it's "correct" and so surely there's nothing really to review and so merging the changes should be a breeze... but I find myself rejecting these PRs all the time because these agents still "just don't get it"[2]. (But I'm sure they'll "get it" eventually; you can't stop progress). We can revisit this topic when we get there; but for now I'm going to reject an AI-authored PR that eschews it.

Good taste is important.

[1] I'm not going to pretend anyone actually writes any kind of spec (informal or otherwise) for the vast majority of software out there; but an unwritten-spec exists when you mentally combine a vague Jira ticket, platform-conventions and common-sense (and that's how Claude in an Agentic Loop works too, except it always has to write-out the Spec.md/Plan.md to disk first, whereas us humans keep things in our head).

[2] I cannot define "it".

[amannm]

It seems weird to get angry about a change that is happening and will continue to happen due to what the market demands from software, which I believe will be the speed/ability to solve problems, rather than its own stewardship

[20k]

I'm just here to do good software engineering and make good products. If people want to try and circumvent that process to deliberately make the product worse and slow development down, they're bad software engineers, its as simple as that

Nobody thinks its a good idea to fully automate PRs, at least not anyone with software engineering experience. It slows down your ability to solve problems if your code base is an absolute disaster

Again: If someone fully automates everything, what service do they provide? Why are they even there? Especially actively lying in the process when people are trying to force knowledge dissemination with human reviewed PRs

[computably]

Sure, if you're shipping a 500MB mobile/web app with a 5s start-up, it probably won't make a difference today, or tomorrow, or 3 months later. The problem is when your codebase is a dumping ground for AI slop and a year from now nobody can make any changes.

Also, it's not just some subjective value put in human review. If a change causes a major outage and it turns out it's because 5 reviewers were all shirking the company-mandated responsibility of review, and it could trivially have been caught, I would 100% expect those people to get fired. It's not a process issue if people are intentionally circumventing the process.

[jpollock]

There are also compliance reasons.

SOX requires code review by a second party. If the reviews are automated, the development process isn't in compliance and that can get expensive in a hurry.

[dboreham]

And of course these SOX-mandated second reviews were 99% of the time pure theater.

[bandrami]

Sort of; it's like the itemizer systems at airport security. They're entirely theater (in the sense of "for show") but that show is itself important in that it makes entire categories of attacks significantly less feasible.

Sort of like how simply having a uniformed police officer on a street corner reduces street crime significantly even if the officer never interacts with anyone.

[satvikpendem]

Or that their company does not in fact enforce human PR reviews or even encourages AI PR reviews.

[0xblacklight]

this is exactly right