Asserted confidently without a shred of proof

the thesis of the post is that this is not true. fable can solve more problems but for complex systems it is not sufficiently diligent that you can turn the lights off.

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.

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

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

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.

> The role of a software engineer is foremost about the ownership of software systems, and secondarily about modifying them or developing new ones.

Yes! That's sooo accurate. Tools you use change, the level of abstraction you operate changes, but the role remains.

Before LLMs, "organizations" have seen code review as multiple things:

  * Share knowledge about a particular area of the codebase between multiple people
  * Share overall engineering knowledge between the parties in the review
  * Ensure maintainability of the codebase long-term
  * Ensure readability of the code
  * Catch architectural/directional omissions (yes, from the planning/architecture phase) before it's really too late and non-reversible change goes in (eg. large destructive DB schema change)
  * Ensure changes are small, self-contained, and as often as possible, reversible
  * Do some basic manual QA
  * Do comprehensive integration testing with a fully built-out system
  ...
  * And yes, catch bugs before they hit production.

Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).