AI made your engineers faster. Why isn't your software better?

Four independent studies agree on what AI changed in software delivery, and on what it didn’t. Here is what closes the gap.

What does the 2025–2026 research actually say about AI and software delivery?

The 2025–2026 research on AI in software delivery tells a split story: velocity is up and trust is down. Four sources; DORA (Google Cloud’s research program), METR (an independent nonprofit), DX and Faros AI (engineering-intelligence platforms) converge on the same finding. AI did not fail. Most delivery systems were simply never redesigned to absorb it.

The headline numbers are real. According to DX’s Q2 2026 report covering more than 500 organizations, the share of code generated by AI rose from 34% to 52% in a single quarter, and AI users save an estimated four to six hours a week. DORA’s 2025 study of roughly 5,000 technology professionals found that 90% use AI at work, and more than 80% report higher productivity. AI adoption now correlates with higher delivery throughput.

The same reports show the other side. Developer trust in AI code, change confidence, delivery stability, and innovation capacity are flat or falling. The task for engineering leaders is not to question whether AI works. It is to close the gap between faster and better.

Metric	DX Q2 2026	Faros AI 2026	Signal
AI-generated code share	34% → 52% in one quarter	n/a	Velocity is real
Code maintainability	+3.8%	Tasks up 34%, epics up 66%	Output up
Change confidence	−6.1%	Bugs per dev up 54%	Trust is down
PR size	Nearly doubled	PRs up ~51%	Review load explodes
PR review time	n/a	Grew ~5x; 31% merged with no review	Bottleneck confirmed
Innovation ratio (new features vs maintenance)	Flat	n/a	Time absorbed, not reinvested

You might also be interested in:

→ The Ceiba Method: AI-Augmented Software Delivery Where Engineers Stay Accountable

→ Past the Pilot: Delivering Generative AI That Holds Up in Production

Why does faster code generation produce lower confidence in what ships?

Faster code generation produces lower confidence because non-deterministic models generate plausible code, not necessarily correct code for a specific architecture. The code arriving for review is often not review-ready, which means human engineers spend their attention on catching errors the model introduced rather than on the architectural and business judgment that only humans can provide.

The data makes this concrete. DX found that median pull request size nearly doubled as AI adoption rose. Code maintainability improved 3.8% developers understand what the code does but change confidence dropped 6.1%, meaning they trust less what they ship. The Developer Experience Index slipped from 67 to 65 over four quarters.

Faros AI’s 2026 engineering report, drawn from telemetry across 22,000 developers and more than 4,000 teams, adds a harder number: bugs per developer rose 54%, and the incident-to-PR ratio more than tripled under high AI adoption. DORA 2025 found that about 30% of respondents report little or no trust in AI-generated code, and that AI adoption still correlates with higher delivery instability.

Ceiba’s answer to this problem is spec-driven development. An architect agent documents the system whether greenfield or reconstructed from an existing codebase and a product agent writes stories with acceptance criteria and architectural impact analysis before a developer agent writes a line. The result is that agents build what the team intended, not something plausible. Specifications live as Markdown in the client’s own repository, giving both engineers and agents the documented context that DORA describes as AI-accessible internal data.

What happens to engineering teams when AI generates more code than reviewers can handle?

When AI generates more code than reviewers can handle, three things happen: PR review time grows, PRs get larger, and some teams quietly stop reviewing. Faros AI’s 2026 report found that median PR review time grew roughly fivefold, PRs became approximately 51% larger, and 31% more PRs were merged with no review at all. The bottleneck did not move to production it was removed.

This is not a new problem. Faros AI’s 2025 report found review time up 91% while company-level delivery metrics stayed flat. The 2026 numbers show the same dynamic accelerating. More output per engineer does not compound into better outcomes when the constraint is human attention at review.

DORA 2025 identifies working in small batches as one of seven capabilities that amplify AI’s positive effects. Ceiba addresses review volume through two mechanisms. An automated review stage checks every story against OWASP Top 10 for LLM Applications criteria, development best practices, and the acceptance criteria a named engineer signed before implementation began. A failed check sends the story back for rework before a senior reviewer spends a minute on it. The product agent keeps stories small and estimated, which counters PR bloat directly.

The principle behind both mechanisms is the same: human review capacity is the constraint worth protecting. It should be spent on judgment calls architecture, risk, business context not on catching errors that automated gates can catch for free.

You might also be interested in:

→ Who Do You Delegate To? Agent Delegation, Authority, and the Engineer Who Signs Off

→ Strategies to Mitigate Codebase Cognitive Debt

Does AI actually make engineers faster and where does the time go?

AI does save engineers time, but self-reported speedups overestimate the gain and the saved hours are not automatically reinvested in higher-value work. METR’s randomized controlled trial with 16 experienced developers found they took 19% longer with AI tools while believing afterward they had been roughly 20% faster. METR’s 2026 follow-up suggests newer tools likely do produce speed gains, but selection effects in the study design make the size hard to pin down. DX confirms that saved hours are real and that the innovation ratio, time spent on new features versus maintenance, has stayed flat. The time is being absorbed, not reinvested.

DORA’s ROI report for 2026 introduces the J-curve: AI delivery returns show an initial dip before gains appear, and positive ROI is not guaranteed without adapting the system around the tools. Teams that deploy AI without changing how they measure, review, and govern work are likely sitting in the dip without the infrastructure to climb out of it.

Ceiba validates its own method before scaling it to client work. The Ceiba Method was measured by phase on live projects before it reached its current scale. For organization-wide adoption, Ceiba’s Augmented Organization Model installs two instruments: Sextante ranks initiatives by value, risk, and maturity before budget is committed; Astrolabio checks whether the promised value arrived afterward. The goal of both instruments is to make the J-curve visible before it becomes a budget conversation.

The people angle matters here. The goal of AI-augmented delivery is not to reduce headcount. Agents absorb the repetitive load boilerplate, documentation reconstruction, scaffolding so engineers move into architecture, validation, and product decisions. That is the work that raises the innovation ratio, reduces attrition, and keeps the engineers organizations most want to retain.

You might also be interested in:

→ What to Delegate to an AI Agent, and What a Senior Engineer Should Never Sign Away

→ Agentic AI and Your Modernization Backlog: The Real Cost, and Why Expert Engineers Still Win

Why did enterprise AI spend grow 28x and how do you defend it to the CFO?

Enterprise AI spend grew 28x in a year, and most leaders cannot yet tie that number to throughput, quality, or innovation. DX data shows median quarterly organizational AI spend rising from roughly $1,500 to roughly $44,000 over four quarters, with tech-sector spend leading that curve. DORA warns against what it calls ‘tokenmaxxing’ rewarding raw token consumption as a proxy for adoption. AI cost is an engineering variable to manage, not a line item to accept.

The exposure compounds because many AI coding subscriptions are priced below their real compute cost, with venture capital covering the gap. Companies that wired their delivery economics to one provider’s introductory pricing are exposed when that gap closes.

Ceiba’s approach is model independence by design. The Ceiba Method’s agents have operated across GitHub Copilot, Claude, and open-source models without architectural changes. Ceiba moved from hundreds of Copilot licenses to a mix of Claude licenses and open-source models on its own H200 GPU infrastructure. Routing logic matches each workload to the cheapest model that clears its quality bar: sensitive intellectual property stays on local inference, high-volume low-complexity tasks run on open-source models, and frontier-model spend is reserved for the tasks that genuinely require complex multi-step reasoning.

You might also be interested in:

→ AI FinOps Starts With Engineers, Not Invoices

Five questions to ask any AI-augmented delivery partner before you scale

Question	What it tests
Where does code get checked before a human reviews it?	Review bottlenecks are automated gates catching errors before they reach senior engineers?
Who signs off on each deliverable, by name?	Trust gap accountability requires a person, not a pipeline.
How do you measure value beyond self-reported speed?	METR and J-curve perceived speed is not delivered speed.
Where do the hours saved by AI actually go?	Innovation ratio is freed time reinvested or absorbed into maintenance?
What happens to our costs if a model provider changes pricing?	AI FinOps model independence is a negotiating position, not a contingency.

Ceiba’s answer to each question is operational, not aspirational. Automated gates run before human review. Every deliverable carries a named senior engineer. Ceiba measured the method on live work before scaling it. Saved hours are redirected into architecture and validation through a defined autonomy spectrum exploratory work runs with light oversight, production systems with regulatory or revenue exposure get dense human validation at every stage. And the delivery economics are model-independent by design.

The nearshore dimension matters for the last point. A partner whose engineers work in US time zones and inside your standups and code reviews makes the oversight real. Calibrated human judgment is not a claim on a sales deck; it is the 10 a.m. pairing session where your engineer and a Ceiba engineer work through the same pull request.

Ceiba engineers will map your workloads onto the autonomy spectrum and outline a first engagement on your own codebase, under your credentials, in a working session.