Somewhere in your company right now, an AI agent is writing code. Probably several, possibly a great many. One is running inside an IDE on a senior engineer's laptop. Another is chewing through a ticket somebody assigned it this morning. A third lives in a tool you've never heard of because a team lead expensed it back in March. Output is up and the velocity chart looks terrific.
Now try and find the person who designed the system that produces all this software. Not the person who bought the tools; the person who decided how work enters the production line, what happens at each station, where the checkpoints are, and what must be true before something rolls off the end and reaches a customer. Almost every leader I pose this question to struggles to find clear and intentional design in their software production line.
If your team builds software with agents, you are already operating a production system. Inputs arrive as tickets, prompts, and half-written specs. Machinery transforms them into product at a pace we'd have called absurd 3 years ago. The output ships to production and users use it. The gaping open question is whether anyone designed that system on purpose, or whether it assembled itself one developer preference and tool adoption at a time. And, as any competent plant manager will tell you, an undesigned line produces nothing more efficiently than defects.
How the Line Assembled Itself
People made choices that led to this state but they didn't make decisions, which is exactly why nobody owns it. Every step along the way may have been a rational choice. Code generation and autocomplete made engineers faster, so they came in. Agents made them faster still, so those came in too. Somebody wired an agent directly to the backlog because the experiment cost almost nothing and took an afternoon. Each choice, possibly sane on its own. None of them individually created a system, but all of them together did.
Meanwhile the process around the work never got a second look. Your review habits were sized for the pace of human typing, and they're now standing in front of a firehose. The definition of ready, the definition of done, the branching rules, the approval rituals; all were calibrated for a world where writing the code was the slow (and therefore expensive and risky) part. That world is ending while everyone's busy trying to carry on.
There's an organizational reason this goes unexamined but it isn't negligence. Delivery processes are "plumbing." It doesn't feel customer-facing, no revenue line points at it, and the people who experience its pain points sit three levels below the people who could redesign it. So the production line keeps assembling itself bit by bit, sprint after sprint.
The Lights-Out Temptation
The industry's loudest answer to this mess is to brutally finish the job. Remove the people entirely. Specs go in one end, working software comes out the other, and no human writes or reviews a line in between. Manufacturing has a name for this, the lights-out factory; machines running in the dark because nobody's there to need the lights.
And for some software work, honestly, it can deliver real results. Bounded, well-specified, high-volume, low-novelty work tolerates automation beautifully. Good candidates are projects like a framework migration, version bumps across 40 repositories, or that fourth internal admin tool that looks just like the other three. Teams are proving this in production right now, and pretending otherwise would make everything else in this essay easy to dismiss.
But stand in the dark for a minute and look around. Just about every lights-out success has a senior human standing just outside the frame. Someone decided this work was constrained and defined enough to automate, wrote the spec that made it bounded, and built the checks that catch failure before a customer does. The machines run in the dark precisely because a person with judgment drew up some seriously thoughtful plans.
Novel, complex application work, the systems your business actually differentiates on, should rarely sit inside a dark factory like that. Requirements will shift mid-build and the edge cases discovered through actual development are where the business risk (and reward) lives. "Correct" shifts with the market. For this work, removing the people removes the judgment along with the labor, and only one of those was the cost you meant to cut.
All Green, Half Rejected
Your engineers can already feel the problem with the output. The immaculately documented pull request that looks great and smells terrible. The test suite that passes while a senior person squints and says "give me an hour with this."
Earlier this year METR, the research group whose mission seems to be generating uncomfortable measurements in AI, tested that instinct. They took 296 pull requests written by AI agents, every one of which had already passed the automated checks used to grade agent performance, and put them in front of active maintainers of scikit-learn, Sphinx, and pytest; these are the people who answer for those codebases. The maintainers turned away roughly half of those PRs.
Sit with that ratio for a moment. Every light on the dashboard was green, and half the work still wasn't shippable in the judgment of the humans accountable for it. Google's 2025 DORA research found a similar pattern at industry scale: AI adoption near 90 percent, throughput climbing, and instability rising right beside it. The old shop rule was measure twice, cut once, but agents cut instantly and measure only when and what you've told them to measure.
We've made the longer argument elsewhere, but the short version transfers well: a definition of done that the agent itself can satisfy, edit, or grade is really just a suggestion. The bar has to live with the humans who set it.
What the Air Force Figured Out
If verification becomes the bottleneck, one tempting conclusion is that checks are the enemy of speed. The best counterexample I know comes from the least likely place: the Pentagon (a sentence I would have bet against 10 years ago).
In 2017 the Air Force stood up a delivery organization called Kessel Run to ship software the way modern product teams do, inside an institution where a single authorization to operate (ATO) could swallow most of a year and happened exactly once. The breakthrough came in 2018, when Kessel Run won approval to make that authorization continuous. Instead of one enormous gate at the end, checks ran constantly, against every change, all the time. Software that used to wait months for ATO started landing in production in days. Judgment moved into the flow of work as waiting consumed less of the process.
More checking, more often, and far less waiting, is the whole trick. We've run a version of it ourselves; our delivery work with the Department of Defense's MEPCOM agency over the past 7 years took inspiration from Kessel Run's playbook, and it permanently changed how that agency thinks about pace. Speed and rigor stopped being opposites for us a long time ago and in the agent-driven world they become sides of the same coin.
What a Designed Production Line Looks Like
A designed system divides the work 3 ways; how you execute this split is the design.
The process holds the structure. What's being built and in what order, what done means for each piece, where the checkpoints sit, and what state everything is in right now. Boring, load-bearing, and written down where everyone (human and agent alike) can see it.
The agents do the reasoning. The drafting, the code, the first pass at nearly everything. This is where the speed lives, and a well-designed system lets agents run hard precisely because the structure around them makes running hard safe.
And the humans hold the delicate decisions that never get delegated. Approving the plan before work starts. Owning the acceptance bar, the definition of done no agent can edit. And making the final call that something ships. Three intentionally slow moments that allow everything else to move at machine speed; these move at the speed of judgment, and that's the point.
Done well, none of this feels like a stodgy compliance office. It feels closer to working with a great executive assistant, someone who knows where everything stands, files the work, keeps you pointed at what's next, and nudges you toward the practices you'd choose on your best day, while every real decision stays in human hands. Structure as support and never as a cage.
There's also a governance angle your board or leadership will eventually ask about. In a designed system, every piece of work you ship traces back to a named person who approved the plan, owned the bar, and made the call. "The agent did it" has never once satisfied a customer, a regulator, or a board. It's why we center every build on one accountable senior engineer-architect, the role we call the Conductor, rather than a delivery pyramid with judgment smeared thinly across it.
So walk your own floor this week. Take the last significant thing your company shipped with AI-agents and ask 3 questions. Who approved the plan before the work began. Who owns the definition of done, and could an agent have changed it. Who decided it was ready to ship. If the honest answer to all 3 is "the agent, effectively," then your production system is running with the lights already dimming and nobody standing at the end of the line checking the work.
You don't have to slow anything down. You have to decide, on purpose, where the people stand. Design the production line before it designs itself.