There is a simple promise underneath most of the AI coding conversation: If developers can produce code faster, software should reach production faster. That promise sounds reasonable right up until the new code reaches the rest of the delivery system.

The latest evidence says generation is speeding up while the feedback loop is struggling to keep pace. Faros AI telemetry covering roughly 22,000 developers found that pull requests grew 154% larger in 2025 and another 51.3% in 2026. Developers were also handling 67.4% more pull-request contexts per day. More code is arriving, in larger packages, across more simultaneous threads of work. The number of human beings expected to understand it has not increased at anything like the same rate.

That is not a reason to dismiss AI coding tools. It is a reason to look at the whole system instead of celebrating one faster step inside it.

The Feedback Loop Has a Math Problem

DevOps has always favored small batches and fast feedback. AI can support that model, but it does not enforce it. Give a developer ten times more generation capacity without a change in delivery discipline, and the result may be a much larger pull request rather than ten small, easily reviewed changes.

The adoption numbers expose the imbalance. Futurum research cited in Techstrong’s new special report, The Great Unification, puts AI use in code generation at 40.2% and code review at 37.7%. Yet AI use in CI/CD operations is only 13.2%, and its use in deployment decisions falls to 6.2%. Only 9.5% of organizations release daily, even though 58.3% place their DevOps maturity at the standardizing or mastering stage.

In other words, the fastest part of the system is getting faster while the later stages remain largely unchanged. DevOps people know what happens next. Work queues up in front of the constraint.

There are two ways to read the low automation rate at deployment. The generous reading is that organizations are wisely retaining human control at the highest-consequence boundary. The less comfortable reading is that our delivery machinery cannot absorb the output now being created upstream. Both can be true at once.

The Pipeline Has to Learn What “Good” Means

Traditional CI/CD is built around deterministic artifacts and mostly deterministic checks. A test either passes or it does not. AI-dependent software complicates that assumption because the same input can produce different outputs, and a model can change behavior without a corresponding change in application code.

That pushes evaluation into the pipeline. Prompts, models and agents need versioning. Evaluation suites need thresholds, comparison baselines and release criteria. A model change may need a canary process, but the failure signal could be a statistical drop in answer quality rather than a spike in HTTP 500 errors. Rollback can also be slower and more expensive because model artifacts are large, warm-up takes time and regressions are often behavioral.

The practice is still behind the need. A LangChain survey of more than 1,300 practitioners found observability implemented by nearly 89% of respondents, while evaluation adoption trailed at 52%. Many of those evaluations run offline rather than as a gate that can stop a release. A lot of teams can tell that an agent behaved badly in production. Far fewer can demonstrate before merge that a prompt or model change did not make it worse.

This is not an exotic machine-learning concern. It is a delivery concern, which makes it DevOps territory.

The Pipeline Becomes the Product

As platform engineering takes responsibility for inference endpoints, approved model catalogs, agent runtimes and GPU quota, the DevOps role can move away from building every piece of delivery infrastructure. The focus shifts to the delivery process itself: What evidence must a change carry? Which risks require a human decision? What can be reversed safely? How quickly does production behavior return to the team that made the change?

That pipeline will need evaluation gates, guardrail checks, data-egress controls, provenance for AI-generated code and model-specific promotion rules. It will also need restraint. An LLM reviewing LLM-generated code can find defects, but it can also produce confident approval with the same blind spots as the system that wrote the code. AI-assisted review is not the same thing as scaled judgment.

The organizations that benefit most will not be the ones with the highest code-generation number. They will be the ones that keep batch sizes small, make verification a first-class capability and preserve human attention for the decisions where it has the greatest value.

This is one part of a larger change. AI is now both a workload running on the stack and a worker operating inside it. That dual role is pulling DevOps, platform engineering, software development, QA and security into a shared operating model. The Great Unification lays out that model, the research behind it and the signals that would prove the thesis wrong.

Download the Full Report