AI code generation has delivered on its first promise. Teams are shipping more, covering more test cases, and moving faster than they could have imagined just a year ago. The productivity gains are real and the organizations that have leaned into AI adoption have proof points to show for it.
That first wave of wins is also creating a second wave of questions, and the engineering leaders who are building influence now are the ones who saw those questions coming.
The Quick Wins are Real; So is What Follows
Most teams start using AI code generation in low-risk, repetitive work: Documentation, unit testing, and simple functions. Data from recent research bears this out, and the productivity gains in these areas are real.
The problem is what happens at scale. As AI generates more code, it creates more to review, more to maintain, and more places for issues to hide. Review load compounds. Pull requests change in size, frequency, and composition. The code looks different than it used to, and reviewers who built their instincts on human-generated code are being asked to evaluate something with unfamiliar patterns and different failure modes.
The same research found nearly 80% of respondents already spend at least 10% of their time on code review, and about one in ten spend 41% or more.
Every AI-generated PR adds to a review queue that wasn’t built for this volume or this pace. More than 80% of organizations have already changed their development and release processes to accommodate it, and at more than a third of them, issues from AI-generated code still reach production often or sometimes. As DevOps.com reported earlier this year, the traditional approach of reviewing line-by-line changes is becoming impractical at AI-generated volumes.
The Questions are Already Here
Here’s what I think gets underestimated: the scrutiny coming at engineering leaders right now isn’t just technical. It’s financial and organizational.
Tokens aren’t free. As AI coding tools proliferate, the aggregate cost of API calls, completions, and agent loops adds up quickly. Leaders who can only point to velocity metrics when the CFO asks about ROI are going to struggle. The ones who can show which revenue-driving features shipped sooner, at what cost, and what it caught or missed are in a fundamentally different position. Atlassian’s Mike Cannon-Brookes made the same point recently: Engineering leaders need to understand the ROI of AI investment, and teams that can’t measure it are flying blind.
On the organizational side, AI-generated code has become an enterprise-wide concern. That same research also found security stakeholders have concerns at 63% of organizations, compliance teams at 52%, CTO/CIO leadership at 47%, and legal at 41%. That’s a cross-functional review committee, and most engineering leaders are walking into those conversations with ticket-based data and closed-issue counts, sourced from tools built for a human-speed world.
Both conversations require the same capability: showing what’s actually happening in the codebase, not just what was planned. Security issues, dependency changes, performance impacts, and architectural shifts are the kinds of changes hardest to detect week to week, and the ones that cause costly production incidents when they go unnoticed. The dependency risk alone is growing faster than most teams realize as AI accelerates the introduction of open source components without sufficient visibility into their maintenance status or security posture. The gap between leaders who have this capability and those who don’t will be career-defining.
What the Hesitant 35% Understands
One of the most telling findings in the survey: 44.7% of organizations already have AI-generated code in production while another 35% are actively writing code with AI but haven’t yet shipped it to production. That hesitant group isn’t necessarily moving slowly because they’re behind in AI adoption. They may not trust their ability to see and manage the risks.
The data supports their caution. Just 3.6% of respondents said AI-introduced issues never reach production.
The hesitant group is also investing more heavily in safeguards before they ship, with higher rates of code quality analysis, SCA, and training than their production-deployed counterparts. They have organizational buy-in for AI-accelerated development. What they’re still building is confidence in the code itself. They won’t ship what they can’t trust, and they can’t trust what they can’t see.
What Leaders Getting it Right are Doing
The engineering leaders I see doing this well have a few things in common.
They treat shipping AI-generated code as a governance decision, not just a tooling one. They invest in automated safeguards: code quality analysis (46% of survey respondents have already purchased this), automated review (39%), and a variety of security testing tools. They connect those safeguards to hard signals from the codebase rather than manual reporting from ticketing tools. They track review capacity alongside code velocity, because shipping faster only creates value if the team can see what changed and trust what they’re shipping.
And they build the visibility layer before they need to defend it. Ticket counts have never told the full story. Codebase signals do: what’s changing, where complexity is growing, where review capacity is falling behind. That’s what engineering leaders need to bring to these conversations.
AI creates a forcing function to build something engineering organizations have always needed and rarely had: continuous visibility into what’s actually happening across the codebase. The teams that use this moment to build that capability will come out of the AI transition stronger, more trusted by the business, and better positioned to keep accelerating without losing control.
The ones that don’t will struggle to explain incidents and ROI shortfalls, eroding the credibility they’ve built across the business.