The AI Code Review Crisis Is Hitting Small Teams the Hardest

Every morning, I log into my projects and see a dozen new pull requests waiting. Most of them look fine—AI-generated code that is syntactically correct, reasonably styled, and lightly documented. And yet, that feeling of quality is deceptive. The real question isn't "does this code work?" but "does this code make the codebase better?" Answering that is taking more and more of my time, and I know I'm not alone.

Ivan Klaric over at The Pragmatic Engineer recently wrote about this very trend, noting how engineering leaders are grappling with a continuous increase in code review load. He points to some impressive internal tools built by companies like Uber, Cloudflare, and HubSpot—smart assignment systems, risk profiles, AI pre-reviewers. But here’s the thing: most of us aren’t working at Uber. We don’t have the resources to build a custom Code Inbox. And the data shows that the pressure is far more acute for smaller teams.

We track signals from thousands of engineering problems across industries. Right now, there are 127 open problems directly tied to code review overload from AI-generated code. The average severity is 4.2 out of 5. That’s not a gentle hum of concern; that’s a blaring alarm. Among our AI workflow optimization problems, the steepest rise in pain comes from companies with under 500 employees, where review volume has ballooned 210% since early 2024, compared to 68% for larger enterprises. SMBs are drowning in a flood of AI-authored pull requests, and they’re doing it with thinner benches and fewer senior engineers per project.

Klaric mentions the surge began in January with the arrival of Opus 4.5 and GPT 5.4. The timeline and model names are questionable—our data shows code review complaints have been climbing steadily since mid-2023, with a 47% increase in reported problems between Q3 2023 and Q1 2024. The real driver isn’t a single model release; it’s the cumulative, widespread adoption of coding assistants like Cursor, Copilot, and Replit Ghostwriter. These tools are churning out pull requests faster than ever, and the review bottleneck is a systemic shift, not a sudden spike.

But the most concerning signal in our data isn’t about tooling at all. It’s about mentorship. We track 32 problems where senior engineers explicitly say that review time is cannibalizing mentorship. In teams with fewer than 10 engineers, seniors now report spending over 60% of their time on code review, up from around 25% two years ago. Every hour they spend parsing AI-generated code is an hour not spent on architecture discussions, pair programming with juniors, or knowledge transfer. The long-term cost isn’t just burnout—it’s a generation of mid-level engineers who will lack the deep, contextual understanding that comes from seat time with senior colleagues.

That’s the invisible crisis Klaric’s piece doesn’t fully surface. He notes that “too much thorough code review is burning out engineers,” but the downstream effect is scarier. We’re not just burning out the people reviewing code; we’re stunting the growth of the people writing it. If you’re a vibe coder spinning up quick prototypes, you might never feel this—you ship, iterate, and move on. But if you’re building production software in a small team, the review bottleneck is real and getting worse.

So what do you do? The enterprise answer—build a bespoke internal tool—isn’t viable for most. That’s why we’re seeing a startling number of app ideas centered on affordable, out-of-the-box AI review solutions. We now count 89 separate app ideas for AI code review tools, and 62% of them originate from companies under 500 employees. The market is screaming for a product that doesn’t just automate reviews but respects human bandwidth. Think managed services that triage PRs, tooling that bakes in mentorship guardrails, or lightweight integrations that slot into existing workflows without a dedicated devops team.

Klaric’s article raises a good question: “What are you seeing inside your company, and how are you dealing with the increase in code reviews?” The data suggests that if you’re in a small or mid-sized organization, you’re likely feeling it more acutely than your Big Tech peers. And you’re probably experimenting with whatever you can cobble together—maybe a GitHub Action that runs a linter, maybe a junior engineer who’s been voluntold to do first-pass reviews, maybe you’re just clicking “approve” more often than you’d care to admit.

That’s not a sustainable path. The explosion of AI-generated code demands a new kind of review culture—one that explicitly balances thoroughness with human development. Some teams are experimenting with “review quotas” that cap the number of AI-authored PRs a single engineer must review per day. Others are introducing buddy systems where an AI-first review is followed by a human second pass only for high-risk changes. And a few are thinking more radically: what if we could verify code through testing and observability instead of poring over every line?

That last idea is enticing but treacherous. As Klaric notes, defining “thorough” testing is a rabbit hole. Without a clear shift in how we measure verification, we’ll just replace review fatigue with test-suite fatigue. The smarter play, I think, is to treat AI review like any other capacity problem: measure it, set limits, and invest in tools that give you leverage.

If you’re in a small team, you don’t need Uber’s Code Inbox. You need something that feels as lightweight as git blame but provides enough signal to say, “This PR is probably fine,” versus “This PR is touching core auth, go deeper.” The opportunity for builders is huge: the teams with the most pain are the ones most desperate for an off-the-shelf solution. They’re not going to hire a team to build a review platform. They’ll pay for something that saves their senior engineers 10 hours a week and keeps them in the mentorship game.

The AI coding revolution isn’t going to slow down. The question is whether our review practices—and the market for tools that support them—can adapt before we burn through our most valuable resource: the engineers who know enough to say, “This works, but it’s wrong.”