Sorting the last 100 review comments finds 75% of the feedback a rule or a test can catch

Multiply the two percentages in the post and the answer depends on what the second one measures ^[1]. If the 91% is the wall clock on a single pull request, the reviewing load is 1.98 times 1.91, or 3.78 times what it was ^[5]. If it is the team's total review hours, then time per pull request fell to 1.91/1.98 of its old value, about 3.5% less, and the whole increase is volume ^[6]. The post attributes its 77% figure to one study without naming it, and it does not define high AI adoption ^[22].

The per-reviewer number is concrete either way. Fifteen pull requests at 400 lines each is 6,000 lines of diff a day ^[4]. Some experienced engineers, the post says, point-blank refuse to review AI-generated code ^[23].

The author runs a community of senior engineers and engineering leaders, and says all of them name AI code review bottlenecks among their top concerns ^[18]. Volume is only part of the complaint. "When AI writes code, the reasoning is gone. The reviewer is left reverse-engineering intent from a diff," the author wrote ^[7].

The part that transfers is the sorting exercise, because you run it on your own history. Pull the last 100 review comments. Label each one deterministic if a rule can check it, execution-testable if running the code catches it, or genuine judgment ^[12]. The post reports a rough split of 45%, 30% and 25% when teams do this ^[13]. The first two buckets add to 75% ^[14]. "Three-quarters of review feedback is codifiable. Every recurring review comment is an invariant you haven't written yet," the author wrote ^[15]. The worked example is "New endpoints must have OTel spans", which the post calls an AST check and not a judgment call, written once ^[16].

Three of the five slop categories in the post look like rule and harness work to me. Convention-blind output ignores repo conventions around naming, error handling, logging patterns and module boundaries ^[20], which is the material an AST check encodes. Over-engineering shows up as a 200-line abstraction layer for a problem that needs 15 lines ^[21]. Hallucinated calls to APIs that do not exist are sometimes caught immediately and sometimes only in production, according to the post ^[25]. Plausible-but-wrong stays with a human: it reads coherently and handles the happy path, and catching it requires knowing what the code was supposed to do ^[10].

The objection to bolting on another model is that one which both writes and reviews shares its own blind spots, and that stacking adversarial agents turns engineers into "bot-sitters" who tune filters instead of building ^[11]. The recurrence test costs less to apply: if you have posted the same comment more than once, codify it ^[17].