Agent-Driven Delivery Is Fast, Until Your Environment Slows It Down

This is the gap most enterprises are hitting right now, and it’s why the two sides keep talking past each other. Writing code was never the hard part of enterprise delivery. The weeks go into framing the work, getting sign-off, wiring it into everything else, proving it holds up in production, and releasing it without breaking anything. Agents make one part of that faster. The friction in the rest stays exactly where it was.

So the real question isn’t which AI coding tool you pick, it’s whether your delivery system can absorb what an AI coding agent throws at it or whether it quietly paces that output back down to human speed. Most enterprise estates pace it down, and they do it from two directions at once: the way the organization works, and the way the technology is built.

Take the velocity seriously, because it’s genuine. Give a capable agent a clearly specified task, in a codebase it can understand, with a sandbox where it is safe to execute, and it will produce a working change faster than any developer. There’s no context-switching defecit, no time wasted waiting for standup, and not one afternoon lost to a merge conflict. This part is not hype.

But assuming that speed survives the trip to production is a trap. It only survives if every stage downstream can keep pace. There are plenty of ways to draw the software delivery life cycle and none of them is the one true map; the version we find useful runs from frame and spec, through plan, implement, test, integrate, verify and release, out to observe. But it’s not about the labels (use whatever labels you like, frankly). The point still holds.

A coding agent is transformative at only a few of those stages—plan through implement and test—and does very little for the others on its own. Make those stages faster and you still haven’t shortened the pipeline. You’ve just moved the bottleneck somewhere else.

Factory’s Autonomy Maturity Model puts a number on it: “A 10x improvement on that one step yields only roughly a 10% improvement overall,” because “the return compounds only when autonomy moves the entire lifecycle.”

The first kind of friction is human, the kind technology leaders tend to wave off while an agent that ships in minutes waits days for a decision.

Start with the ticket: three bullet points and a title. A human engineer fills the gaps without noticing: they know which service owns this, or who to ask about the edge cases, or what “make it like the last one” was supposed to mean. An agent has none of that, so it either guesses or it stalls.

From there the waiting compounds.

Stakeholder sign-off takes time, and so does a brand or UX call that lives in one person’s judgment and nowhere else. With no catalogue of what already exists, the agent rebuilds a feature you shipped last year. With conventions the team never wrote down, it guesses again. Then it reaches the review queue, where a human still approves every change and the gates were built for a slower world.

A sharper coding tool won’t touch any of this. What helps is making intent and standards explicit, and rethinking approvals that assume code is expensive to produce. Once code is cheap, the scarce resource becomes judgment and coordination— the thing most organizations haven’t rebalanced around yet.

The other kind of drag is the environment the agent works in, and that shows up in two places: what the agent can see, and what happens to the code once it’s written.

What it can see is usually too little. Undocumented architecture leaves it unable to reason about how systems connect, so it changes one thing and breaks another two services away. And with no safe sandbox to run its code, every experiment is either risky or slow, because there’s nowhere to try things without consequences.

Then there’s the path to production. Manual CI/CD drops a human back into the exact step you were trying to automate. Regression coverage too thin to trust means every automated change still needs a manual pass, which spends the time you just saved. And when something does break—and it will—weak observability means nobody sees it in time to react.

None of that is mysterious, and each part has a known fix. Together they decide whether your environment is safe enough for an agent to move fast without leaving a mess behind.

Two things run in parallel: the technical estate and the operating model. Agents expose whichever one is weaker. A team with immaculate automation but no decision discipline stalls in the review queue. A team with fast approvals but a fragile, undocumented environment stalls in integration. You don’t get to pick one. It’s both, or the speed leaks away regardless.

Treat operations and infrastructure as a single problem, then sequence the work.

Start with intent and conventions, because it’s cheap and it unblocks everything after it: specs an agent can act on, a catalogue of what already exists, and the standards your team carries in its head written down somewhere a machine can find them. Fix the approval bottleneck next, so review and change gates scale with the volume agents produce instead of choking on it. The engineering comes after that, roughly in order: a safe sandbox, pipelines with no manual step on the critical path, regression tests you’d stake a release on, and observability that shows you what production is doing in time to act.

If you want a structured way to score this, Factory’s maturity model rates each repository across eight technical pillars, testing, build systems, sandboxed environments, observability, security and governance, documentation, and more, and rolls them up into a single board-legible metric: the share of your repositories that are “agent-ready.” It’s a useful lens whether or not you adopt their tooling, because it turns “get ready for AI” into a concrete, measurable backlog.

A fast agent isn’t the achievement. A system that can keep up with one is. To pull ahead, teams have to do the unglamorous work around the tooling, far beyond just shopping for a sharper agent. Pick the stage that’s costing you most right now and start there. And measure lead time from idea to production, not lines of code an hour.