According to the O'Reilly Radar blog, "code review is an expensive way to do something that may not be all that useful in the long run". We just have to get the specifications right in our vibe-coded future.

https://www.oreilly.com/radar/beyond-code-review/

@corbet would it be mean of me to say this guy should have his paragraph lengths reviewed? :)) hard to read.

But seems it's a sort of trick question in a way 'using methodology X would somehow render code review unnecessary but methodology X would be so cumbersome as to be not useful'.

Or so I guess from a scan

@corbet Sure. As soon as GenAI reliably, reproducibly, deterministically, consistently, completely, and coherently translates those specifications from natural language into machine code.

@corbet Being published by O'Reilly used to be a mark of quality. How the mighty have fallen!

@corbet the temptation to me on "getting the specifications right" as a review process is it doesn't matter how code was written. Does the developer understand the brief and can they explain their solution to me? If they can't, that's the problem. Pre-AI, that would mean they copied from somewhere else.

@corbet I agree that article is pretty BS. Consider "Understanding someone else’s code is harder than understanding your own, and understanding machine-generated code is harder still." Wrong: the only task at which ML models I've encountered excel is writing documentation. Copilot's suggested commit messages and code comments are usually better than mine, and I always tried to do a good job.

An important function of code review is inducing the reviewer and code author to come to agree on requirements. Author: "Here's what you asked for, with tests that match your requirements." Reviewer: "That's not what we need." Having code generators will not mean that Engineering and Product do not need to talk.