AI Made Coding Faster. Why Are Products Still Slow?The Real Meaning of Development Speed

1. Conclusion: Development Speed Is Not Writing Speed; It Is Time to Delivered Value

AI has unquestionably changed how quickly software can be written. Research, first-pass design, implementation, test generation, and bug investigation that once took half a day can sometimes move forward in minutes. In my own work, some bug fixes feel tens of percent faster. Once the defect and the desired state are clear, AI can compress the cycle of investigation, hypothesis, and repair.

New features and products often feel different. Implementation finishes, then waits for review, a QA environment, cross-functional confirmation, or a release decision. When several teams must finish before anything can ship, making the fastest contributor ten times faster may barely move the date on which a customer can use the result.

That calls for a more useful definition of productivity:

In AI-era product development, productivity is not the volume of code produced. It is how much we reduce the time between recognizing a need and putting a safe, meaningful change in a customer's hands—then receiving evidence from reality.

This lead time is broader than the interval from ticket creation to deployment. It includes discovery, prioritization, design, implementation, review, QA, security, approval, release, use, and outcome measurement. DORA's change lead time begins at commit and ends in production; management also needs an outer measure from idea to validated value.^[1]

The proposal is not to abandon long-term strategy. It is to hold a two-year direction while decomposing it into bets that reach the market every three months. Construction, pharmaceuticals, vehicles, and critical infrastructure can have unavoidable physical, regulatory, and safety timelines. Updateable software should not inherit the same clock without a reason. When AI is accelerating the environment itself, a single large software launch eighteen months away becomes a bet that today's understanding will still be correct at completion.

2. Commits Can Rise 180% While the Release Effect Fades to 30%

A May 2026 NBER working paper captured this distinction directly. It combined AI telemetry with data from more than 100,000 GitHub developers and traced the effect of successive AI tool generations across a production hierarchy. With autonomous coding agents, the cumulative effect was 180% for commits, but 50% for projects and only 30% for actual releases. The authors describe a weak-link mechanism: AI and human effort remain strong complements, so gains attenuate as work moves through the production chain.^[2]

This was a matched event study, not a randomized trial, so its estimates should not be treated as a universal causal effect. Yet the pattern—AI gains fading higher in the production hierarchy—closely resembles what teams experience in practice.

Other studies show why measurement location matters. In a controlled experiment that asked developers to build a simple HTTP server, GitHub Copilot cut completion time by 55.8%. Across three field experiments involving 4,867 developers at Microsoft, Accenture, and a Fortune 100 company, access to an AI assistant increased completed tasks by 26.08%, with larger gains among less experienced developers.^[3][4]

By contrast, METR's randomized study of early-2025 tools followed 16 experienced contributors through 246 real tasks in mature open-source repositories. AI access increased completion time by 19%. Participants had predicted a 24% speedup and, even afterward, believed they had been 20% faster. In 2026, METR reported that newer agents probably delivered more benefit, but it could not reliably estimate the size because developers unwilling to work without AI selectively left the follow-up study.^[5][6]

These findings are not simply contradictory. A greenfield, self-contained task; everyday enterprise development; and work in a large, familiar legacy codebase differ in available context, testable correctness, and review burden. Asking for one universal percentage by which “AI speeds development” hides the system that determines the answer.

3. Japan's Data Reveals a Fault Line Between Internal Speed and External Value

It is tempting to reduce the comparison to “the world is fast and Japan is slow.” No authoritative public dataset standardizes average product-release lead time across countries. DORA itself warns against comparing unlike applications and user contexts. A fictional country ranking is less useful than several comparable cross-sections.

IPA's DX Trends 2025 found that 39.3% of Japanese companies had introduced or trialed generative AI, versus 58.5% in the United States. More tellingly, 12.2% of Japanese companies had integrated it into departmental business processes, compared with 42.4% of U.S. companies. Japanese use leaned toward individual writing and ideation, while process integration was more common in the United States.^[7]

One year later, DX Trends 2026 found that 58.0% of Japanese companies had introduced or trialed AI, including generative AI. Full generative-AI adoption rose from 22.6% to 44.0% in a year. Adoption is moving quickly. Yet only 31.8% of adopters reported results meeting or exceeding expectations; 50.6% saw some benefit, but less than expected.^[8]

The direction of those benefits matters most. Among companies reporting benefits, 91.6% cited more efficient or faster operations, 48.9% cited faster or better proposals, and 29.2% cited reduced overtime. Only 4.5% reported higher customer satisfaction and 3.9% reported increased sales or profit. The tool spread faster than the operating system that turns its output into external value.^[8]

The Japan Productivity Center reported that real labor productivity per hour and per worker each rose only 0.2% in fiscal 2024. This is not an AI scorecard. Industry mix, the economy, prices, capital, and labor constraints all affect the macro measure, so it cannot prove that AI failed. It does reinforce the need to explain why vivid individual time savings do not automatically appear as organizational or national value.^[9][10]

There is no single “Japanese weakness.” IPA found that 72.9% of companies with DX results reported effective coordination among management, IT, and business functions, versus 37.1% among companies without results. Organization-wide process optimization was underway or complete in 53.8% of the results group and 29.5% of the no-results group. Cross-functional flow, not tool adoption alone, separates outcomes.^[8]

4. AI Does Not Merely Close Skill Gaps; It Can Move and Widen Them

AI can lift less experienced developers. The larger effects for junior developers in the 4,867-person field experiments matter. They do not imply that everyone can now develop at the same speed.

Real work still depends on setting useful boundaries for an agent, understanding a system's tacit context, detecting plausible mistakes, decomposing a change into testable pieces, and designing a safe rollback. Differences in implementation speed may narrow while differences in supervision, integration, and judgment become the new bottleneck.

DORA's 2025 study drew on nearly 5,000 technology professionals and more than 100 hours of qualitative data. Ninety percent used AI at work and more than 80% believed it improved productivity, yet 30% had little or no trust in AI-generated code. AI adoption was positively associated with delivery throughput and product performance, while it still had a negative relationship with delivery stability. The report's central conclusion is that AI is an amplifier of an organization's existing strengths and weaknesses, not a repair kit for weak systems.^[11]

Give the same reviewers twice the change volume, with the same time, staffing, and rules, and the queue grows. Large pull requests are deferred, context switching rises, and the surface that appears to require inspection expands. As AI increases code volume, humans also become less certain about what they must inspect to fulfill their responsibility.

Adding an AI reviewer is not enough. If final accountability and scope remain ambiguous, more automated comments simply become another queue. Teams need smaller changes, machine-enforced checks for what machines can decide, and explicit human responsibility for meaning, exceptions, and irreversible consequences.

5. Do Not Slow Down for Safety; Build a System That Is Safely Fast

“Ship faster” can sound like a request for reckless launches. But the assumption that speed and stability are opposites is mistaken. DORA reports that strong teams achieve both and that the two dimensions are correlated for most teams. Small changes are easier to reason about, test, and reverse.^[1][12]

Continuous delivery replaces a large final inspection with testing, security, and observability embedded in small daily changes. DORA argues that continuous testing, pervasive security, and strong observability become more—not less—important in regulated and safety-critical environments. NIST's SSDF similarly includes integrating dynamic vulnerability tests and regression tests for known vulnerabilities into automated suites.^[13][14]

A practical risk model has three levels:

Applying the highest-risk process to every change creates delay rather than safety. Using classification to remove necessary checks creates incidents. Every rule should therefore identify the risk it controls, its scope, what machines can verify, its owner, and a review or expiry date. Once an automated control replaces a manual approval, the old approval should not survive merely because it once had a purpose.

If only the individual removing a rule carries the blame, nobody will remove one. Leadership must own the risk tiers and guardrails as an organizational decision—not leave one brave employee responsible for reducing ceremony.

6. We Are Not “After AI”; We Are Inside an Ongoing Shift

It is comforting to draw one line between before and after AI. Yet the move from chat-oriented systems around 2023 to agents that read repositories, execute tools, and coordinate multi-step work occurred within a few years. Comparing METR's 2025 and 2026 updates shows that tools changed quickly enough to undermine the stability of the experimental design itself.

This is better understood as moving ground than as a completed paradigm shift. A Socratic posture here is not merely admitting ignorance. It is knowing the boundary of what can be known, then designing the organization to learn faster.

A two-year product direction still matters. Budgets, talent, regulation, data, and platforms take time. The danger is freezing a two-year feature list under today's assumptions and waiting until completion for customer evidence. The useful question is not whether leaders feel confident about success in two years. It is how much evidence will arrive in the next ninety days to update that confidence.

An earlier article, “Will AI Agents Kill SaaS? GUI, API, Aggregation and the Road to 2030,” proposed a two-track strategy: build durable APIs, permissions, and audit foundations for an agent-oriented future while still shipping embedded AI that customers can use today. Even if GUIs shrink in the long run, a working interface has business value when today's customer wants one.

This is not a celebration of disposable engineering. Hypotheses and surface experiences may be disposable; customer data, authorization, auditability, billing, and security are not. Cultivate the hard-to-change foundation for years while testing the fast-changing value proposition in short cycles. Do not treat the permanent root system and the seasonal pot as the same asset.

7. Recut an Eighteen-Month Program into Ninety-Day Market Learning

Software plans can operate on three horizons:

• Two-year direction: Which customer problem should the company own, and which data, permissions, and brand promises are non-negotiable?
• Six-month capability: Which APIs, data quality, tests, observability, sales, and support capabilities must exist?
• Ninety-day bet: What is the smallest value for which audience, when will it ship, and what evidence will determine continue, change, or stop?

Ninety days must not become ninety days of development. Use the first two weeks to narrow the customer and success condition, the next two to four weeks to release the smallest change, and the remaining time to observe use and improve it. Even in integration-heavy or regulated domains, teams can often learn earlier through internal use, a restricted tenant, read-only access, or an AI that proposes actions without executing them.

Product, engineering, QA, security, sales, and support cannot each own separate deadlines. They must jointly define the smallest unit of value and own it until production. As DORA notes, siloing metrics by function creates friction and finger-pointing.^[1]

“Allow failure” also needs precision. Allow a controlled, small hypothesis to be wrong. Do not relabel a security incident, legal violation, or unrecoverable data loss as experimentation. Fast companies are not fast only because they are brave. They have technology that reduces blast radius and leadership that rewards an informed stop.

8. Measure Residence Time from Idea to Value, Not AI Usage

AI seats, prompt counts, generated lines, and time saved on slides can describe adoption. If they become the primary productivity measures, using the tool becomes the goal.

For one product, classify the last twenty to thirty changes by time spent in these states:

1. Need recognized to priority decided
2. Waiting to start
3. Implementation
4. Waiting for and undergoing review
5. QA, security, and approval
6. Waiting for release
7. Customer use to outcome decision

Use the median and 85th percentile, not only the mean, because a few giant items can distort the system. Also track work in progress, pull-request size, review wait, test duration, deployment frequency, change failure rate, rework rate, and recovery time. Finally, select one intended customer outcome—adoption, retention, fewer support contacts, revenue, or processing time.

If implementation shrinks after AI adoption while review wait expands, the next investment is not another coding model. It is review priority, change decomposition, automated testing, and clear accountability. If QA wait dominates, do not merely demand faster testers. Inspect test data, environments, regression suites, and release decisions for automation opportunities.

It is also useful if AI produces large gains in bug fixing and smaller gains in new features. Bugs offer a clearer desired state, agreed urgency, and less competition for priority. New features include unresolved questions about what to build, for whom, and whether it will sell. Averaging them into one productivity measure hides the place where work actually waits.

Closing: Speed Is Not Rushing; It Is Meeting Reality Earlier

Faster code generation is an important advance. It does not make a product fast by itself. Productivity appears only when a change can be reviewed, tested, released safely, and used to decide what comes next.

Japan's latest data does not say AI is ineffective. Efficiency and speed benefits are widespread. They attenuate before reaching customer satisfaction and revenue. The next investment is therefore not only more AI licenses. It is smaller changes, fast review, automated quality, progressive delivery, observability, explicit exit conditions, and leadership willing to remove approvals that no longer control a real risk.

There is no need to ban large launches eighteen months or two years away. A plan that waits until launch day to test whether it is right, however, is fragile. If the future cannot be predicted precisely, make learning stronger rather than planning weaker.

The AI-era contest is not about who writes code fastest. It is about who can receive an answer from reality earliest—safely.

References

1. [1]DORA, “Software delivery performance metrics”. Definitions for change lead time, deployment frequency, recovery time, change failure rate, and rework rate. Updated January 2026. ↩
2. [2]NBER Working Paper 35275, “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools”. May 2026 working paper covering more than 100,000 GitHub developers. ↩
3. [3]Microsoft Research, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”. Randomized HTTP-server task experiment. ↩
4. [4]Microsoft Research, “The Effects of Generative AI on High-Skilled Work”. Three field experiments with 4,867 developers. ↩
5. [5]METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”. A randomized trial with explicit scope and limitations. ↩
6. [6]METR, “We are Changing our Developer Productivity Experiment Design”. Discussion of selection bias and measurement limits in the follow-up study. ↩
7. [7]IPA, DX Trends 2025 webinar materials. Japan-U.S.-Germany comparisons of generative-AI adoption and use. ↩
8. [8]IPA, DX Trends 2026. Survey of DX, AI adoption, outcomes, organization, and talent in Japanese companies. ↩
9. [9]Japan Productivity Center, Trends in Japanese Labor Productivity 2025. Real labor productivity per hour and worker in fiscal 2024. ↩
10. [10]PRESIDENT Online, “The Reality of AI Use: Work Feels Faster, but Hours and Productivity Do Not Improve”. A reference for the gap between individual time savings and organizational or macro productivity. ↩
11. [11]Google Cloud, “2025 DORA Report: State of AI-Assisted Software Development”. Nearly 5,000 technology professionals and more than 100 hours of qualitative data. ↩
12. [12]DORA, “Working in small batches”. Practices for making AI-accelerated changes easier to review, test, and recover. ↩
13. [13]DORA, “Continuous delivery”. Technical capabilities behind fast, safe, and sustainable releases. ↩
14. [14]NIST SP 800-218, Secure Software Development Framework Version 1.1. Recommendations for integrating secure development practices throughout the lifecycle. ↩