Automated Code Review is Not a Visibility Tool

AI-accelerated developments deliver on their 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 are already using AI-generated code reporting to increase productivity, and nearly 45% are working on productivity. That’s just a summary from one report, but it shows that teams are doing real work with AI coding tools, faster than they could a year ago.
The tools ecosystem is evolving
The ecosystem of tools that support that change is also growing. Automated code review, increasingly powered by AI, is becoming a standard productivity tool. Research has shown that almost 40% of organizations have installed it, and there are good reasons for that. These tools catch errors in submissions, use consistent standards, and provide feedback faster than human review processes. Nearly two-thirds of engineering leaders in that same report believe AI can surpass humans in code reviews (at least in some ways). I would agree with that. At scale, AI is better than humans at applying the same standards consistently, and that’s especially important if you need to review more code than your team can realistically handle.
During submission, the automatic code review answers a specific question: does this change have a defect that I can see right now? That’s a good question to ask in a pull request. But it’s a different question to what’s really happening throughout your codebase week-to-week, where it accumulates, and what patterns build up that won’t show up until they trigger an event. Those are questions of visibility, and review tools aren’t designed to answer them.
That distinction is more important today than it was a few years ago. The accelerated development of AI has changed the volume, speed, and productivity aspects of coding. Teams produce more code, more quickly. Often, that code looks polished and confusing at first, which can make it difficult to catch problems in their review. And code reviews are definitely time consuming. Our survey found that nearly 80% of development teams already spend at least 10% of their time on code reviews, and nearly one in 10 spend more than 40% of their time there.
Most teams simply cannot handle the increased volume, and review volume does not increase with AI-accelerated code output. It’s not just extra code, either. It is also very dangerous. Volume hides small changes with significant downward effects. Security issues are overlooked, simply because there is so much to check at that level of detail. Almost half of the respondents indicated that they struggle to find security issues on a week-to-week basis, and changes in dependencies and performance impact are not far behind. Only 3.6% of respondents said that the problems presented by AI do not extend to productivity. In many groups, this is a well-known, repeated fact.
Structural changes that are hard to see
I talk to engineering leaders all the time who are grappling with this challenge. They adopted AI coding tools, watched speeds increase, invested in automated reviews to catch problems at the gate, only to discover months later that problems were piling up in their codebase that their review processes hadn’t caught. This is not a problem that the reviewer missed an error, which can always happen. Structural changes, however, are difficult to detect, especially when no one is able to be seen from week to week. The following events may look like update failures, but they are actually visibility failures.
Visibility into the codebase means something specific: knowing what has changed, where, and why, over time and across groups. 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 stories flagged by developers can’t show that. Continuous signals from the code itself.
A proper mental model for layers. Automated code review is for all engineering organizations deploying AI-generated code—catching errors before they are compiled prevents many problems. But it works with individual changes in the shipping area.
Codebase visibility works on the system, continuously. It means knowing that a dependency has changed in the last three weeks in a way that your security team would like to know, or that a module has been accumulating complexity in many implementations in ways that no single PR can express. Those symptoms don’t come from reviewing individual pull requests or Jira tickets. They come from watching the codebase change over time.
Most of the engineering leaders I talk to already know that something is missing. They have an overview of the updates, but they don’t have a week-by-week picture of what the AI is doing in their codebase. Getting that picture means realizing that deploying AI-generated code at scale is a different problem than revising it, and managing it properly.




