Blog
History of code review: from Fagan inspections to AI
What code review looked like before, and how AI is changing it
Alex Mercer
Code review started as the formal inspection meeting that M. E. Fagan described at IBM in 1976. Later came patches reviewed over mailing lists, then pull requests on GitHub, and now review often begins with an AI reviewer.
In the 1970s and 1980s, the formal way to review code was an inspection. Each reviewer prepared alone, then the group met and went through the code together at about 150 lines an hour. Engineers printed listings, gathered in conference rooms, and followed inspection checklists.
Today, AI tools can review similar changes in seconds. They flag likely bugs, call out risky patterns, and draft comments before a human reviewer even opens the pull request.
The shift isn't just in speed. It's changing when feedback happens, and what humans spend attention on.
Here's how we got from conference rooms to AI-assisted review, and what's coming next. If you want the basics first, start with what code review is and how it works today.
TLDR
Code review evolved from formal inspections, which IBM's Michael Fagan published in 1976, to lightweight peer review, and now to AI-assisted review.
Waterfall-era reviews were slow, rigid, and difficult to scale, often delaying feedback until late in development.
Agile practices made reviews faster and more collaborative, but human bottlenecks remained as teams and codebases grew.
AI code review now analyzes changes in seconds, helping teams improve quality and consistency without slowing delivery.
Fagan inspections: when code review meant conference rooms
A Fagan inspection is a formal review meeting with set roles and steps. Fagan described it in a 1976 IBM Systems Journal paper on design and code inspections, as five operations: overview, preparation, inspection, rework and follow-up.
Four people made a good-sized team: a moderator, ideally from an unrelated project, plus the program's designer, coder and tester. Each prepared alone, studying the material and checklists of common errors. In the meeting, a reader picked by the moderator, usually the coder, walked through the logic so every branch was covered at least once, and the moderator noted each error with its type and severity. The meeting only found errors. Fixing them waited for the rework step, and if more than 5% of the material was reworked, the team inspected all of it again.
The pace was slow. For systems code, Fagan's paper plans on about 125 lines an hour for preparation and 150 lines an hour in the meeting, in sessions of no more than two hours, with the moderator's written report due within a day.
The process worked for finding bugs. But it came with serious costs.
Waterfall review challenges:
Time-consuming formal process - Reviews took days or weeks to complete
High overhead - Coordination, scheduling, and documentation requirements slowed everything down
Late feedback - Developers discovered issues long after writing code, when fixes cost more
Sequential bottlenecks - Each review had to finish before the next phase could begin
Limited adoption - Many teams skipped reviews entirely due to the burden
A 2018 Google study notes that researchers found inspections useful, especially for finding defects, but "the cumbersome, time-consuming, and synchronous nature of this approach hindered its universal adoption in practice."
Software development needed a better approach.
What changed with agile?
By the early 2000s, frustration with the waterfall's rigidity had reached a breaking point. Teams struggled to deliver working products efficiently. Bureaucratic processes overwhelmed productivity.
In 2001, 17 software practitioners met in Utah to formalize a new way of working. They created the Agile Manifesto, prioritizing individuals and interactions over processes and tools.
Code review evolved along with development methodology. Formal inspections gave way to lightweight, informal peer reviews built into daily workflows. Today's review threads run on shorthand such as LGTM, nit and PTAL, which our code review glossary explains.
Key improvements:
Informal process - No mandatory meetings or rigid checklists.
Faster feedback - Hours or days instead of weeks.
Team learning - Review became a knowledge-sharing platform.
Flexibility - Teams adapted practices to their needs.
Open-source projects had their own lightweight style. Until the late 2000s, most large ones reviewed patches sent to mailing lists and issue trackers, remotely and asynchronously, according to the same Google study.
But agile didn't solve the tooling problem. Reviews still happened via email, printed diffs, or awkward custom systems.
How did pull requests change everything?
GitHub added pull requests in February 2008, at first as a way to tell people who had forked your repository to pull your changes. In 2010 it added a discussion view with Commits and Files Changed tabs, and in 2011 comments on individual lines of the diff.
Pull requests let developers see exact code changes, leave inline comments, and track discussions in one place. No more emailing patches or reviewing printed diffs. For a primer, see what a pull request is.
The pull request era brought:
Visual diffs - See exactly what changed, line by line.
Inline comments - Discuss specific code sections directly.
Continuous integration - Automated tests run before human review.
Distributed teams - No timezone coordination needed.
Version control integration - Review tied directly to the git workflow.
By the mid-2010s, GitHub, GitLab, Bitbucket, and similar platforms made this style of code review standard practice. For how that works today, see our guide to reviewing a pull request on GitHub. Tools like Gerrit and Phabricator offered alternatives for different workflows.
This was modern code review at its peak. Fast, collaborative, and integrated with development tools.
But human bottlenecks remained. PRs piled up. Reviews took hours or days. Context switching killed productivity as developers waited for feedback.
The next step had to address a simple problem: human reviewers couldn’t keep up.
Why did a human-only review still cause problems?
Even with pull requests, code review remained a constraint for most teams.
1. The velocity problem: PRs pile up when humans are the bottleneck. Engineers wait hours or days for feedback. Developers lose significant time refocusing after each interruption. When PRs sit in queues, developers either start new work (creating more context switches) or sit idle.
2. The consistency problem: Human reviewers have good days and bad days. Morning reviews catch different issues than afternoon reviews. Senior engineers spot different problems than juniors. Style preferences vary by person. This makes review quality unpredictable.
3. The scale problem: As teams grow and codebases expand, human review capacity doesn't scale proportionally. A 10-person team might generate 50 PRs weekly. That's 5 PRs per person to review, on top of their own development work. The math doesn't work.
Code review in the age of AI
AI code review spread along with AI coding tools. What started as experimentation is now standard practice at many teams.
Stack Overflow's 2026 Developer Survey found that 73% of respondents use coding assistants and agents daily. In April 2026, Google's CEO said 75% of all new code at Google is AI-generated and approved by engineers, up from 50% the previous fall.
But adoption alone doesn't tell the full story. The results matter more.
What does AI code review deliver?
Instant feedback - Reviews in seconds, not hours or days.
Consistent analysis - Same standards every time.
Scalable capacity - Reviews many pull requests at once, so the first pass doesn't wait in a reviewer's queue.
Team conventions - Checks each change against the rules your team has written down.
24/7 availability - No timezone delays.
Our guide to automated code review covers what to automate and what to keep human. When AI handles the routine checks, people can spend their review time on architecture and business logic.
How does AI code review actually work?
Modern AI code review tools work differently from earlier automated tools. Static analysis tools flag code that matches rules written in advance. An AI reviewer also reads the code around the change, so it can comment on logic that no rule covers.
The review process:
AI scans changed code against the full codebase context.
Identifies bugs, security risks, style issues, and performance problems.
Leaves inline comments with specific suggestions.
Generates a summary highlighting major concerns.
Developers address feedback and commit fixes.
AI re-reviews to verify resolution.
The entire cycle takes minutes. You can see AI review comments on real pull requests in projects like n8n, Cal.com and PostHog. AI reviewers that learn from your team's replies and reactions produce fewer false positives over time.
What AI excels at:
Syntax and style violations.
Security vulnerability scanning.
Performance anti-patterns.
Test coverage gaps.
Documentation requirements.
What humans still handle better:
Business logic validation.
Architectural decisions.
Edge case identification.
Mentoring through review comments.
The best results come from combining both.
Where is AI code review headed?
AI code review is still evolving. Here's where it's headed.
Autonomous code agents: Coding agents already turn issues into pull requests, as GitHub's Copilot cloud agent does, and can push fixes for review comments. As more of the code and the fixes come from agents, review becomes the main place a person checks the work.
Continuous code quality: Rather than reviewing code at PR time, AI will provide real-time feedback as developers type. Think pair programming with an AI that knows your entire codebase and every bug your team has fixed.
Self-learning systems: Some reviewers already learn from how your team responds. cubic remembers your replies and reactions to its comments and learns rules from your senior engineers' past reviews, to reduce false positives over time.
Integration depth: AI code review will integrate more deeply with the entire development lifecycle. Instead of being a step in CI/CD, it will be woven throughout: architecture design, implementation, testing, deployment, and production monitoring.
Why this evolution matters
Code review evolved because software development demands changed. Waterfall worked when requirements were stable, and timelines were measured in years. Agile enabled faster iteration. AI enables continuous quality at scale.
But success requires more than installing a tool. Teams need to understand what AI does well, where it falls short, and how to integrate it effectively into workflows.
cubic's AI code review checks every pull request against your whole codebase and your team's rules, flags changes that break code elsewhere, and learns from your team's replies and reactions.
Start your free trial to see what it finds on your own pull requests.
FAQ
How does AI code review find bugs that humans miss?
An AI reviewer such as cubic checks each pull request against the whole codebase, so it can flag a change that breaks code outside the diff, even in a large pull request. Large changes are where human review thins out: in a Microsoft study of about 1.5 million review comments, the more files a change had, the smaller the share of comments that were useful to its author. AI reviewers miss bugs too, and GitHub's docs tell teams to supplement Copilot code review with a human review.
How should code review change in an AI-native engineering team?
Let an AI reviewer take the first pass on every pull request, including the ones coding agents write, and keep a human approval for design, intent and business logic. Watch pull request size: in cubic's State of AI coding 2026 report, the median pull request grew from 56 lines changed in June 2025 to 124 in May 2026. When you measure review speed, count only human reviews, because an AI reviewer's quick comment hides how long authors wait for a person.
What is the purpose of a code inspection?
To find defects early, while they're cheap to fix. Fagan's paper warns that an error left unresolved after inspection can cost 10 to 100 times more to fix if it's found later in the process. Modern review turns up fewer defects than people expect: when Bacchelli and Bird sorted 570 review comments at Microsoft, 14% were about defects and the largest group, 29%, suggested code improvements.
