# Automating Both Ends Of A Review Collapses Its Value **Claim**: A code review only creates real knowledge-sharing value when at least one human is genuinely present on each side of the exchange. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions Holds where review is meant to transfer knowledge, build trust, or teach — the normal case for team and open-source PR review. Weakens for purely mechanical lint/format checks, which were always automatable and never carried a human-learning purpose. ## Evidence Ryan McCue argues review's less obvious value is that it's "one of the primary ways we build and share our engineering knowledge across the team." When both the description and the back-and-forth are AI-generated, the reviewer is effectively talking to an agent by proxy — the knowledge-transfer function disappears even if the code quality gate still technically fires. Piping review comments into an agent compounds this: comments are often discussion probes ("did you consider...?"), and an agent treats every one as a directive, introducing a "false certainty" the feedback never intended. ## Links - [[Open Source Governance MOC]] — what review is actually for, and what stops happening when both sides are automated - [[3. Resources/Literature Notes/Pull Requests Are for Humans]] — source literature note, full claim atoms and quotes. - [[3. Resources/MOCs/DevRel MOC]] — applies-in contributor onboarding and review-etiquette guidance. ## Tests / falsifiers If teams that require decision-and-context PR descriptions (not diff summaries) show no measurable difference in reviewer-reported knowledge transfer or satisfaction versus teams allowing AI diff-summary descriptions, this claim weakens. Would also weaken if AI-mediated review turns out to preserve nuance (e.g., agents that correctly distinguish a probing question from a change request) rather than flattening it. ## Maintenance Last tended: 2026-08-16 Next review: 2026-11-16 ## Source [[3. Resources/Literature Notes/Pull Requests Are for Humans]]