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.

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.

> 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".