The Two Speeds: Why Faster Code Isn't Better Code

AI promises to produce software much faster.

It can generate a function, explain an error, correct a test, write documentation, propose a pull request, refactor a component, or create a first version of an application in just a few minutes. For product and tech teams, the promise is clear: reduce lead times, increase volume, and deliver more often.

But one question is becoming increasingly important: what happens when the speed of production exceeds the speed of validation?

Because software isn't just written code. It's code that's understood, tested, reviewed, integrated, deployed, monitored, maintained, and fixed. And that entire process doesn't automatically speed up just because a model can generate 200 lines in ten seconds.

AI is getting faster and faster, but quality still takes time.

Producing code has never been the real problem

In many teams, the bottleneck isn't the actual writing of the code. It's everything that surrounds it.

Understanding the requirement. Identifying the impacts. Choosing the right architecture. Checking edge cases. Writing tests. Reviewing a pull request. Deploying without breaking anything. Monitoring production. Fixing side effects. Maintaining the system six months later.

AI mainly speeds up the visible part: generation.

But if it produces more code than the team can review, test, or understand, it doesn't necessarily reduce risk. It just shifts it.

That's the current paradox: we're gaining speed in writing code, but not always in quality assurance.

And in real-world software, quality isn't measured by the number of lines produced. It is measured by the system's ability to function correctly, over the long term, in a changing environment.

IT projects were already failing quite well without AI

We must start with an uncomfortable truth: IT projects didn't need AI to go wrong.

Major studies on IT projects have for years shown very high rates of failure, delays, and budget overruns. A McKinsey-Oxford analysis of more than 5,400 large IT projects showed that, on average, they exceeded their budgets by 45%, took 7% longer, and delivered 56% less value than expected. For large software projects, the figures were even more severe: approximately 66% budget overruns and 33% delays.

Even more concerning: 17% of the large IT projects studied were performing so poorly that they could threaten the very existence of the company.

This is important because AI is entering an industry where the challenge has never been merely about coding. The historical problems lie elsewhere: vague objectives, technical debt, poor coordination, hidden dependencies, underestimation of complexity, weak governance, and insufficient validation.

In other words, AI is not entering a perfectly optimized factory.

Poor software quality is already very costly

Software quality also carries a massive macroeconomic cost.

The CISQ estimated that poor software quality cost the United States $2.41 trillion in 2022. This figure includes, in particular, operational failures, failed projects, security vulnerabilities, legacy systems that are difficult to maintain, and technical debt.

This cost is often invisible until it becomes acute. A logic error, a vulnerable dependency, poor access control, or a poorly tested patch can go unnoticed for months, then surface in production as an incident, a data breach, or a service outage.

AI can reduce certain costs. But it can also create new ones if it increases the volume of code without improving the quality of safeguards.

The statistics on AI-generated code call for caution

Recent data doesn't suggest that AI is useless. It reveals something more interesting: AI is useful, but not without cost.

Veracode analyzed code generated by more than 100 models across 80 programming tasks. The result: only 55% of the generated code was deemed secure. This means that nearly 45% introduced known vulnerabilities in the tested scenarios.

CodeRabbit compared pull requests created by humans with those generated by AI. Out of 470 pull requests, AI-generated changes contained an average of 10.83 issues per PR, compared to 6.45 for human-generated PRs. This represents about 1.7 times as many issues.

Apiiro observed another concerning trend: in the repositories studied, AI-generated code introduced more than 10,000 new security findings per month in June 2025, a tenfold increase in six months.

These figures do not prove that AI always writes bad code. They show that the speed of code generation can multiply defects if it is not accompanied by better controls.

The problem isn't that "AI makes mistakes." Humans do, too. The problem is that AI can make mistakes at high speed, with great confidence, in a format that looks like production-ready code.

Productivity gains aren't automatic

One might think that even with a few errors, AI remains cost-effective because it massively speeds up developers' work. Here, too, the reality is less straightforward.

A controlled study by METR, published in 2025, observed 16 experienced developers working on 246 tasks in open-source projects they were familiar with. The developers believed that AI would save them about 24% of their time. Afterward, they still estimated they had saved 20%.

But actual measurements showed the opposite: with AI tools, they took an average of 19% longer.

Why? Because the time saved on writing was offset by the time spent rereading, correcting, guiding the tool, waiting for it to generate suggestions, and cleaning up the suggestions.

This result doesn't mean that AI always slows everyone down. It can be very useful for simple tasks, prototypes, developers less familiar with a codebase, or repetitive work. But it highlights one essential point: in a complex software system, producing a plausible solution isn't enough. You have to verify that it's correct.

And verification remains expensive.

The frequency of updates is increasing

At the same time, modern software is being updated more and more often.

The best DevOps teams deploy on demand, sometimes several times a day. DORA has shown for years that the highest-performing teams combine speed and stability: they deploy frequently, recover quickly after incidents, and keep changes small.

Even major consumer software companies are accelerating their release cycles. Chrome, for example, has shifted over the years from longer cycles to shorter ones, and Google has announced a transition to a stable release every two weeks starting with Chrome 153. Microsoft, for its part, maintains a structured monthly schedule for Windows security updates, with updates released on the second Tuesday of each month, and out-of-cycle patches when critical issues arise.

There's sound logic behind this acceleration. Smaller, more frequent updates can reduce risk: fewer changes at a time, faster feedback, quicker fixes, and users protected sooner.

But this logic only works if the foundations are in place: automation, reliable testing, observability, feature flags, rollback, thorough review, and built-in security.

Without these foundations, more deployments simply mean more opportunities to break something.

Confusing speed with maturity

Speed isn't a problem in and of itself.

A mature team that deploys ten times a day with robust testing, small changes, good observability, and the ability to roll back quickly can be more reliable than a team that deploys once a quarter in a panic.

The problem arises when AI pushes a team to produce faster without improving its ability to validate.

More generated code means more pull requests. More pull requests mean more code reviews. More code reviews mean more cognitive load. More changes mean more interactions between components. More interactions mean more subtle bugs.

If teams don't change their practices, AI can turn slow technical debt into fast technical debt.

Before, we laboriously wrote bad code. Now, we can generate it en masse. The problem lies in throughput.

AI amplifies the existing organization

Recent DORA reports are particularly insightful on this point. In 2024, AI adoption was associated with an estimated decline in software throughput and, more importantly, a decline in stability. In 2025, the relationship with throughput became more positive: teams seem to be learning how to integrate AI into their workflows. But DORA continues to observe a negative relationship with stability.

This nuance is important.

AI isn't just an individual tool. It's an organizational amplifier.

In a team with good testing, rapid CI, robust reviews, security practices, and a clear architecture, it can accelerate useful tasks.

In a disorganized team with few tests, fragile deployments, and poorly understood technical debt, it can generate problems faster than the team is already able to handle.

AI doesn't replace the fundamentals. It makes them more visible.

What teams need to measure

If companies want to use AI seriously in software development, they must stop measuring only volume.

The number of lines generated is not a meaningful metric. Neither is the number of closed tickets, if those tickets resurface as bugs. The number of pull requests can even become an indicator of noise.

The right questions are more demanding:

• How many bugs make it into production after AI-assisted code?
• How long do code reviews take?
• What is the rollback rate?
• What is the change failure rate?
• How many vulnerabilities are introduced?
• How much of the generated code is deleted or rewritten in the following weeks?
• How much time is actually saved between the idea and a stable feature in production?

We need to measure the entire cycle: generation, review, testing, deployment, incidents, and maintenance.

Otherwise, we're only measuring the accelerator, never the brakes.

What this means for software quality

Software quality must evolve alongside AI.

First, testing must become more important, not less. The faster AI generates code, the more critical automated tests capable of quickly filtering out errors will become.

Second, code review must change. Reviewing AI-generated code requires special attention: business logic, security, edge cases, dependencies, duplication, and maintainability. The code may be well-formatted yet still incorrect.

Security must also be integrated earlier in the process. If vulnerabilities are detected only at the end of the pipeline, the AI will have already multiplied the number of changes that need to be corrected. Tools such as SAST, SCA, secret scanning, dependency analysis, and policy-as-code are becoming even more important.

Finally, teams must reduce the size of changes. AI makes it tempting to request large modifications all at once. This is often a mistake. Smaller changes remain easier to review, test, deploy, and roll back.

The right strategy isn't to slow down AI. It's to break down its work so that quality can keep up.

What about the future?

The future of software development won't simply be "more code, faster."

It will be a race between two speeds.

On one hand, the speed at which models, agents, co-pilots, frameworks, prompts, and automation are generated.

On the other hand, the speed of validation through testing, security, observability, architecture, and business understanding.

If generation accelerates on its own, companies will accumulate more technical debt, more bugs, and more risks. If validation also accelerates, AI can truly improve software delivery.

The problem, therefore, is not how fast AI can write code, but how fast we can review and correct it.