← All articles

How Much Code Does AI Write in 2026? The Real Data

Published · by theCoders · 35 min read
How much code AI writes in 2026 — near-total adoption, exploding volume, but quality metrics going down

Just three years ago, AI coding assistants were still viewed as an emerging technology. Today, they are part of the daily workflow for almost every software engineering team.

The conversation has changed just as quickly.

We are no longer relying on bold predictions, marketing claims, or isolated success stories. For the first time, we have something far more valuable: large-scale datasets, randomized controlled studies, engineering telemetry, and millions of real-world commits that reveal how AI is actually changing software development.

The overall picture is remarkably consistent.

AI adoption is approaching saturation. The amount of code being produced has increased dramatically. Yet many of the metrics that describe software quality, maintainability, and developer confidence are moving in the opposite direction.

This is not another article arguing whether AI is good or bad.

It is an article about what happens when you automate the cheapest part of software development—writing code—while leaving the hardest parts almost untouched: architecture, product decisions, code review, security, and long-term maintenance.

The data tells a far more interesting story than the headlines.

How much code AI writes in 2026 — real data from companies, randomized studies and telemetry from millions of commits

1. How Much Code Is AI Actually Writing?

The first numbers come directly from the CEOs of the world’s largest technology companies. They are worth paying attention to—but they should also be interpreted carefully. These figures are self-reported, and none of the companies have published the exact methodology behind their measurements.

Microsoft has been one of the most transparent organizations on this topic.

During LlamaCon in April 2025, CEO Satya Nadella stated that between 20% and 30% of the code in Microsoft’s repositories is now written by software. He also pointed out that performance varies significantly between programming languages: AI-generated Python code is already “fantastic,” while C++ still lags behind.

Google tells a similar story.

Sundar Pichai first announced that AI was generating approximately 25% of Google’s new code, before later updating that figure to well above 30%.

Meta has made even bolder predictions.

Mark Zuckerberg publicly suggested that AI could soon be responsible for roughly half of all software development inside the company, while Microsoft’s CTO Kevin Scott believes AI could generate 95% of all code within the next five years.

Those numbers are impressive.

But there is an important nuance that often disappears once these statements reach headlines.

“Written by AI” does not mean “shipped without human involvement.”

Pichai has repeatedly emphasized that every AI-generated suggestion still goes through human review before becoming production code. These percentages describe who typed the code—not who made the engineering decisions.

That distinction matters.

There is also a far more conservative, independent measurement.

According to a SemiAnalysis report cited by METR, only around 4% of GitHub commits are currently authored by Claude Code.

The gap between “30% of the code” and “4% of commits” does not necessarily mean that one figure is wrong.

It simply illustrates that different organizations are measuring different things.

Some count generated characters.

Others count commits.

Others estimate developer assistance across internal repositories.

Without a common methodology, these percentages should not be compared directly.

Instead, they should be viewed as different perspectives on the same rapidly evolving phenomenon.

Key takeaway: AI is already responsible for generating a meaningful share of the code produced inside the world’s largest technology companies. However, engineering ownership, architectural decisions, and production responsibility remain firmly in human hands.

2. AI Adoption Is Nearly Universal. Trust Is Moving the Other Way.

If the figures reported by major technology companies leave room for interpretation, the data on AI adoption is far more robust.

Unlike executive estimates, these numbers come from large-scale industry surveys that are repeated year after year using consistent methodologies. They provide one of the clearest pictures of how software engineers actually use AI in their daily work.

And the conclusion is straightforward:

AI is no longer experimental. It has become part of modern software development.

The 2025 DORA Report, published by Google Cloud and based on responses from approximately 5,000 technology professionals alongside more than 100 hours of interviews, shows that AI has rapidly become a standard development tool rather than an optional productivity experiment.

The report highlights several key findings:

  • 90% of developers now use AI at work, up 14% compared to 2024.
  • The median developer spends around two hours per day using AI tools—roughly a quarter of the average workday.
  • More than 80% believe AI has improved their productivity.
  • At the same time, 30% report having little or no confidence in AI-generated code.

On the surface, those numbers seem contradictory.

How can developers rely on AI more than ever while trusting it less?

The answer becomes even clearer when we look beyond DORA.

The Stack Overflow Developer Survey 2025, based on responses from more than 49,000 developers across 177 countries, paints almost exactly the same picture.

AI adoption continues to rise.

Trust continues to fall.

Among the survey’s most notable findings:

  • 84% of developers either already use or plan to use AI development tools, up from 76% the previous year.
  • Concern about AI accuracy increased from 31% in 2024 to 46% in 2025.
  • 66% identified “almost correct” answers as their biggest frustration.
  • 45% said debugging AI-generated code consumes a significant amount of their time.

This is perhaps the most interesting trend in the entire dataset.

Adoption and confidence are moving in opposite directions.

The more developers use AI, the more they understand both its strengths and its limitations.

That is exactly what usually happens when a technology matures.

Early users tend to focus on what it can do.

Experienced users learn where it fails.

Today’s AI coding assistants are no longer viewed as magical programming machines capable of solving every problem.

Instead, they have become something much more practical: a powerful accelerator that still requires constant human supervision.

The comparison is surprisingly simple.

Think about your smartphone’s autocorrect.

Most people use it every day.

Very few people trust it enough to send an important email without reading it first.

AI-assisted programming is beginning to occupy the same space.

Developers rely on it because it makes them faster.

They verify it because they know it can still be wrong.

Key takeaway: AI adoption is no longer the story. It has already happened. The new challenge is confidence—how much organizations can trust AI-generated code, and how much human review is required before that code reaches production.

3. The App Explosion: When Supply Outgrows Demand

So far, we’ve looked at how AI is changing the way software is built.

The next effect is even more visible.

AI isn’t just helping developers write code faster—it is dramatically reducing the cost of creating software. And when the cost of production falls, the amount of production usually rises.

That is exactly what we are seeing today.

According to data from Sensor Tower, cited by The Information and The New York Times, the mobile app market has entered a completely new phase. After nearly a decade of declining app releases, AI-assisted development has triggered one of the fastest rebounds the industry has ever experienced.

The numbers tell the story.

YearNew App Store Apps
2016~890,000 (all-time record)
2022~420,000
2024Continued decline (−46% vs. 2016)
2025~600,000 (+30%)
H1 2026~560,000

During the first quarter of 2026 alone, developers released 235,800 new applications, an 84% increase compared to the same period the previous year.

If this pace continues, 2026 will become the first year in history to surpass one million new App Store applications, breaking the previous record set nearly a decade earlier.

That is an extraordinary shift.

Ten years of declining app production have effectively been reversed in less than two years.

At first glance, this looks like an enormous success story.

Software has never been easier to build.

But that is only half of the story.

The other half is far more important.

While the supply of applications is exploding, user demand is barely moving.

Global app downloads increased by only 3% throughout 2025 and by another 2% during the first half of 2026.

In other words, developers are creating software dramatically faster than users are consuming it.

That changes the economics of software entirely.

For years, building an application was the difficult part.

Today, building is often the easiest part.

Getting discovered has become the real challenge.

Another data point reinforces the same conclusion.

Since early 2024, Google Play has removed approximately 1.8 million applications, reducing its catalog from roughly 3.4 million to 1.8 million apps.

Meanwhile, Apple’s App Store is experiencing the opposite trend, with a rapid increase in newly published software.

Different platforms. Different strategies. The same underlying pressure.

One marketplace is aggressively removing low-quality applications.

The other is being flooded with new ones.

Both are reacting to the same structural change: software has become dramatically cheaper to produce.

This is the first of three recurring patterns that appear throughout this article.

Quantity rises rapidly.

Value grows much more slowly.

AI has made production cheaper. It has not made attention any cheaper. And attention—not code—is rapidly becoming the scarcest resource in the software industry.

Key takeaway: AI has dramatically lowered the cost of building software, but it has done almost nothing to reduce the cost of getting users. In a world where nearly anyone can build an application, competitive advantage no longer comes from shipping faster—it comes from building something people actually discover, adopt, and continue to use.

4. What Actually Got Faster?

After reading the previous sections, it would be easy to conclude that AI is creating more problems than it solves.

That would be an unfair conclusion.

Because the productivity gains are real.

The data leaves very little room for debate on that point.

AI is helping developers write more code, complete more work, and ship software faster than before.

The real question is not whether AI improves productivity.

The real question is how much of that improvement comes from AI itself—and how much comes from the people using it.

The 2025 DORA Report provides one of the strongest pieces of evidence.

Compared to its 2024 findings, DORA reports a significant shift: AI adoption is now positively associated with software delivery throughput.

In simple terms, engineering teams are shipping more.

That may sound obvious today, but it wasn’t obvious a year earlier.

In the 2024 report, the relationship between AI usage and delivery performance was either weak or even slightly negative.

What changed?

Most likely, developers did.

During the first wave of AI adoption, engineers spent a considerable amount of time experimenting with prompts, learning the strengths and weaknesses of different tools, and figuring out how AI fit into their workflow.

By 2025, much of that learning curve had disappeared.

Teams had learned where AI delivers value—and where it doesn’t.

As a result, productivity improvements became measurable rather than anecdotal.

The same trend appears in telemetry collected by Faros AI, which analyzed engineering activity across approximately 22,000 developers.

Their findings are impressive:

  • 21% more completed tasks
  • 98% more merged pull requests
  • 66.2% more completed epics per developer in the 2026 dataset.

Looking only at these numbers, the conclusion seems obvious.

AI is making developers dramatically more productive.

But this is exactly where statistics become dangerous.

Because correlation is not causation.

GitClear explored this question in much greater detail.

When they compared developers who actively use AI with those who rarely do, they found that AI users appeared to produce between four and ten times more output.

At first glance, that sounds extraordinary.

It would also be the perfect marketing headline.

Except it isn’t the full story.

Instead of comparing different developers, GitClear compared the same developers against their own historical performance before adopting AI.

The result changed dramatically.

Rather than being four to ten times faster, developers improved by a much more modest approximately 25%.

That distinction matters.

It suggests that a significant part of the observed productivity gap already existed before AI entered the picture.

High-performing engineers were already high performers.

They simply became the earliest and most effective adopters of AI-assisted development.

This is one of the clearest examples of the difference between correlation and causation.

The best developers tend to adopt the best tools first.

That does not necessarily mean the tools are the reason they became the best developers.

Strong engineering cultures adopt new technology faster because they already have the discipline, processes, and technical maturity needed to benefit from it.

That observation also explains why vendor case studies often look spectacular.

Technology companies naturally highlight customers who achieved exceptional results.

Those customers are frequently organizations that were already operating at a very high level before AI entered the workflow.

The technology amplifies existing strengths.

It rarely creates them from scratch.

None of this diminishes AI’s impact. The productivity gains are real. But they are more nuanced than marketing narratives often suggest.

AI is not a magic multiplier that instantly turns average teams into elite engineering organizations.

It is a force multiplier. And, like every force multiplier, its impact depends heavily on the quality of the team using it.

A well-organized engineering team with strong architecture, automated testing, mature review processes, and experienced developers will usually extract enormous value from AI.

A poorly organized team will simply produce poor code at a much higher speed.

Key takeaway: AI delivers measurable productivity gains, but those gains are often smaller than they first appear. Much of the observed performance difference comes from the fact that the strongest developers and engineering organizations adopt new tools earlier and use them more effectively. AI accelerates capable teams—it does not replace engineering excellence.

More code doesn't mean better software — adoption and volume rise, but code quality goes down

5. What Got Worse?

Up to this point, the data paints a fairly optimistic picture.

AI is helping developers write more code.

Teams are completing more work.

Software is being delivered faster than ever before.

But every productivity gain raises an obvious question:

What happens to code quality when software production accelerates this dramatically?

This is where one of the largest engineering studies published in recent years becomes particularly important.

GitClear analyzed 623 million code changes made between 2023 and 2026, tracking eight different indicators of software quality and comparing them against the period before AI-assisted development became mainstream.

The dataset is enormous.

More importantly, it doesn’t measure opinions.

It measures how developers actually write software.

The overall conclusion is surprisingly simple:

We are producing significantly more code than ever before. We are maintaining significantly less of it.

Risk indicators are rising

GitClear identified several engineering patterns that are generally associated with higher long-term maintenance costs and lower software quality.

Nearly all of them moved in the same direction.

Among the most significant findings:

  • Duplicated code blocks increased by 81%, reaching the highest level ever recorded.
  • Copy-and-paste within the same commit increased by 41%.
  • Error-masking constructs increased by 47%.
  • Code rewritten within the first two weeks after being committed increased by 15%.

None of these metrics, by themselves, prove that AI writes poor code.

But taken together, they reveal a clear shift in engineering behavior.

More duplication means the same logic now exists in multiple places.

More copy-and-paste means less reusable architecture.

More error-masking patterns usually mean bugs become harder to discover.

And when newly written code needs to be rewritten almost immediately, it often suggests that initial implementation is being prioritized over long-term quality.

In other words, development becomes faster.

Maintenance becomes more expensive.

The opposite trend appears in software maintenance

Perhaps even more revealing is what developers are doing less often.

GitClear observed substantial declines in several indicators that are typically associated with healthy software engineering practices.

Among them:

  • Refactoring activity fell dramatically, with moved lines dropping from 21% of all code changes in 2022 to just 3.8% in 2026.
  • Function connectivity declined by 35%.
  • Maintenance work on code older than one year fell by 74%.

These numbers may sound technical, but their business implications are straightforward.

Healthy software is not built solely by adding new features.

It is also built by improving existing architecture, simplifying old implementations, removing duplication, and continuously paying down technical debt.

Those activities become increasingly rare when generating new code becomes almost effortless.

Instead of improving existing components, teams often create entirely new ones.

The software grows.

Its architecture doesn’t necessarily mature with it.

From refactoring to duplication

One of the most striking observations in GitClear’s report is how dramatically engineering priorities appear to have shifted.

In 2022, developers were roughly twice as likely to refactor existing code as they were to duplicate it.

By 2026, that relationship had completely reversed.

Today, developers are approximately five times more likely to duplicate code than to consolidate it through refactoring.

That single statistic captures one of the most important side effects of AI-assisted development.

Writing another function is now incredibly cheap.

Stopping to redesign an existing system is not.

Generating new code takes seconds.

Understanding years of existing architecture still takes experience.

As a result, many teams naturally choose the faster option.

Not because it is better engineering.

Because it is easier.

”Perpetual Version One”

GitClear describes this phenomenon with an unusually memorable phrase:

“Perpetual V1 Components.”

The concept is surprisingly simple.

Software components no longer go through the traditional lifecycle of continuous refinement.

Instead of being simplified, reorganized, and strengthened over time, they remain permanently stuck in their first iteration while additional layers of code accumulate around them.

The software continues to work.

It even continues to grow.

But internally, it becomes increasingly difficult to understand, modify, and maintain.

This may explain why so many engineering teams report feeling simultaneously more productive and more overwhelmed.

They are shipping software faster than ever before.

Yet the codebase itself is becoming progressively harder to navigate.

Not because AI is producing fundamentally bad code.

But because AI makes producing new code dramatically easier than improving existing code.

The second divergence

Earlier in this article we identified the first major divergence.

The supply of software is growing much faster than user demand.

Now a second pattern emerges.

Code volume continues to rise. Code structure continues to decline.

Those two trends appear repeatedly across multiple datasets, collected using completely different methodologies.

AI is making software production cheaper.

It is not making software architecture easier.

And those two things should never be confused.

Key takeaway: AI is dramatically increasing software output, but much of that growth comes from creating new code rather than improving existing systems. As code generation becomes cheaper, refactoring, architectural cleanup, and long-term maintenance risk becoming increasingly neglected—allowing technical debt to accumulate much faster than before.

6. Security: Syntax Has Improved. Security Hasn’t.

One of the most common arguments in favor of AI-assisted development is that today’s models produce remarkably good code.

And that’s true.

Compared to the first generation of coding assistants, modern AI systems generate cleaner syntax, produce fewer compilation errors, understand larger codebases, and solve increasingly complex programming tasks.

But there is a crucial distinction that often gets overlooked.

Code that works is not necessarily code that is secure.

And this is exactly where the data becomes far less encouraging.

One of the most comprehensive studies on this topic comes from Veracode, which evaluated more than one hundred large language models across eighty programming tasks covering Java, JavaScript, Python, and C#.

The objective was not simply to measure whether AI could generate working code.

It was to determine whether that code could withstand real-world security standards.

The results were sobering.

On average, 45% of AI-generated solutions introduced vulnerabilities that fall within the OWASP Top 10, the industry’s most widely recognized list of critical software security risks.

Java performed particularly poorly, reaching a failure rate of approximately 72%.

These figures should not be interpreted as saying that half of all AI-generated software is insecure.

What they do demonstrate is something equally important:

AI-generated code should never be assumed to be secure simply because it looks correct.

A convincing solution can still contain serious vulnerabilities.

A clean implementation can still expose an application to attack.

And a successful compilation says nothing about whether the software is safe to deploy.

AI has become exceptionally good at syntax

The most interesting part of Veracode’s research is not the snapshot itself—it is the trend.

Between 2023 and 2026, the models improved at an astonishing pace in one specific area.

Syntactic correctness increased from roughly 50% to well over 95%.

In practical terms, today’s models produce code that compiles successfully almost all the time.

Anyone who experimented with early coding assistants has experienced this firsthand.

Three years ago, developers routinely encountered missing imports, undefined variables, incorrect APIs, or code that simply failed to compile.

Those problems have become dramatically less common.

From a syntax perspective, AI has improved faster than almost anyone expected.

Security tells a completely different story

Unfortunately, the same progress has not occurred in software security.

While syntactic correctness has nearly doubled, security test pass rates have remained largely unchanged, fluctuating between 45% and 55% over the same three-year period.

That difference is one of the most important findings in the entire report.

AI has become extremely good at producing code that executes correctly.

It has not become equally good at producing code that is resilient against real-world attacks.

The distinction matters because developers naturally gain confidence when code compiles successfully.

But compilation only proves that software is executable.

It says nothing about authentication flaws, authorization mistakes, injection vulnerabilities, insecure object references, or dozens of other security issues that only become visible once an application is deployed—or attacked.

Bigger models don’t necessarily produce safer software

Another surprising observation from Veracode is that increasing model size does not significantly improve security performance.

Whether the model contains 20 billion parameters or 400 billion parameters, the security results remain remarkably similar.

That challenges one of the common assumptions surrounding large language models.

Larger models generally produce more fluent explanations.

They often generate more complete implementations.

They frequently solve more difficult programming tasks.

Yet none of those improvements automatically translate into stronger application security.

In other words:

Better code generation does not necessarily mean better secure code generation.

Why does this happen?

The explanation is probably more economic than technological.

Syntax is relatively easy to optimize.

A compiler provides immediate feedback.

The code either builds or it doesn’t.

Tests either pass or fail.

Those signals are objective, inexpensive to generate, and available in enormous quantities for model training.

Security works differently.

There is no compiler that can instantly determine whether an application is truly secure.

Many vulnerabilities only emerge under very specific runtime conditions.

Others depend on business logic, infrastructure, user behavior, or attack scenarios that are impossible to infer from code alone.

Security is contextual.

It is also largely defined by the absence of failures rather than the presence of correct syntax.

That makes it dramatically more difficult to optimize automatically.

As a result, AI models have become exceptional at generating software that looks correct.

They have made far less progress at generating software that is provably secure.

Machine learning tends to improve fastest wherever feedback is cheap, immediate, and objective.

Compilation errors satisfy those conditions.

Security vulnerabilities usually do not.

The third divergence

Earlier we identified two recurring patterns.

The first was that software supply is growing much faster than user demand.

The second was that code volume is increasing much faster than code quality and maintainability.

Security reveals exactly the same pattern.

Syntax is improving rapidly. Security is not. We covered what engineering teams should do about it in our guide to AI security for development teams.

It is the third major divergence found throughout the available data—and perhaps the most important one for organizations building production software.

Because vulnerabilities rarely become expensive when code is written.

They become expensive when they are discovered.

Key takeaway: AI has become exceptionally good at generating syntactically correct code, but there is little evidence that it has made comparable progress in software security. Organizations should treat AI-generated code exactly like third-party code: every change still requires code review, automated testing, and dedicated security validation before reaching production.

7. The Study That Broke Itself — And Why It’s the Most Important Result

So far, we’ve looked at surveys, engineering telemetry, and hundreds of millions of code changes.

Those datasets are incredibly valuable, but they all share one limitation.

They describe what is happening in the real world.

They do not necessarily prove why it is happening.

To answer that question, researchers need something much stronger than observational data.

They need a randomized controlled experiment.

That is exactly what METR (Model Evaluation & Threat Research) attempted to conduct in 2025.

Ironically, the study became famous not because it produced a definitive answer—but because the experiment itself started falling apart.

And that may be the strongest evidence of AI adoption the industry has today.

The first serious randomized trial

In July 2025, METR conducted one of the first large randomized controlled studies on AI-assisted software development.

The experiment involved 16 experienced software engineers, working on 246 real tasks taken from their own open-source repositories.

The design was straightforward.

Each task was randomly assigned to one of two conditions:

  • completed with AI assistance, or
  • completed without AI assistance.

Unlike surveys or productivity reports, this approach attempted to isolate the actual effect of AI by removing as many outside variables as possible.

If AI truly made developers faster, this experiment should have measured it.

The results surprised everyone—including the researchers themselves.

Instead of accelerating development, AI-assisted tasks took 19% longer to complete on average.

At first glance, the conclusion seemed shocking.

How could an industry that was rapidly embracing AI become slower because of it?

The answer turned out to be far more complicated.

Developers felt faster—even when they weren’t

Perhaps the most fascinating result wasn’t the slowdown itself.

It was how developers perceived it.

Before participating in the study, engineers estimated that AI would make them approximately 24% faster.

After completing the experiment, despite objective measurements showing the opposite, participants still believed they had worked around 20% faster.

The gap between perception and reality reached nearly 39 percentage points.

That finding reveals something important about human psychology.

Writing code often feels like the slowest part of software development.

When AI removes much of that effort, developers naturally experience a stronger sense of momentum.

The work feels easier.

Progress feels faster.

But software development is much more than writing code.

Every generated function still needs to be reviewed.

Every implementation must be verified.

Edge cases still require testing.

Architecture still demands human judgment.

Time saved during generation is often spent during validation.

The keyboard becomes faster.

The engineering process does not necessarily do the same.

A year later, the story changes

If the first METR study were the only available evidence, the conclusion would seem obvious:

AI slows developers down.

But technology evolves quickly.

So do AI models.

In February 2026, METR published a follow-up study using significantly more advanced AI agents.

This time, the experiment involved 57 developers, 143 repositories, and more than 800 real engineering tasks.

The results looked completely different.

Developers from the original study appeared to gain roughly 18% productivity, while newer participants showed a more modest improvement of approximately 4%.

However, the confidence intervals crossed zero.

From a statistical perspective, that matters.

It means the researchers could no longer say with certainty whether AI consistently speeds developers up or slows them down.

The evidence simply wasn’t strong enough to support either claim.

That uncertainty is far more honest than many headlines suggest.

Then something unexpected happened

The most remarkable finding wasn’t hidden in the productivity numbers.

It emerged from the participants themselves.

Between 30% and 50% of developers admitted they intentionally avoided sending certain tasks into randomization because they didn’t want to risk completing them without AI.

Others declined participation altogether.

One participant failed to complete a single task assigned to the “no AI” condition.

For researchers, this is a nightmare scenario.

Every randomized controlled experiment depends on one critical assumption:

Participants must be willing to enter either group.

Once that assumption breaks, the experiment itself begins to collapse.

And that is exactly what happened.

The control group—the very thing required to measure AI objectively—became increasingly difficult to maintain.

One quote explains everything

Among all the graphs and statistical analyses, one sentence from a participant captures the entire situation better than any chart.

“Working without AI feels like walking across the city after you’ve gotten used to taking Uber.”

That quote is remarkably revealing.

It does not prove that AI makes developers dramatically faster.

It proves something arguably more important.

Developers have changed their workflow so fundamentally that many no longer want to work without AI—even in the context of a scientific experiment.

The technology has shifted from being an optional productivity tool to becoming part of the default engineering environment.

The adoption paradox

This leads to one of the most interesting paradoxes in AI research.

The technology has become so deeply integrated into software development that it is beginning to interfere with the methods used to measure its own impact.

Researchers struggle to create a valid control group because experienced developers increasingly refuse to work without AI.

Paradoxically, that may be the strongest evidence of widespread adoption available today.

Not because it proves AI is extraordinarily productive.

But because it demonstrates that developers increasingly consider it indispensable.

That also explains why any claim about an exact productivity gain should be treated cautiously.

The better AI becomes—and the more universally it is adopted—the harder it becomes to measure what software development looks like without it.

The benchmark itself is disappearing.

Key takeaway: The most important AI study published so far does not prove that AI dramatically speeds up software development—or that it slows it down. Instead, it reveals something even more significant: AI has become so deeply embedded in modern engineering workflows that researchers are beginning to lose the ability to measure software development without it. That may be the strongest evidence of real-world adoption yet.

The hidden cost of AI-generated code — who reviews the reviewer? Verification becomes the new bottleneck

8. Where the Bottleneck Has Moved

When you step back and look at all of the evidence together, a remarkably consistent pattern begins to emerge.

AI hasn’t eliminated software development bottlenecks.

It has simply moved them somewhere else.

For decades, writing code was the most time-consuming part of building software. Developers spent most of their day implementing features, translating ideas into code, and solving problems line by line.

Today, that part of the process is becoming dramatically cheaper.

Generating a function, an API endpoint, or even an entire feature can take minutes instead of hours.

But software development has never been just about writing code.

And that’s exactly where the data becomes interesting.

The time saved during code generation is increasingly being spent somewhere else.

According to the 2025 DORA Report, developers frequently reallocate the time they save writing code toward activities such as reviewing, validating, testing, and auditing AI-generated output.

In other words, engineers are not necessarily working fewer hours.

They are simply spending less time typing and more time deciding whether what AI produced is actually correct.

Faros AI reaches exactly the same conclusion from a completely different dataset.

Its engineering telemetry shows that:

  • the median time spent reviewing Pull Requests increased by 441%;
  • 31% more Pull Requests are merged without any review at all;
  • the average Pull Request size increased by 51.3%.

Those numbers reveal a fundamental shift in software engineering.

If developers suddenly produce twice as much code, someone still has to read it.

Someone still has to verify it.

Someone still has to approve it.

Unlike code generation, human attention does not scale linearly.

A senior engineer cannot review three times as much code simply because AI generated it three times faster.

Review remains a fundamentally human activity.

The same pattern appears in the Stack Overflow Developer Survey.

Developers are not complaining that AI is too slow.

Their biggest frustration is something much more subtle: AI-generated code that is “almost correct.”

That phrase perfectly captures the new bottleneck.

Code that is obviously wrong is easy to reject.

Code that is almost right is much more dangerous.

It compiles.

It often passes basic tests.

It looks convincing.

But it still requires careful inspection because the remaining mistakes are usually the ones that take the longest to discover.

And unlike syntax errors, those mistakes cannot be spotted automatically every time.

They require engineering judgment.

That is why three completely different research methodologies all converge on exactly the same conclusion.

The bottleneck is no longer writing code.

The bottleneck is verifying code.

This distinction is critical because verification does not scale the same way generation does.

Computing power can generate millions of additional lines of code.

Human expertise cannot be multiplied at the same pace.

That imbalance is becoming one of the defining challenges of modern software engineering.

The DORA Report summarizes this idea particularly well by describing AI as an amplifier, not a replacement for engineering discipline.

Organizations with mature engineering practices—strong automated testing, rigorous code review, continuous integration, and fast feedback loops—benefit enormously from AI.

The technology amplifies processes that already work.

Organizations with weak engineering practices experience the opposite effect.

AI simply allows them to generate poor software faster.

The report summarizes the idea in a single sentence:

“Speed without stability is simply accelerated chaos.”

The easier it becomes to generate code, the more important architecture, testing, review, documentation, and technical leadership become.

The bottleneck has not disappeared.

It has simply moved upstream—from writing software to validating it.

Key takeaway: AI has dramatically reduced the cost of generating code, but it has not reduced the cost of understanding, reviewing, testing, or maintaining it. Modern software engineering is increasingly constrained not by code production, but by human attention and engineering judgment.

9. What Do We Do With All This?

By now, two extreme conclusions might seem tempting.

The first is to believe that AI will solve every major challenge in software development.

The second is to dismiss AI as an overhyped technology that simply produces mediocre code faster.

Neither conclusion is supported by the data.

The reality is far more nuanced—and far more useful.

Across every study discussed in this article, one pattern appears again and again.

AI is an extraordinary productivity tool.

But its value depends almost entirely on the engineering environment in which it is used.

The technology itself is neither the solution nor the problem.

It is an amplifier.

The question is: what exactly is it amplifying?

The available research suggests several practical lessons.

1. Measure structure, not output

For decades, software teams measured productivity using metrics such as lines of code written, completed tasks, closed tickets, or merged pull requests.

Those metrics are becoming increasingly meaningless.

If AI can generate hundreds or even thousands of additional lines of code with a single prompt, code volume is no longer a useful proxy for engineering value.

Instead, organizations should focus on metrics that reflect software health rather than software quantity: code duplication, architectural cohesion, function connectivity, refactoring activity, and long-term maintenance.

These indicators reveal whether a codebase is becoming healthier—or simply becoming larger.

2. Budget for refactoring

One of the clearest signals in GitClear’s research is the dramatic decline in maintenance work.

Old code is receiving significantly less attention than it did only a few years ago.

That does not happen because engineering teams consciously decide to stop refactoring.

It happens because generating new functionality has become so inexpensive that improving existing systems is constantly postponed.

If organizations want maintainable software, refactoring can no longer be treated as optional work that happens “when there is time.”

It has to be planned, scheduled, measured, and protected just like any other engineering investment.

3. Treat AI-generated code like third-party code

One of the biggest mistakes organizations can make is assuming that AI-generated code deserves a different review standard.

It doesn’t.

Every AI-generated change should pass through the same engineering pipeline as code written by an external contributor: code review, automated testing, static analysis, security scanning, and architectural validation.

Not because AI is unreliable.

But because every study discussed in this article reaches the same conclusion: confidence should never replace verification.

When nearly half of generated solutions can contain security issues under certain conditions, blind trust simply isn’t a responsible engineering strategy.

4. Don’t trust perception—measure reality

Perhaps the most surprising finding in the METR research was not the productivity numbers themselves.

It was how inaccurate developers were when estimating their own performance.

Experienced engineers genuinely believed they had become substantially faster—even when objective measurements showed the opposite.

Engineering decisions should be based on telemetry, not intuition.

Every organization adopting AI should continuously measure delivery speed, software quality, stability, incident rates, and maintenance costs.

Otherwise, it becomes almost impossible to distinguish real productivity gains from the feeling of being more productive.

5. Don’t confuse correlation with causation

This lesson appears repeatedly throughout nearly every dataset.

High-performing engineering teams tend to adopt AI earlier.

High-performing developers also tend to use AI more effectively.

That does not necessarily mean AI created their performance.

More often, it means strong engineering cultures are simply better at adopting useful technology.

Good processes still matter.

Good architecture still matters.

Experienced developers still matter.

AI does not replace those fundamentals. It makes them even more valuable.

6. Building software is no longer the competitive advantage

Perhaps the most important conclusion in this entire article has nothing to do with code.

It has to do with economics.

If the industry is approaching one million new applications per year while downloads grow by only around two percent, then software production is no longer the scarce resource.

Attention is.

Nearly anyone can build software faster than ever before.

The difficult part is no longer shipping an application.

The difficult part is building something users actually discover, trust, recommend, and continue using.

AI has dramatically lowered the cost of creating software.

It has done almost nothing to lower the cost of earning customer attention.

That is where competitive advantage is moving. Not toward code generation—toward product thinking, user experience, distribution, trust, and execution.

The new role of software engineers — from writing code to conducting: the right decisions matter more than speed

Conclusion

Every dataset examined in this article points toward the same conclusion.

AI is transforming software development—but not in the way many people expected.

It is not replacing software engineers.

It is not eliminating engineering complexity.

And it is certainly not making architecture, security, or product decisions less important.

Instead, it is changing the economics of software development.

Writing code is becoming dramatically cheaper.

Understanding problems is not.

Designing robust architectures is not.

Reviewing code is not.

Securing applications is not.

Building products that people actually want is not.

As the cost of generating code approaches zero, the value of everything that happens before and after code generation increases.

The companies that succeed over the next decade will not be the ones that generate the most code.

They will be the ones that consistently make the best engineering and product decisions.

AI is an extraordinary force multiplier.

But a force multiplier only amplifies what already exists.

Strong engineering becomes stronger.

Weak engineering becomes faster.

And that is exactly what the data shows.

The biggest lesson is surprisingly simple.

AI has solved the cheapest part of software development.

Everything else remains as valuable as ever.

What this shift looks like at company level — and why infrastructure matters more than the model — is covered in AI Isn’t Software. It’s Business Infrastructure.

Sources