AI hit 65% of committed code a year early. Do we know what's in the box?

November is the season of planning decks and next-year budgets, and of slightly awkward moments when you put last year's predictions next to what actually happened. For most of us that comparison is humbling in the usual way (the project took longer, the budget got tighter). For AI coding, it went the other way.

A year ago, the developers and engineering managers in our first State of Code Developer Survey told us how much of their code AI was writing and how much they thought it would be writing soon. This year, we surveyed 1,026 developers and engineering managers globally to see what had changed. The short answer is that AI moved faster than respondents predicted, verification did not, and teams are already planning their next leap anyway. You can read all about it in this year’s State of Code Developer Survey report. 

Let's take a brief look at what the data says!

How fast did AI coding grow this year?

Last year, respondents who write code told us AI generated or significantly assisted 42% of the code they committed, and they expected that share to reach 55% within a year and 65% within two. They got to 65% in just one year.

The code AI writes also matters more than it used to. 76% of respondents say their team or company uses AI coding tools for business-critical or mission-critical services, up from 58% last year, so we're well past the stage where AI was mostly trusted with prototypes and side projects.

Who is verifying all this code?

Fewer people than you might hope, and the ones who do are running out of hours. 53% of respondents now spend more time reviewing code than creating it, compared with 18% who say that was true before they adopted AI tools. Despite all that extra review time, 76% of developers and engineering managers agree that "we generate AI code faster than we can verify it."

Trust is creeping up, which makes the picture more interesting rather than more reassuring. 45% of developers and engineering managers agree AI-generated code is functionally correct, up from 29% last year, yet only 6% agree completely (4% last year), which means 94% still do not fully trust it. At the same time, the share who completely agree they always check AI-generated code before committing fell from 48% to 39%. In other words, code that almost nobody fully trusts is getting checked less consistently, and it is going into software the business depends on.

Why is everyone suddenly talking about software factories?

Because teams are already building them. If we had asked anyone about autonomous software factories when we published our last survey back in January, the most likely answer would have been, “what software factories?” Now, 5% are building or have built software factories where agents work autonomously on tasks, and 34% expect to be creating or using one within a year. The appetite for autonomy is growing faster than the ability to verify what autonomy produces, and the more autonomy agents get, the more expensive it becomes when something slips through.

So what's keeping developers up at night?

According to respondents, quite a few things, and security worries top the list. Four of the top seven concerns about AI-generated code are about security: for example, 44% are very or extremely concerned about new or subtle vulnerabilities, and 42% about severe ones.

But the threat is no longer only about security of the code AI writes. 61% of developers and engineering managers are very or extremely concerned about attacks that use AI to find and exploit vulnerabilities faster and at greater scale in ALL code, including existing code, which makes it the top concern in this year's survey. If attackers are using AI to look for flaws around the clock, a vulnerability that waits for the next quarterly review has had plenty of time to be found by someone else first.

Is AI paying down technical debt or adding to it?

Both, for nearly everyone. 95% of respondents report at least one positive impact of AI-generated code on their team's technical debt (93% last year), and 89% report at least one negative impact (88% last year).

The most useful finding here is about what AI learns from. 78% of developers and engineering managers agree that when the quality of their codebase is high, it positively affects the quality of code AI tools generate, and 64% agree that when quality is low, it makes AI output worse. Think of an agent as a very fast new hire who copies whatever example sits closest in the codebase: if that example is clean, you get more clean code, and if it's a mess, you get the mess at agent speed.

When does verification happen, and does the timing matter?

For most teams it happens late, and the data suggests that timing is associated with outcomes. Among respondents whose teams review any AI code, 81% say AI code gets analyzed or verified at code review or pull request time, 51% in the CI/CD pipeline, and 43% as the agent generates code, in real time. 

Teams that run automated review inline, as their AI-generated code is written, report stronger outcomes than teams that do not. 61% of them say AI has had a positive impact on code security, compared with 46% of teams without inline review, and the gap holds for vulnerability rates (49% vs. 38%), code quality (75% vs. 63%) and time-to-market (89% vs. 81%). These are associations rather than proof of cause, but they point in a consistent direction: catching an issue while the agent still has the context is a lot cheaper than finding it in a pull request with three more changes built on top of it.

Are teams governing AI code, and does it pay off?

More teams govern AI code than a year ago, though far fewer govern it well. 55% of respondents now say their organization has guidelines, policies or quality gates for AI-generated code that differ from those for developer-written code, up from 41%. Only 23% describe well-defined, distinct guidelines or automated checks, up from 14%, while the most common approach is still informal rules enforced by hand (32%, up from 27%).

The difference between those two groups shows up in the results. Teams with well-defined rules are 31% more likely to say AI has had a positive impact on defect rates (66% vs. 51%) and 32% more likely to say the same for rework or patch costs (70% vs. 53%). They are also the only group where AI cut compliance risk more often than it raised it (23% reduced vs. 16% increased), which is a useful counterweight to the security worries above.

Why does ROI still feel out of reach?

Because the gains are real but smaller than expected, and a lot of the time saved gets spent elsewhere. 43% of respondents say AI coding has not yet delivered the return they expect: 47% expect an ROI of 50% or more from their AI coding tools, but only 27% report a return that high so far, and 22% are unsure what return they have seen at all.

Governance seems to be where the gap starts to close. 32% of respondents with governed agents report an observed ROI of 50% or more, compared with 19% of those with approved agents but informal, manual governance. 

Two things are holding them back. The first is toil, which hasn't gone anywhere: respondents estimate about 27% of their work is toil (24% last year), and 54% say it takes more than a quarter of their week, up from 38%. The second is cost, which rose more than any other concern we track, with 45% very or extremely concerned about the cost of advanced AI coding tools and agents, up from 30%.

Which AI coding tools are teams using now?

Claude had the biggest jump of any tool this year. 85% of respondents say they or their team used Claude or Claude Code for software development in the past year, up from 48%, while GitHub Copilot fell from 75% to 65% and Cursor rose from 31% to 41%. Interestingly, even though cost is a major concern, respondents who are talking about it choose model tiers much like everyone else, so cost worries haven't yet translated into cheaper model choices.

How much more are SonarQube users gaining from AI coding?

Noticeably more, on code quality & security as well as on productivity. Throughout this report, verification and governance kept coming up as the practices behind AI acceleration that actually pay off, with teams that have well-defined guidelines and early verification reporting higher ROI than teams that rely on informal rules and late review. That's exactly the job SonarQube is built for, and the SonarQube users among our respondents show what it looks like in practice.

SonarQube users are 81% more likely than non-users to say AI-generated code has had a very positive impact on code security, and similar gaps appear for vulnerability rates (65% more likely to report very positive impacts), defect rates (42%), technical debt (46%) and code quality (66%). They are also 39% more likely to report very positive impacts on developer productivity.

As with the other comparisons in the report, these are associations — the comparison doesn't adjust for company size, region or role — but SonarQube users are also more likely to have the practices this report keeps coming back to: well-defined guidelines, systematic context for agents, verification in CI, and measurement of results.

How do you build code confidence into a software factory?

Start by treating confidence as something you engineer rather than something you hope for. Here at Sonar, we describe it as a formula:

Code confidence = Intent × Guiderails × Verification × Evidence

Each element is multiplied, so if any one of them is zero, confidence is zero too. Excellent context with no independent verification still ships unchecked code, and rigorous review with no written standards has nothing consistent to check against.

1. Intent: Write your rules down as standards and constraints specific enough for agents to follow and for automated checks to enforce.
2. Guiderails: Give agents codebase context  and guiderails through a shared, systematic process, shift governance to start alongside the agent writing code, put controls on permissions and tool access, and keep the codebase healthy, since it's the example AI learns from.
3. Verification: Check every change independently, inline as the agent writes, at the pull request and in CI, and never let a model review its own work.
4. Evidence: Keep a record of what was checked and what the checks found, measure AI's impact on productivity and ROI before scaling further, and make token spend forecastable and tied to the shippable output.

So where should you start to optimize AI coding outcomes? 

Start with the element above that your team would rate closest to zero if you were being completely honest, and for many teams that will be intent. Only 23% of respondents describe well-defined, AI-specific guidelines or automated checks, which means most of the rules agents are expected to follow still live in reviewers’ heads, and turning them into something an agent can be checked against is a very practical first move.

Read the full State of Code Developer Survey 2027 report for more data and insights, along with a detailed look at each element of the code confidence formula, and get ready to move into autonomous software delivery that has something to show for itself: software you can confidently ship, returns you can report, and evidence you can stand behind when someone asks how you know it works.