Code review outgrows the diff, and verification is the job left without a home

The New Stack has published an argument that code review has outgrown the diff: AI writes thousands of lines in minutes, and there is no way engineers keep up with reviewing them ^[1][3]. That leaves two default failure modes, and both are already running in production somewhere: skip review and risk shipping slop, or review everything and become the bottleneck ^[4].

The piece's useful move is to stop treating review as one activity. It lists three jobs that remain after you strip out line-by-line inspection: collaboration, where a team decides what belongs in the product; alignment and knowledge sharing, which builds shared context and carries institutional knowledge for both people and agents; and verification, meaning is the code correct, will it work, what is the risk ^[6]. The article's framing is that the original assumption -- review exists to catch bugs -- was always wrong, and the real work is taste, judgment, and applying organizational process ^[2]. As one quote in the piece puts it, "Code is the medium, but the review is where we exercise judgment, and it's still important" ^[8].

Note what that list does to the argument. Collaboration and alignment are precisely the things a diff-reading pass never did well. Verification is the one thing it did do, and it is the one that breaks first when volume grows faster than the supply of reviewers ^[7].

The two proposed paths both address the first two jobs. One is to collaborate on the genuine artifact instead of front-loading PRDs and architecture documents, which the article says are collapsing into the same space as review now that code is cheap to write and rewrite ^[9][10]. That path ends somewhere uncomfortable: the piece floats a world with 20 times as many PRs that never get merged, and treats build-try-reject as a plausible future workflow ^[11]. The other is to move review left, capturing intent and the decision-making from the LLM session before the change is submitted, with the discipline being preservation rather than letting those decisions disappear ^[12]. The reviewer then reads eight lines of intent instead of a 600-line diff, and asks whether the team is solving the right problem with the right constraints ^[13]. That is roughly a 75-fold cut in what a reviewer reads ^[19], and the article argues it is a better use of a senior engineer's time, with knowledge sharing surviving because acceptance criteria carry the decisions behind the implementation ^[14].

What neither path specifies is where correctness checking goes once nobody reads the lines ^[20]. The article's answer is a sliding scale: not read or not read, but whether attention is directed where it is useful, with low-risk material dropping out of the attention set over time and different organizations landing in different places depending on sensitivity ^[16][17][18].

Watch whether the intent artifact actually gets preserved before submission, because that discipline is the whole mechanism and it is unpaid work at the exact moment an engineer wants to ship ^[12]. Watch merge rates: if unmerged PR volume climbs toward anything like 20x, review queues and CI spend become the constraint, not reviewer attention ^[11]. And watch what replaces line-reading for verification, because the source treats it as a job that remains while describing mechanisms that only cover judgment ^[6][20].