Trusting Agent-Driven Delivery in Production

The honest answer is that both halves of that worry are right, because they describe different parts of the same shift. One part is how fast an agent can produce working code. The other is how much it costs to trust what it produced, and how much damage it can do on the way there. Those are separate problems, and the second is where almost all the pushback on agent-driven delivery actually lives.

(By agent-driven delivery we mean handing whole units of work to AI agents that plan, write, test, and open changes, with people directing and reviewing rather than typing every line.)

It’s important to draw that distinction, because it changes what you do next. If the problem were raw capability, the answer would be to wait for a better model. It isn't, though, so that’s not the solution. Confidence and safety don't arrive with the next release. They are produced by the system the agent works inside: how it’s grounded, what it can touch, who checks its work, and what gets recorded when it acts.

Between us we spend our days building these systems, on Orium's own delivery and inside our clients' engineering teams, and the lesson has been consistent. The answer isn't a better agent. It's the delivery process itself. When you make the lifecycle the work moves through explicit, and pull the friction out of each stage, the promise and the pushback stop fighting each other.

Start with the part that's true. Something has changed in how software gets built, and the people closest to it are not hedging. Andrej Karpathy, an OpenAI co-founder who recently joined Anthropic's pre-training team, wrote on X that LLM coding agents had crossed "some kind of threshold of coherence" around December 2025, and called 2026 a high-energy year as the industry metabolizes the new capability. Y Combinator president Garry Tan reported shipping 37,000 lines of AI-generated code a day across five projects. Tan's number later drew scrutiny when a developer audited the public output and found a lot of waste, which is its own lesson: raw volume and trustworthy software are not the same thing.

The shape of the work is moving. The developer goes from writing each line to directing a system that writes it, then judging what comes back. Treated as faster autocomplete, that is a modest gain. Treated as a new operating model, it is a large one. We've felt that shift in our own teams, where the leverage is real once the work is set up for it.

The gains in raw output don't survive the trip to production intact, and the evidence is specific.

On quality, CodeRabbit's State of AI vs Human Code Generation report found that across 470 pull requests, AI-co-authored changes carried about 10.83 issues per PR against 6.45 for human-only changes, roughly 1.7 times the defects. GitClear, drawing on 211 million lines of changed code, found code churn (the share revised or discarded within two weeks of being written) climbing as AI authorship spread, alongside a sharp rise in duplicated code. Its CEO, Bill Harding, describes "a lot of code that gets written and then immediately needs to be fixed."

That quality gap is what drains the velocity. Output rises, but a chunk of it loops back through review and rework, so net throughput lands below the headline number.

Cost has two faces. The first is that rework, paid in the most expensive hours you have. The second is the cost of inference itself. An agent that plans, retries, and runs in multi-agent loops consumes far more tokens than a single prompt, and a high-autonomy setup left unwatched can run up real money fast. Without usage visibility and spending controls, the bill becomes unpredictable in a way finance notices.

Then there is the surface most teams never mapped. An agent working in your pipeline can hold credentials, call tools, modify the host it runs on, and send your code to a model provider that may retain it. Each of those is a safety and security question that a slide-deck demo never raises, and that a regulated enterprise cannot wave through.

None of this is mainly a model problem. It is a friction problem, and the friction has a shape. Map the work an agent does, from framing a request through observing it in production, and you can see where the time and the trust go.

The spine across the middle is the lifecycle every change moves through (though the terminology is still settling): Frame, Spec, Plan, Implement, Test, Integrate, Verify, Release, Observe. Pressing down on it from above is operational drag, the people-and-process friction: ambiguous requests, weak stakeholder alignment, brand and UX judgment that is hard to codify, no catalog of existing features, undocumented conventions, limited review capacity, and change-management gates. Pushing up from below is infrastructure and technology drag: undocumented architecture, poor codebase hygiene, slow manual builds, no sandbox for the agent to run code in, manual pipelines, thin regression coverage, and little production observability.

An agent hits every one of these, faster than a person would. Point it at an undocumented codebase and it guesses, the same way a new hire would, only at machine speed and volume. Swap in a more capable model and none of it moves. The undocumented architecture is still undocumented, the review queue is still the bottleneck, the agent still has more access than its task needs. The promise leaks away in the drag, and the drag is not in the model.

Lay the objections over that diagram and they stop looking like separate complaints. They are the same friction surfacing at different stages.

Quality and velocity leak in the middle of the spine, at Implement, Test, and Verify, and at the review gate sitting above them. An agent writes quickly, but with thin regression coverage and a review queue already at capacity, defects either slip through or pile up waiting, and the speed you gained turns back into rework.

Cost leaks in two places at once. There is the rework above, paid in senior hours. And there is the infrastructure drag below: manual builds and pipelines, and no sandbox for the agent to run its own code, so a person ends up babysitting every step. Token spend leaks wherever an agent runs at high autonomy with no usage visibility to rein it in.

Safety and security leak where the spine meets your real systems, at Integrate and Release, when there is no sandbox to contain what the agent does and no gate to check what it is about to do. That surface is large enough that we've written about it on its own, but on the diagram it reads as one more form of drag: friction the work hits on its way to production.

Here is what the faster teams we work with actually do. They don't wait for a better model. They make the lifecycle explicit, name the drag on each stage, and take it out one piece at a time. They write down the conventions an agent keeps guessing at. They stand up a sandbox so the agent can build and test its own work without a human in the loop for every run. They put automated checks into the pipeline so review is no longer the only gate. And they weave verification and observability through every stage instead of bolting them on at the end, so a problem shows up at Test rather than in production.

None of that is glamorous, and none of it is a model upgrade. It is the unglamorous work of clearing friction, and it is what turns raw output into output you can ship. The teams that do it get two things at once: the speed compounds, and so does the resilience, because the same clarity that lets an agent move fast is what lets you catch and recover when it gets something wrong.

You don't need a bigger model or a reorganization to begin. Take one team and one workflow, and walk it down the spine from Frame to Observe. At each stage, name the drag: the ambiguous request, the undocumented convention, the missing sandbox, the review queue that has become the constraint. Then pull out the worst one, and do it again next month.

Do that a few times and the gap between the promise and your reality starts to close. The agent didn't get better; the path it runs got clearer. That's the work we do with engineering teams ready to cross from borrowed speed to delivery they own.