AI Code Review for Modern Engineering Teams

Engineering teams are shipping faster than ever with the assistance of AI. According to data from Linear, teams using coding agents merge five times more pull requests per week than teams that don’t (Figure 1).

At the same time, according to data from Cursor, the share of AI agent-generated changes reaching commits without a separate manual accept step has increased more than 5x since the start of the year, suggesting developers are trusting agents to carry more of the commit flow (Figure 2).

The code is moving fast, and it’s breaking trust. Software is becoming more complex and brittle.

A Georgia Tech study tracked AI-introduced security vulnerabilities across tens of thousands of security advisories. In the second half of 2025, they found 18 cases; on average, roughly, three per month. By March 2026, they found 35 in a single month (Figure 3).

Brittle software comes with real business costs. At Meta, engineers confirmed to Gergely Orosz that AI-generated, AI-reviewed code (combined with security teams depleted by layoffs and reassignments) contributed to a security failure that exposed over 20,000 Instagram accounts [4], including those belonging to the Obama White House, a US Space Force official, and Sephora. Meta’s CISO resigned the following day [5].

The engineering organization was never just producing code; every time the team deployed code safely, it also produced trust. When these deployments break, so does trust. “We’re accumulating code faster than we’re accumulating trust,” Kent Beck wrote [6]. He elaborated [7], “With code, you need to trust it. You need to understand it. We don’t have time to do that right now.” Beck outlined three possible responses. Teams need to:

• Accept operating without trust in programs and the engineers who ship them.
• Slow down code production deliberately to match the pace of trust.
• Learn to accumulate trust faster.

This report dives deep into the third path, supported by academic research and interviews with engineering leaders who are accelerating trust accumulation along with their software velocity.

AI-related coding failures rarely make headlines, as most companies have no reason to publicize them.

To understand how widespread this problem really is, we turned to four independent academic research papers that conducted studies based on thousands of repositories, not just the failures companies couldn’t hide:

These academic studies help establish the scale of AI-introduced risk. (Please see the Appendix for the full summary.) The following findings highlight key insights, and what engineering leaders can do about them.

He et al.’s study of Cursor adoption in 806 GitHub repos found that velocity gains fade within two months of adoption. Meanwhile, code complexity (+41%) and static analysis warnings (+30%) rise at adoption and remain elevated for the full observation period [8].

The initial velocity gain overshadows the complexity that accumulates over time (Figure 4). This complexity is the new constraint, which is a matter of software validation.

As engineering constraints shift, so do the responsibilities of engineering leadership. The challenge is no longer speeding up code output, but designing engineering systems that allow velocity and trust to scale together.

Coinbase’s head of Wallet Chintan Turakhia thinks of this shift in constraints in concentric circles. Each inner circle used to be a bottleneck; as it accelerates, the constraint gets pushed to an outer circle. Here’s an illustration of his mental model (Figure 5) [12]:

Once engineering teams can move faster, review and validation constrains the process. Then once validation can keep up with software velocity, there won’t be enough product ideas and design resources. Eventually, once that keeps up, compliance and legal remains the final constraint.

Until recently, engineering teams spent most of their time writing code. AI has sped that process up. At Atlassian, an engineering organization of about 6,000 people, coding is now roughly 15% of how they spend their time; the rest of their time is spent on new bottlenecks, including problem framing, validation, and alignment [13].

Engineering teams that build trust will spend less of their time writing code, and more time in problem framing and validation (Figure 6).

Liu et al. tracked AI-introduced issues, including code smells, correctness, and security issues, across over 6,000 GitHub repositories from early 2025 through February 2026. Overall, out of 464,900 tracked AI-introduced issues, 105,364 still survive in the version of the codebase in February 2026, corresponding to a survival rate of 22.7% (Figure 7) [9]. Each of these issues erodes trust.

Accumulating trust more quickly means building the validation infrastructure to catch issues before they ship and getting to a cumulative decrease of AI-introduced issues, not just shipping more code faster. The closer these issues get to zero, the more trust gets restored.

While individual engineers can improve review quality, only engineering leaders can establish the processes, tooling, and incentives that make trusted velocity repeatable across an organization. As AI increases the throughput of code for software engineers, the ability to scale validation becomes more important.

Every line of code introduces risk. As Coinbase’s Chintan Turakhia says, as the amount of code being contributed goes up, the safety guardrails need to go up with it. At Coinbase, every PR is scored against a security risk framework that governs whether an agent can approve it alone or whether it needs multiple human reviewers (Figure 8) [12]. That’s what the path from brittle software to trusted velocity, and fewer issues, looks like in practice.

Uber built similar infrastructure independently. Their internal Code Inbox tool was created specifically because, as Principal Engineer Ty Smith says [14], “Developers are spending more and more time in code review because there’s so much more code being generated.” The risk of letting bugs through increases as review fatigue sets in.

Code Inbox routes PRs intelligently. It surfaces only actionable reviews, assigning the most relevant reviewer based on ownership, availability, and timezone, and escalating automatically if SLOs are missed. Its separate Risk Profiles feature estimates the riskiness of each change and routes it accordingly.

Not all code needs the same level of scrutiny, but every line needs some.

Through their project SlopCodeBench, conducted in a controlled environment, Orlanski et al. found that the longer agents work on a codebase without validation, the more expensive every subsequent change becomes (Figure 9). These costs increase because the codebase itself becomes progressively harder to work with.

Simpler code is more trustworthy, and less expensive, code. Validation is about keeping the codebase simple enough to trust.

In a traditional SDLC, validation resembles a single checkpoint before production that catches what slipped through everything else. By the time a bug reaches that gate, it is expensive to fix and potentially already eroding trust. Shifting left is moving that validation effort forward earlier in the SDLC.

AI-assisted validation changes this. As Chris Kasten, Intuit’s chief architect and SVP engineering says [13], “We’re shifting left so much that the agents have all of our architecture rules, all of our security requirements fed into the context.” Review can be AI-assisted at every PR; in that sense, each PR serves as its own checkpoint (Figure 10).

The outcome of this process is bugs are caught earlier, when they are cheapest to fix, and the codebase stays simple enough to trust. Making subsequent changes should be just as easy as early ones.

As Coinbase’s Chintan Turakhia says [12], “AI is not an excuse to ship slop.” Making sure code is reviewed thoroughly also means making the resulting software higher quality.

Velocity and validation aren’t competing priorities. If velocity accelerates without validation, validation simply becomes the bottleneck. Treated as a sequence rather than a tradeoff, they help engineering teams accelerate the production of trust.

“Trustworthy behavior resulting in trustworthy software resulting in trust is the path to effective augmented development,” Kent Beck writes [6]. The path to trusted velocity runs through four practices: spec upfront, AI-augmented review, automated validation at scale, and risk-scored escalation. Each one is a step toward accumulating trust more quickly.

In a world where anyone can ship code quickly, the leaders who can also ship trust will ship better products, faster. The engineering leaders in this report demonstrate that trusted velocity is achievable not by slowing down, but by building the validation infrastructure that makes speed sustainable.