Why is AI making your software delivery slower?

AI is not slowing your delivery because the models are bad. It is slowing your delivery because it accelerates the local work of producing code, specs, and tickets, while the work that actually gates delivery, agreeing on what is true across people and tools, still runs at human speed or not at all. The effect is measurable. In a randomized controlled trial by METR (2025), experienced developers using AI took 19% longer to complete real tasks, while believing they had been about 20% faster. I watched this play out from the inside of one company's AI push.

How a three-day AI refactor caused a two-week production cleanup

Every step of an AI disaster feels like a win while it is happening. In early 2026, the CEO of a company I work with sent a message that will sound familiar: we need to accelerate software development with AI. By the end of January he had repeated it to every technical lead, and isolated initiatives started appearing within weeks. Each one was local, and each one looked reasonable on its own.

The first was a major Next.js upgrade. The frontend team pointed an AI coding agent at it and let it run for almost three days. The codebase had no unit tests. The build passed, manual tests in a controlled environment passed, and the team estimated the agent had saved them at least two weeks of work.

Then it reached production. The agent had quietly rewritten integrations along the way and invented endpoints that never existed. Features stopped working in silence. Stabilizing took two weeks, during which the planned work of other streams stopped too. A few features turned out to be broken for two or three months, discovered only when a single user finally touched them.

Inventing endpoints is not exotic bad luck. A USENIX Security 2025 study generated 576,000 code samples across 16 models and found that at least 5.2% of package references from commercial models, and 21.7% from open-source models, pointed at packages that do not exist. Confidently referencing things that are not there is documented, measured model behavior.

Old fundamentals, broken at machine speed

AI coding agents did not invent a new failure mode; they made a decades-old one, the big-bang rewrite of an untested codebase, cheap enough to attempt. Martin Fowler wrote the rulebook in Refactoring, first published in 1999: you refactor in small steps that always leave the code working, and you do it on top of self-testing code. A three-day rewrite without tests violates both rules at once. The agent simply made the violation cheap.

This is the industry pattern, not one team's mistake. GitClear analyzed 211 million changed lines of code written between 2020 and 2024 and found the share of changes that refactor or move existing code sank from 25% in 2021 to under 10% in 2024, while copy-pasted lines grew from 8.3% to 12.3% of all changes. AI as used today produces more code, not more reuse.

Then every role got its own AI, and the words stopped matching

When every role in a company gets its own AI, the contradictions come from the sum of the tools, not from any single one. After the refactor, the push continued: the designer began generating layouts and design specifications with AI, the PM wrote tasks in Asana with AI, product wrote specs into Notion with AI, developers wrote code with AI. Each initiative produced an impressive volume of artifacts. It also produced the simplest contradiction there is: the names used in the product definitions stopped matching the names used in the code.

Eric Evans named what was lost. Domain-Driven Design (2003) calls it the ubiquitous language: one rigorous vocabulary shared by the people who define the product and the code that implements it. That language was the team's informal consensus protocol, maintained for free while humans wrote everything by hand and read each other's work. AI production erased it in a single quarter.

The bugs this creates are silent. The task "works", but with slight differences from what was specified, so nothing fails loudly on day one. And since no human understood the whole anymore, each error surfaced only when someone built on top of an assumption and hit reality.

AI moved the bottleneck from writing code to agreeing it is safe to merge

The bottleneck of software delivery was never typing. It was agreement. Gene Amdahl formalized the general form in 1967: speed up one part of a system and the total gain is capped by the parts you did not speed up. AI sped up production. It did not speed up review, QA, integration, or reconciliation, the serial part of delivery. And it is worse than a cap, because faster production feeds more work into the part that did not scale.

Faros AI's telemetry across more than 10,000 developers and 1,255 teams shows exactly this shape: teams with high AI adoption merged 98% more pull requests while review time rose 91%. Across the same dataset, AI adoption was associated with pull requests 154% larger and 9% more bugs per developer. At the company level, Faros found no significant improvement in any metric, DORA included. The bottleneck moved from writing code to deciding whether code is safe to merge.

None of this should surprise anyone who has read DORA's research: working in small batches is one of the strongest predictors of delivery performance, and the emphasis is on small changes with fast feedback, not on the volume of code produced. The company accelerated the one thing DORA never pointed to as the constraint.

Your AI stack is a distributed system with no consensus protocol

A company running AI inside every tool is a distributed system, and almost nobody ships it with a consensus protocol. Distributed computing has a name for what I watched: split-brain. Partition a cluster and, if both halves keep accepting writes, each builds its own version of the truth. The design tool, the task tracker, the spec, and the codebase were all accepting writes faster than any human could read them. Nothing reconciled them.

Melvin Conway saw the underlying law in 1968. As he states it: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." Give every silo its own AI and you do not fix the fragmentation, you automate it.

There is one difference from the classic scenario, and it makes things worse. A partitioned cluster once had consensus and lost it. Your company's AI stack never had it. It was born split-brain.

The failure nobody measures: locally right, globally wrong

The dangerous failure is the answer that is right locally and wrong globally: invented answers get audited, incoherent ones slip through. Everyone measures hallucination, and the industry has benchmarks for it. But the deeper failure at that company was different: each tool did its job correctly on the slice it could see, and the sum of correct answers was an incoherent system.

No standard evaluation catches this. Benchmarks like MMLU and HELM test one model on one task. There is no eval that asks whether your five AI touchpoints agree with each other about the same feature. Practitioners already feel the gap: in Stack Overflow's 2025 survey of over 49,000 developers, 84% use or plan to use AI tools, yet more developers now distrust their accuracy (46%) than trust it (33%). The number one frustration, cited by 66%, is code that is "almost right, but not quite", and 45% say debugging AI-generated code takes more time. Almost right is exactly what locally correct, globally inconsistent looks like from the inside.

What fixes AI-slowed delivery: reconciliation at machine speed

If production runs at machine speed, reconciliation has to run at machine speed, or the acceleration is self-defeating. The fix is not less AI, a smarter model, or better prompts. The missing piece is the function humans performed silently when everything was slow: reconciling what the design, the spec, the tickets, and the code each believe into one current truth. That function now has to be infrastructure: a context layer that every tool reads before acting and writes back through. The ubiquitous language and the consensus protocol, rebuilt as a system instead of a habit.

This fix has been measured, with one caveat worth stating first. In a 2026 preprint, Dillon and Varanasi benchmarked a coding agent against 41 team decisions in a single repository and moved compliance from 46% to 95%. The caveat: they build the context tool they tested, and the gain came from a bundle of recorded decisions, a generated spec, and consultation during the build, so no single ingredient earns the credit. What survives the caveat is one case in their per-decision table. The repository held two audit functions, and a SOC-2 rule made exactly one of them mandatory for exports. The rule itself was written down nowhere the agent could reach. Told to make sure the action was logged, the agent went looking, found an audit function, and used the wrong one, a distinction the authors say requires knowing why the right one exists. It could read both functions. It could not read the agreement about which one the team had settled on. Retrieval alone does not close that gap, because retrieval finds similar text, it does not govern truth.

What to demand from a context layer

Before you buy the next AI tool, ask your team one question: where do all our AIs read what is true? A context layer earns that role only if it does four things. It reconciles the many names of one real thing into one entity. It tracks provenance, so every fact traces back to a source. It withholds or flags contested facts instead of blending them into one confident answer. And it sits underneath the tools you already run, so agents read it first, over a standard interface like MCP.

Most products in this category run as cloud subscriptions on someone else's infrastructure. LoomSignal is our answer for the delivery lifecycle specifically: a local context layer your AI tools share, running on your own servers, bought once. It refines raw signals through bronze, silver, and gold tiers, so an agent only acts on context that passed a governance gate.

The companies that will actually get the acceleration are not the ones with the smartest model. They are the ones whose tools agree on what is true.