Code review, the practice of peer evaluation before code enters the main codebase, exists ostensibly to catch bugs, ensure consistency, and maintain quality. These are its productive functions, and they are real. But its social function — the trust built through repeated demonstrations of careful attention and honest feedback, the norms transmitted through the modeling of quality standards, the professional relationships deepened through sustained intellectual engagement — is equally real and far more consequential for organizational resilience. Code review is inherently vulnerable. It requires the author to submit work for scrutiny and the reviewer to invest time reading another's code with genuine attention. Both must be willing to be wrong, to learn, to negotiate. The interaction is a trust-building exercise precisely because both parties demonstrate reliability — the author by producing reviewable code, the reviewer by providing thoughtful feedback — under conditions where unreliability was possible. When AI can review code more comprehensively and more quickly than humans, the productive justification for human review diminishes. The social justification does not.
The practice was formalized in the 1970s at IBM, spread through the software industry in the 1980s and 1990s, and became standard practice in the 2000s with the rise of distributed version control (Git) and platforms like GitHub that made review workflows trivially easy. The open-source community adopted code review as a governance mechanism: the pull request that must be approved by maintainers before merging. The corporate software world adopted it as a quality mechanism. Both contexts produced the same social byproduct: trust among practitioners.
Effective code review requires what Putnam would call sustained attention to another person's thinking. The reviewer must understand not just whether the code works but whether the design is sound, whether the approach is maintainable, whether the solution fits the broader architecture. This understanding takes time — often more time than writing the original code — and it cannot be faked. The author knows whether the reviewer actually read the code or merely scanned it. The quality of the review signals the reviewer's respect for the author, the work, and the shared standards of the team. The trust built through high-quality review is the invisible return on the visible time investment.
AI code review tools — GitHub Copilot's review suggestions, static analysis at scale, Claude's architectural feedback — can identify bugs, security vulnerabilities, performance issues, and style violations faster and more comprehensively than human reviewers. The productivity case for AI review is overwhelming. The social capital case for preserving human review is invisible to productivity metrics. The bug gets caught either way. Only human review builds the relationship, transmits the norms, and demonstrates the mutual investment in quality that constitutes professional trust.
Organizations responding to AI's review capabilities face a choice disguised as an efficiency question. Replace human review with AI review and capture the time savings. Preserve human review and invest in social capital that does not appear on any balance sheet. The design challenge is creating a hybrid: AI handles the mechanical checks (syntax, security, performance), human review handles the judgment questions (is this the right approach? does this fit our architecture? what will break in six months?). The hybrid preserves the productive efficiency while maintaining the social capital production — but only if the human review remains genuinely consequential rather than pro forma.
Code inspection was formalized by Michael Fagan at IBM in 1976. The Fagan inspection process was heavyweight — formal meetings, defined roles, checklists — and designed for mainframe development where errors were catastrophically expensive. The modern lightweight code review evolved with distributed version control: asynchronous, tool-mediated, woven into the daily workflow. GitHub's pull request model (introduced 2008) made review frictionless enough to become universal. The social capital implications were never examined because the practice was justified entirely by its quality benefits.
Review is a trust demonstration. The reviewer who invests thirty minutes reading your code demonstrates that your work matters, your judgment is respected, and the shared quality of the codebase is worth her time.
Norms are transmitted through modeling. Junior developers learn what good code looks like not through style guides but through observing what senior reviewers approve, question, and reject — and why.
Vulnerability builds bonds. Submitting work for review requires accepting the possibility of criticism. Surviving the criticism with respect intact — on both sides — deposits a layer of trust that accumulates over iterations.
AI review is qualitatively different. It catches errors without building relationships. The efficiency gain is real; the social capital cost is invisible until the team that used to trust each other can no longer coordinate under pressure.