AI-accelerated development is delivering on its promise. Engineering teams are shipping more code, moving faster, and we can all see that the productivity gains are real.
In a survey of 309 engineering leaders conducted by Dimensional Research for Flux, 67% of organizations already using AI-generated code report increased productivity, and nearly 45% have it running in production. That’s a snapshot from a single report, but it shows teams are getting real work done with AI coding tools, faster than they could have just a year ago.
Ecosystem of tools is evolving
The ecosystem of tools supporting that shift are maturing too. Automated code review, increasingly AI-powered, is becoming standard production tooling. The research showed that nearly 40% of organizations have already deployed it, and there are good reasons for that. These tools catch defects at submission, apply consistent standards, and provide feedback faster than human review processes can. Nearly two-thirds of engineering leaders in that same report believe AI could outperform humans at code review (at least in some ways). I’d agree with that. At scale, AI is better than humans at applying uniform standards consistently, and that matters a lot when you need to review more code than your team can realistically handle.
At the moment of submission, automated code review answers a specific question: does this change have defects I can detect right now? That’s the right question to ask at a pull request. But it’s a different question from what’s actually happening across your codebase week over week, where complexity is accumulating, and what patterns are forming that won’t become apparent until they trigger an incident. Those are visibility questions, and review tooling wasn’t designed to answer them.
That distinction matters more today than it did a few years ago. AI-accelerated development has changed the volume, velocity, and characteristics of the code entering production. Teams are generating more code, more quickly. Often, that code looks polished and sophisticated at first glance, which can make it harder to catch issues in review. And code review is inevitably time-consuming. Our survey found that nearly 80% of engineering teams already spend at least 10% of their time on code review, and about one in 10 spend more than 40% of their time there.
Most teams simply can’t handle the increased volume, and review capacity isn’t scaling with AI-accelerated code output. It’s not just more code, either. It’s also more potential risk. Volume obscures small changes with significant downstream consequences. Security issues slip through, simply because there’s too much to evaluate at that level of detail. Nearly half of the respondents indicated that they struggle to detect security issues week to week, and dependency changes and performance impacts aren’t far behind. Only 3.6% of respondents said AI-introduced issues never reach production. For most teams, this is a known, recurring reality.
Architectural changes hard to detect
I talk with engineering leaders regularly who are wrestling with exactly this challenge. They adopted AI coding tools, watched velocity go up, invested in automated review to catch problems at the gate, and then discovered months later that issues had accumulated in their codebase that their review processes hadn’t caught. This isn’t an issue of a reviewer missing a bug, which can always happen. The architectural changes, however, are hard to detect, especially when nobody has visibility into the week-over-week drift. The incidents that follow might look like failures of review, but they are actually failures of visibility.
Visibility into a codebase means something specific: knowing what changed, where, and why, across time and across teams. It means seeing complexity grow in a module before it becomes unmaintainable, and catching when generative AI replicates patterns from existing code so that antipatterns spread across services without anyone noticing.
Tickets, retrospectives, and engineer-flagged issues can’t show you that. Continuous signals from the code itself can.
The right mental model is layers. Automated code review belongs in every engineering organization shipping AI-generated code—catching defects before they merge does prevent a lot of issues. But it operates on individual changes at the point of submission.
Codebase visibility operates on the system, continuously. It means knowing that a dependency shifted three weeks ago in a way that your security team would want to know about, or that a module has been accumulating complexity across a dozen commits in ways no single PR can reveal. Those signals don’t come from reviewing individual pull requests or Jira tickets. They come from watching the codebase change over time.
Most engineering leaders I talk with already know something is missing. They have review coverage, but they don’t have the week-over-week picture of what AI is doing to their codebase. Getting that picture means recognizing that shipping AI-generated code at scale is a different problem than reviewing it, and treating it accordingly.
