The Powerful History of Code Review: From Fagan Inspections to the Age of AI Agents

Fifty Years of the Same Basic Question

Every era of software engineering has asked the same underlying question. Before this code ships, who checks it, and how? The history of code review is really the history of that single question, answered five different ways across five decades. Each answer reflected the tools, team sizes, and risk tolerance of its moment. Understanding this full arc matters now more than ever, because AI has just introduced the sixth answer, and it looks nothing like the previous five.

1976: Fagan Formalizes the Inspection

The history of code review begins with a specific paper, published by a specific engineer, at a specific company. In 1976, IBM engineer Michael Fagan published “Design and Code Inspections to Reduce Errors in Program Development” in the IBM Systems Journal. This paper introduced what became known as the Fagan Inspection, the first formal, documented procedure for reviewing software before release.

The process was genuinely rigorous. A “reader,” chosen by the original coder, would paraphrase the design of the code line by line to a small group. The stated objective was narrow and deliberate. Find errors, and nothing else. Questions were permitted only until an error was recognized. Discussion of alternative designs was explicitly discouraged. Each defect found was categorized by severity. This was inspection as forensic procedure, not collaborative brainstorming.

Fagan Inspections worked. They caught genuine defects before expensive downstream fixes. But they were also extremely burdensome. Meetings required physical presence. Printed code was often distributed and marked up by hand. A single inspection could consume hours of several engineers’ time for a modest amount of code. This tension, rigor against speed, would define nearly every subsequent chapter in the history of code review.

The 1990s: Desk Checks and the First Compromise

By the 1990s, the strict Fagan model had started to soften. Teams introduced desk checks, a lighter practice where the original author reviewed their own work carefully before ever submitting it to others. This was not a replacement for peer review. It was a filter, meant to catch obvious mistakes before spending a colleague’s time on them.

This period represented an early, informal acknowledgment of something the history of code review would keep confirming. Full formal inspection did not scale well as software projects grew larger and release cycles grew shorter. Something had to give, and speed usually won.

2005: Git Changes the Physical Shape of Review

The single most consequential turning point in the history of code review was not a new review methodology at all. It was a version control system. Linus Torvalds created Git in 2005, originally to manage changes to the Linux kernel. Git introduced distributed version control, meaning every developer held a complete copy of the project’s history locally, rather than depending on a single central server.

This technical shift had a direct, cascading effect on review practices. Because Git tracked changes as discrete, shareable commits, it became natural to bundle a set of changes and formally propose them to a project maintainer. GitHub, founded in 2008, built an entire product around this idea and gave it a name that stuck permanently. The pull request.

A pull request let a developer submit code changes as a self-contained unit. Other team members could comment directly on specific lines, discuss changes asynchronously, and require a set number of approvals before merging. Crucially, this history remained visible and searchable indefinitely, unlike a Fagan Inspection meeting that ended when the whiteboard was erased.

Divergent Paths: Facebook, Google, and the Fragmentation of Practice

Git’s flexibility meant no single review model dominated. Different companies built genuinely different systems, and the history of code review fragments here into parallel tracks worth examining individually.

Facebook moved away from Git entirely in 2013, adopting Mercurial instead, and built its own internal tool called Phabricator to manage code changes, which it called “diffs” rather than pull requests. Google took an even more distinctive path. Around 2015, Google replaced its older Perforce-based system with an internal tool called Piper, managing an enormous single repository containing billions of lines of code.

A detailed 2018 case study of Google’s own review process, authored by researchers including Caitlin Sadowski, found something notable. Google’s internal review culture remained genuinely fast despite its massive scale, with a strong norm that reviews should happen within roughly a day. This was not accidental. It reflected deliberate cultural engineering layered on top of the tooling itself, proof that the history of code review was never purely a story about software tools. Human norms mattered just as much.

2018: GitHub Suggested Changes and the Rise of Inline Automation

By 2018, GitHub introduced a feature called Suggested Changes, letting reviewers propose specific code edits directly within a pull request comment, which the author could accept with a single click. This was a small feature with an outsized signal. Review was no longer purely about identifying problems. It was becoming about proposing and applying solutions directly, blurring the line between reviewing code and writing it.

This blurring foreshadowed exactly where the history of code review was heading next, though almost nobody framed it that way at the time.

The Numbers Nobody Wants to Talk About

Before turning to AI’s role, it is worth pausing on a specific empirical fact. Studies consistently find that code review does not simply catch bugs efficiently. It catches specific kinds of bugs, and it misses others entirely. Research on pull-based development found that reviewers routinely miss defects that automated static analysis catches easily, while automated tools routinely miss architectural and design issues that experienced human reviewers catch reliably. Neither method alone was ever sufficient. This gap is exactly where AI code review tools have now inserted themselves.

2023 to 2026: AI Enters the Loop

The history of code review reaches its current, most disruptive chapter starting around 2023. GitHub Copilot Code Review reached general availability in April 2025 and reportedly hit one million users within its first month. By January 2026, GitHub Copilot counted 4.7 million paid subscribers, up sharply from 1.8 million the previous fiscal year.

A crowded field of specialized competitors emerged alongside GitHub’s own offering. CodeRabbit, Greptile, DeepSource, Snyk, and Qodo each took a different technical approach. Independent benchmarking in 2026 found real, measurable differences between them. Greptile, which indexes an entire codebase rather than reviewing a diff in isolation, caught roughly 82 to 85 percent of seeded bugs in one test, nearly double the detection rate of diff-only tools. GitHub Copilot Code Review, by contrast, favored precision over recall, catching fewer issues but generating fewer false positives.

This tradeoff between catching more bugs and generating more noise runs directly through the current era of the history of code review. One 2026 analysis found that 64 percent of AI-generated review comments were pure style noise, with only 14 percent flagging genuine bugs. Teams that ignored this ratio saw developer trust collapse. Teams that tuned their AI reviewers carefully saw real gains, typically a 20 to 40 percent reduction in review cycle time.

The Uncomfortable Statistic: 1.7x More Issues

Here is where the history of code review takes a genuinely concerning turn. CodeRabbit’s own December 2025 research found that AI-coauthored pull requests carry roughly 1.7 times more issues than pull requests written entirely by humans. Separately, 96 percent of developers admitted they do not fully test AI-generated code, and only 48 percent said they always review it before merging.

This creates what researchers now call verification debt. Code gets written faster than ever. The review process, the very mechanism the history of code review shows was built specifically to catch exactly this kind of risk, is often skipped or rushed precisely when it matters most.

The Provocative Claim: Has Human Review Already Ended?

A 2026 academic paper takes this trajectory to its logical, and genuinely provocative, conclusion. Its authors argue that coding agents have crossed a threshold of capability at which traditional human code review is no longer a necessary component of a software quality pipeline. This is a striking claim to make explicitly, fifty years after Fagan’s original paper defined the entire discipline.

The paper does not argue for zero oversight. It argues for a different interaction model entirely. Rather than a human reading a list of static comments and deciding whether to accept or reject each one, the developer converses directly with an AI agent, requesting explanations, alternative implementations, or negotiated tradeoffs. The authors compare this to pair programming rather than traditional review, and they argue it removes the social overhead that makes synchronous human pairing difficult to sustain at real scale.

The same paper acknowledges a genuine limit. It recommends keeping specialized, frontier-level AI reviewers specifically for security sign-off, since general-purpose coding agents still fall short on the highest-stakes categories of defect.

Why This Should Make Every Team Pause

The history of code review teaches a consistent, repeated lesson across every single transition covered in this article. Fagan Inspections were rigorous but too slow. Desk checks were fast but too shallow alone. Pull requests scaled well but fragmented practice across companies. And now AI review tools are fast and tireless, but measurably prone to noise, and measurably associated with a genuine rise in defects when relied upon without adequate human oversight.

The teams succeeding with AI code review in 2026 are not the ones replacing human judgment entirely. They are the ones treating AI as one more layer in a defense that has always needed multiple layers. Reserve deep, full-codebase tools like Greptile for architecturally risky changes. Reserve fast, low-noise tools like Copilot for routine, low-risk pull requests. And critically, for teams doing heavy AI-assisted or vibe coding, strengthen human review gates rather than weakening them, since AI reviewing AI-written code, with no human check anywhere in the loop, recreates exactly the kind of blind spot Fagan’s original inspection process was invented specifically to prevent.

Conclusion

The history of code review spans fifty years, five distinct methodologies, and one consistent underlying tension. Rigor costs time. Speed costs certainty. Fagan chose rigor in 1976. Git and pull requests chose speed and scale in 2005. AI code review tools, arriving in 2023 and maturing rapidly through 2026, promise both simultaneously, and the early evidence suggests that promise remains only partially fulfilled. The 1.7x issue rate in AI-coauthored code is not a reason to abandon these tools. It is a reason to apply the oldest lesson in the entire history of code review with renewed discipline. No single reviewer, human or artificial, should ever be the only check standing between code and production.