The New Bottleneck: AI Shifts Code Review

TL;DR:

• AI coding assistants now account for roughly 42% of all committed code, a figure projected to reach 65% by 2027, yet teams using these tools are delivering software slower and less reliably at the organizational level despite strong individual productivity gains
• In teams with extensive AI use, PR review time has ballooned by approximately 91%, according to research from Faros AI, while individual task completion increased by only 21%
• GitHub's 2024 Developer Survey found that 87% of developers using AI coding assistants report faster development cycles, yet Bain and Company's 2025 Technology Report found real productivity boosts at the organizational level landing between 10% and 15%
• AI-generated code is structurally harder to review because reviewers cannot rely on the mental shortcuts they use when reading code written by a known colleague with a known style
• The engineering role is shifting from primary author to critical evaluator, a change that requires different skills, different tooling, and a different relationship with the codebase
• In Web3 environments, where smart contracts are immutable once deployed, the cost of a review failure is not a bug ticket but a permanent financial loss
• Purpose-built AI development environments that integrate review assistance directly into the coding workflow are becoming the structural answer to this problem

The result: AI has solved the writing bottleneck and created a review bottleneck, and the teams that figure out how to scale review capacity will be the ones that actually capture the productivity gains AI promises.

The Bottleneck Nobody Expected

There is a version of the AI coding story that goes like this: developers get access to tools like GitHub Copilot, Cursor, or Claude Code, they write code two or three times faster than before, and the whole software delivery pipeline speeds up proportionally. That version of the story is compelling, and it is also incomplete. What actually happened when teams adopted AI coding assistants at scale is more interesting and considerably more complicated.

The bottleneck did not disappear. It moved. For decades, the constraint in software delivery was the time it took a developer to translate a requirement into working code. That constraint shaped how teams were structured, how sprints were planned, and how engineering managers thought about capacity. AI coding assistants attacked that constraint directly and, by most measures, successfully. Individual developers using tools like Copilot report productivity gains of up to 41% on routine coding tasks, according to GitHub's own research. The writing part of software development got faster, sometimes dramatically so.

But software delivery is not just writing. It is writing, reviewing, testing, merging, deploying, and monitoring. When you speed up one stage of a pipeline without addressing the others, you do not get a faster pipeline. You get a bigger queue at the next stage. This is Amdahl's Law applied to software teams, and it is playing out in engineering organizations around the world right now. The new queue is the pull request backlog, and it is growing faster than most teams anticipated or planned for.

Amdahl's Law Comes for Software Teams

Gene Amdahl formulated his law in 1967 to describe the theoretical speedup of a task when only part of it is parallelized. The core insight is that overall performance improvement is limited by the fraction of the task that cannot be sped up. In software delivery, the fraction that AI has not yet solved is human review, and that fraction is now the dominant constraint on how fast teams can ship.

The pattern is consistent across organizations that have adopted AI coding tools at scale. Individual developers move faster, generate more code, open more pull requests, and feel more productive. But the reviewers on the other end of those pull requests are still human, still limited by attention and time, and now facing a substantially higher volume of code to evaluate. According to research from Faros AI, teams with extensive AI use saw review time increase by roughly 91% while individual task completion went up by about 21%. The math is straightforward: you are generating code roughly four times faster than your review capacity can absorb it.

What makes this particularly tricky is that the problem is invisible at the individual level. A developer using Copilot or Cursor genuinely is more productive. Their personal metrics look great. The slowdown only becomes visible when you zoom out to the team level and look at cycle time, the elapsed time from when a ticket is picked up to when the code is in production. That number, for many AI-adopting teams, has gotten worse, not better. Bain and Company's 2025 Technology Report found that despite two-thirds of software firms rolling out generative AI tools, real productivity gains at the organizational level were landing between 10% and 15%, a fraction of what the individual-level numbers would suggest.

The Numbers Behind the Slowdown

The data on this shift is now substantial enough to move beyond anecdote. AI accounts for approximately 42% of all committed code today, and that figure is projected to reach 65% by 2027. That is a majority of the code in production codebases being generated by systems that do not have context about the business, the team's conventions, the history of a particular module, or the subtle reasons why a certain pattern was avoided three years ago. All of that context lives in the heads of the human reviewers, which is precisely why review has become the bottleneck.

GitHub's 2024 Developer Survey found that 87% of developers using AI coding assistants report significantly faster development cycles, with productivity gains of up to 41% on routine coding tasks. A study published in Communications of the ACM by Ziegler et al. analyzed 2,631 survey responses from developers using GitHub Copilot and found that 73% reported staying in flow state more effectively, while 87% preserved mental effort during repetitive tasks. These are real gains. The problem is not that AI coding assistants do not work. The problem is that they work well enough to create a downstream capacity crisis that the tooling ecosystem was not designed to handle.

The review time inflation is not uniform. It is worst on large pull requests, which AI-assisted developers tend to produce more of because the friction of writing code has dropped significantly. When a developer can generate 200 lines of working code in the time it used to take to write 50, the natural tendency is to batch more work into a single PR. Reviewers then face a 400-line diff instead of a 100-line diff, and the cognitive load of reviewing that diff is not linear. Research on code review consistently shows that review quality degrades significantly above 400 lines, and that reviewers start missing defects at a much higher rate. AI has pushed the average PR size up precisely into the range where human review becomes unreliable.

Why AI-Generated Code Is Harder to Review

There is a specific cognitive challenge that comes with reviewing AI-generated code that is different from reviewing code written by a colleague. When you review a colleague's code, you have a mental model of how they think, what patterns they favor, where they tend to make mistakes, and what their code usually looks like when something is wrong. That model is built over months and years of working together, and it makes review faster and more accurate. You know what to look for, and you know where to be skeptical.

AI-generated code does not come with that context. It is often syntactically clean, well-structured, and superficially correct. It passes linters. It compiles. It often looks like the kind of code a competent mid-level engineer would write on a good day. But it can also contain subtle logical errors, incorrect assumptions about state, or security vulnerabilities that are invisible to a quick scan. The reviewer cannot rely on the usual heuristics because the usual heuristics are calibrated to human error patterns, not AI error patterns.

AI models make mistakes in ways that are qualitatively different from human mistakes. A human developer who misunderstands a requirement will usually produce code that looks confused, inconsistent, or incomplete in ways that are visible during review. An AI model that misunderstands a requirement will often produce code that is internally consistent, well-organized, and confidently wrong. The confidence is the problem. It removes the visual cues that reviewers rely on to know where to slow down and look more carefully. This is what makes AI-generated code cognitively expensive to review even when it is ultimately correct, and it is why review time has inflated so dramatically on teams that have adopted AI generation without also rethinking their review process.

The Role Shift Nobody Prepared For

The Graphite CEO Merrill Lutsky put it plainly in a widely circulated conversation about AI code review: engineering roles are shifting from writing code to reviewing it. That observation sounds simple, but the implications for how teams are structured, how engineers are evaluated, and what skills are valued are significant. Writing code and reviewing code are not the same cognitive activity. They require different kinds of attention, different kinds of knowledge, and different relationships with the codebase.

Writing code is generative. You are building something from a specification, making decisions about structure and naming and logic as you go. The feedback loop is tight: you write a function, you run it, you see if it works, you adjust. Reviewing code is evaluative. You are assessing something that already exists, looking for gaps between what the code does and what it should do, between what the author intended and what the system will actually execute. The feedback loop is much longer, and the cost of a missed defect is paid later, often much later, when the code is in production.

Most engineers were trained primarily as writers. Their education, their early career experience, and the tools they use are all oriented around the act of creation. The shift to a review-primary role is not just a workflow change. It is a skill development challenge that the industry has not fully reckoned with. Senior engineers who have spent years developing strong review instincts are suddenly more valuable than they were before, not because their writing skills have become less important, but because their review skills are now the scarce resource that determines how fast the team can actually ship. Junior engineers, meanwhile, are in a more complicated position: they can generate code faster than ever, but they lack the experience to evaluate what they have generated, which creates a quality risk that is easy to miss until it surfaces in production.

The Compounding Problem of Review Fatigue

Review fatigue is not a new problem. It predates AI coding assistants by decades. Any team that has operated at high velocity for an extended period knows the feeling: the PR queue grows, reviewers start skimming instead of reading, and the LGTM approval becomes a social gesture rather than a technical judgment. The research on this is consistent. Review quality degrades significantly after about 60 minutes of continuous review, and defect detection rates drop sharply on pull requests above 400 lines. These are human cognitive limits, and they do not change because the code was generated by an AI.

What AI coding assistants have done is make review fatigue the default state rather than the exception. When individual developers are generating code 40% faster, the volume of code flowing into the review queue increases proportionally. Reviewers who were already stretched are now facing a substantially higher load with no corresponding increase in their own capacity. The result is predictable: more rubber-stamp approvals, more defects reaching production, and a gradual erosion of the code quality standards that the review process was supposed to enforce.

There is also a subtler form of fatigue that comes specifically from reviewing AI-generated code. Because AI-generated code tends to be verbose, well-formatted, and superficially correct, reviewers can develop a false sense of confidence. The code looks fine, so they move through it quickly. But the defects in AI-generated code are often not in the obvious places. They are in the edge cases, the error handling, the assumptions about input validation, and the interactions between components that the AI did not have full context about. Catching those defects requires the kind of slow, deliberate reading that fatigue makes impossible. The combination of higher volume and higher cognitive demand per line is a recipe for review quality collapse, and it is happening quietly in engineering organizations that have not yet connected the dots between their AI adoption and their rising defect rates.

The Web3 Dimension: When Review Failures Are Permanent

In traditional software development, a defect that makes it through code review is a problem, but it is a recoverable one. You ship a patch, you roll back a deployment, you fix the bug and move on. The cost is real but bounded. In Web3 development, that calculus changes fundamentally. Smart contracts deployed to a blockchain are immutable. There is no patch, no rollback, no hotfix. The code that passes review is the code that lives on-chain, potentially forever, and any vulnerability in that code is a permanent attack surface.

This makes the review bottleneck in Web3 development not just a productivity problem but a security and financial risk problem. The Moonwell DeFi protocol suffered a $1.78 million exploit traced to AI-generated vulnerable code, a concrete example of what happens when the review process fails to catch what the generation process introduced. The stakes are not hypothetical. They are denominated in real assets, and they are irreversible. A 91% increase in review time is an inconvenience in a traditional software context. In a Web3 context, it is a signal that the window for catching critical vulnerabilities before deployment is under serious pressure.

The specific vulnerabilities that AI models tend to introduce in Solidity code, including reentrancy patterns, integer overflow risks, and access control gaps, are exactly the kind of subtle, structurally embedded issues that review fatigue causes reviewers to miss. They do not look wrong at a glance. They require careful tracing of execution paths, understanding of how the EVM handles state changes, and familiarity with the specific attack patterns that have been exploited in the past. That knowledge is not evenly distributed across engineering teams, and it cannot be assumed to be present in every reviewer. The combination of AI-generated code, fatigued reviewers, and high-stakes immutable deployment is one of the more serious risk configurations in modern software development.

What Good Review Tooling Actually Looks Like

The answer to a review bottleneck is not to tell developers to write less code or to hire more reviewers. Both of those approaches work against the productivity gains that motivated AI adoption in the first place. The answer is to scale review capacity using the same class of tools that scaled writing capacity, which means AI-assisted review, but implemented thoughtfully and with a clear understanding of what AI reviewers are good at and where they fall short.

AI reviewers are genuinely useful for a specific class of review tasks. They can scan for known vulnerability patterns without fatigue. They can check for consistency with established coding conventions across an entire codebase, not just the files a human reviewer happens to look at. They can flag deviations from documented architecture decisions, catch missing test coverage, and surface edge cases that the author did not consider. One developer described using multiple LLMs simultaneously, including Copilot, Claude Code, Codex, and Cursor's Bugbot, to review every pull request, noting that each model catches different things and that the iterative review loop turned a small fix that he expected to take two commits into an 18-commit improvement that was substantially more robust than the original patch.

But AI reviewers have real limitations that matter enormously in practice. They do not have the business context that explains why a particular design decision was made. They cannot evaluate whether a piece of code is correct relative to a product requirement that was discussed in a meeting and never written down. They do not know that a certain module is being deprecated next quarter and that adding complexity to it is a bad idea regardless of whether the code is technically correct. Human judgment is not optional in the review process. It is the part that cannot be automated, and the goal of good review tooling is to protect that judgment by handling the mechanical, pattern-matching work that currently consumes most of a reviewer's time and attention.

Architecture Thinking as the New Core Skill

One of the more interesting second-order effects of AI coding assistants is what they are doing to the value of architectural thinking. When writing code is cheap and fast, the decisions that matter most are the ones that happen before writing starts: how the system is structured, how components communicate, where state lives, and what the failure modes are. Those decisions are not things AI models make well without significant guidance, and they are the decisions that determine whether a codebase remains maintainable as it grows.

Lawrence Jones, an engineer who has written publicly about how AI tools changed his coding style, noted that writing extremely clear, easy-to-understand, consistent APIs has gone from a nice-to-have to an absolute requirement when working with AI tools. If you name a variable badly, the model can spiral. Files over 500 lines consume tokens at a rate that makes them practically expensive to work with. The discipline that AI tools demand from developers is, in many ways, the discipline that good software engineering has always demanded. AI has just made the cost of ignoring it immediate and visible rather than deferred and subtle.

This is a meaningful shift in what it means to be a strong engineer. The developers who will get the most out of AI coding assistants are not the ones who can type the fastest or who know the most syntax. They are the ones who can define problems clearly, design systems that are easy to reason about, and evaluate the output of AI generation with enough depth to catch what the model got wrong. Those skills are closer to what we traditionally associate with senior or staff-level engineering than with the kind of work that dominates early-career development. The implication is that AI is not just changing the bottleneck in software delivery. It is changing the shape of the engineering career ladder.

Scaling Review Without Scaling Headcount

The practical question for engineering leaders is how to scale review capacity without proportionally scaling headcount, because the economics of hiring reviewers to keep pace with AI-generated code volume do not work. The answer involves a combination of process changes, tooling investments, and cultural shifts that most organizations are still working through.

On the process side, the most effective intervention is PR size discipline. Smaller pull requests are faster to review, easier to reason about, and less likely to trigger the fatigue effects that cause defects to slip through. AI coding assistants actually make this easier in some ways: because generating code is cheap, there is less pressure to batch large amounts of work into a single PR to justify the effort of writing it. The friction that used to make small PRs feel inefficient is largely gone. What remains is the habit of writing large PRs, and habits can be changed with the right tooling and team norms.

On the tooling side, the most valuable investments are in systems that reduce the mechanical burden on human reviewers. Automated static analysis, AI-assisted vulnerability scanning, and convention enforcement tools can handle a significant fraction of the review workload that currently falls on human attention. The goal is not to replace human review but to ensure that human reviewers are spending their time on the decisions that actually require human judgment, rather than on the pattern-matching work that a well-configured tool can do faster and more consistently. Teams that have implemented this kind of layered review approach report that human review time per PR decreases even as the quality of review improves, because reviewers are no longer wading through mechanical issues to get to the substantive ones.

The IDE as the First Line of Review Defense

One of the most underappreciated opportunities in this space is moving review earlier in the development process. The traditional model treats review as something that happens after code is written, when a PR is opened and assigned to a reviewer. But the most effective place to catch a defect is before it is committed, while the developer who wrote it is still in context and can fix it without the overhead of a review cycle. This is where the development environment itself becomes a critical piece of the review infrastructure.

An IDE that integrates AI-assisted review directly into the writing workflow can surface issues in real time, before they become PR comments. It can flag a potential reentrancy vulnerability as the developer writes the function, not three days later when a reviewer finally gets to the PR. It can check whether a new function is consistent with the patterns established elsewhere in the codebase, without requiring a reviewer to hold the entire codebase in their head. It can prompt the developer to consider edge cases and error handling before the code is considered complete. This kind of shift-left review is not just a productivity optimization. It is a quality architecture decision that changes the economics of the entire delivery pipeline.

The development environment is also where context lives. A well-designed IDE knows the codebase, knows the team's conventions, knows the history of a module, and can surface that context at the moment when it is most useful, which is when the developer is making decisions, not after those decisions have been committed and pushed. The gap between what a generic AI coding assistant knows and what a purpose-built development environment knows is the gap between a tool that generates code and a tool that helps you generate the right code.

Where Cheetah AI Fits Into This Picture

The shift from writing bottleneck to review bottleneck is not a temporary adjustment period that will resolve itself as developers get more comfortable with AI tools. It is a structural change in how software is built, and it requires a structural response. The teams that will capture the full productivity potential of AI coding assistants are the ones that treat review capacity as a first-class engineering concern, invest in tooling that scales review without scaling headcount, and build development environments that integrate review into the writing workflow rather than treating it as a separate downstream activity.

Cheetah AI is built around exactly this understanding. As a crypto-native AI IDE, it is designed for the specific context where review failures are most costly, where code is immutable once deployed, where vulnerabilities are measured in lost funds rather than bug tickets, and where the gap between a good review and a missed defect can be the difference between a protocol that survives and one that does not. The platform integrates AI-assisted review directly into the development workflow, surfaces vulnerability patterns in real time, and is built to keep developers in context rather than pulling them out of flow to chase down issues that should have been caught earlier.

If your team is experiencing the review bottleneck that AI code generation tends to create, the answer is not to slow down generation. It is to build a development environment where review keeps pace. That is the problem Cheetah AI is designed to solve, and it is worth exploring whether it fits the way your team works.

For Web3 teams specifically, the stakes of getting this right are high enough that the choice of development environment is a risk management decision, not just a workflow preference. The protocols that have suffered the most costly exploits in recent years were not built by careless teams. They were built by competent engineers working under the same review pressure that every high-velocity team faces, using tools that were not designed for the specific failure modes of on-chain code. The lesson is not that AI coding assistants are dangerous. The lesson is that AI coding assistants without AI-assisted review are an incomplete solution, and incomplete solutions in smart contract development have a way of becoming very expensive problems.

Cheetah AI is available to teams that want to close that gap. The platform is built for the environment where the cost of a review failure is highest, and it is designed to make the review process as rigorous as the generation process. If you are building on-chain and you are feeling the pressure of the review bottleneck, it is worth taking a closer look at what a purpose-built crypto-native IDE can do for your team's delivery pipeline.