I’ve noticed a pattern with how teams adopt AI coding assistants. Individuals start using Claude or Cursor, feel dramatically more productive, and tell their teammates. Adoption spreads organically. Management sees the enthusiasm and starts wondering about scaling it across the organization. Then something interesting happens. Teams hit a wall that has nothing to do with the technology itself.

The productivity gains that felt obvious at the individual level start getting eaten by code review. Not because the generated code is wrong exactly, but because it needs more scrutiny than human-written code. Recent report from CodeRabbit mentiond that AI-generated pull requests contain about 1.7x more issues compared to human-written code. When you’re the one writing and reviewing your own AI-assisted code, you catch most of these immediately because the feedback loop is tight. You see the weird suggestion, fix it, move on. But when that code goes to code review, someone else has to spend significantly more time finding those same issues.

It’s because the failure modes aren’t always obvious. Recent security analysis shows that nearly half of AI-generated code fails basic security tests, and other reports show that AI code introduces 3 times more privilege escalation paths compared to human-written equivalents. The nasty ones are what an IEEE article calls as silent failures: code that runs fine, passes tests, but doesn’t actually do what it’s supposed to because the model removed safety checks or generated plausible output that matches the expected format without implementing the actual logic.

What makes this tricky is what devs feel. You feel faster when you’re churning out code like nobody’s business. But METR research on AI coding assistants found developers were 19% slower overall while being convinced they were faster (albeit in a limited setting). I like to think of that gap as the verification tax where devs spent more time fixing AI-generated code than they saved generating it, but that cost is diffuse enough that it doesn’t register as “AI made me slower.” It registers as “code review took longer this sprint” or “we had more bugs in production” without a clear line back to the root cause.

For individuals working alone and focused, this tax stays manageable because the feedback loop is immediate. You’re still in context when you review what the AI generated. You know what you were trying to do. Autocomplete for boilerplate works great. Simple refactoring where you’re watching the diff works fine. The narrow use case genuinely improves productivity. But when you try to scale that pattern across a team, the verification work becomes distributed and the cost compounds. Code review turns into a bottleneck because reviewers need to scrutinize AI-generated code more carefully, but they’re often not told which code was AI-assisted, and even when they know, they’re working with less context than the original author had.

I’ve seen teams handle this by retreating to selective scaling rather than trying to use AI everywhere. Use internal tool for search, Gemini for research, claude-code for generation, and so on where verification stays cheap while staying manual for tests or code-reviews. But this atomized approach misses potential compound benefits for the end-to-end flow. While some of this can be protected through high-judgement of experienced engineers, you can’t have them actively verifying every AI-generated PR. In fact that AI-assisted commits merge 4x faster suggests teams aren’t perhaps reviewing them as carefully. It would explain the privilege escalation issues showing up later.

Part of why teams stay narrow is probably how these tools were built and marketed. Copilot’s entire demo flow is autocomplete. You type a function signature, it fills in the body, you keep your hands on the keyboard and eyes on the screen. That immediate verification loop is baked into the design. Same with how Cursor shows you diffs in real-time during refactoring. The marketing focuses on “write code faster” without talking about what happens downstream when someone else has to review that code without your context. When teams try to go broader like “let’s use AI to generate entire features” or “let’s have AI write our tests”; they’re now outside the narrow context these tools were optimized for and the failure modes show up.

The adoption numbers reflect this struggle that comes after. There’s massive and impressive stats which makes the “everyone is using AI in the editor” narrative basically true at this point but anecdotally I find full production rollouts are still a small minority compared to pilots and experiments with recent papers also finding that most real-world agents are simple and tightly controlled (short workflows, off-the-shelf models, heavy human evaluation); suggesting that teams are still doing the verification math and only scaling agents when they can keep verification tractable.

For most engineering organizations, at least for now, AI coding assistants end up being useful individual productivity tools in specific contexts rather than something that transforms team dynamics or development velocity. That’s probably the honest assessment even if it’s less exciting than the transformation narrative. The interesting question isn’t whether to adopt AI coding tools (that ship has sailed), it’s whether we’re setting ourselves up for a productivity debt crisis similar to technical debt, where the accumulated cost of inadequate verification only becomes visible when you try to move fast at scale. The teams avoiding that fate have probably figured out something specific about contexts where verification cost stays manageable, but that knowledge isn’t spreading the way “use AI to code faster” has.