Most teams using AI to build software still run the old assembly line, just faster: an epic, then designs, then stories, then code, then tests, each one handed to the next person. In a small experiment, one autonomous run matched that whole chain at a fifth of the cost. So when does the industry tip from many handoffs to one ask and one acceptance, and what happens to the people in the middle?
The software development lifecycle was designed around specialists. A product manager wrote down what customers needed, a designer drew it, an engineer built it, a tester checked it. Every artifact in between, the requirements, the mockups, the tickets, existed so one person could hand work to the next without losing meaning.
AI has sped up every one of those steps, but most teams kept the steps. Now a single agent can do all of them, and the handoffs start to look less like quality control and more like translation between people who are no longer in the loop.
My team just moved to a workflow where product managers use Claude for every step from research to front-end code, and engineers review and finish the rest. It works. I wanted to think one step ahead: How Many Steps Does a Feature Need? measured the present; this is the thought experiment about where it goes.
The ideaThe pipeline collapses from the middle out. The steps that translate between people disappear first. The steps that hold decisions, verification and accountability stay, and become the whole job.
Every artifact in a software pipeline answers the same question: how does the next person know what the last person meant? The epic carries the product manager’s intent to the designer. The mockup carries the design to the engineer. Acceptance criteria carry it to the tester.
When one agent carries the whole feature, nobody needs the translation. In my experiment the six-step pipeline spent most of its tokens on stories and tests written for the next step to read, and its review step changed nothing in 12 of 12 runs. The model was, in effect, writing memos to itself.
That doesn’t make the artifacts worthless. People still need to understand what was built and why, and regulators need evidence. But artifacts change role: from gates the work must pass through to views generated from the work when someone needs to read them.
This won’t happen in one jump. Here is how I expect a feature’s path to shorten, and what each stage needs before a team can safely take it.
My estimate of the stages, not a measurement. Dark boxes are human decisions; light boxes are AI work.
The technology for stage three exists for well-specified features today. What most teams lack is the written decisions and the tests to trust it.
Decisions written down. In my experiment, every model got every rule right when the rules were written, and every model missed the same ones when they weren’t: who can act across sites, which exceptions exist, what one feature does to another. A smarter model guesses more confidently. It can’t guess what your team agreed. So the source of truth, every decision your product has made, kept in a form a model can read and a tool can check, is the precondition for everything else.
Tests the builder can’t see. Every run that broke a rule still passed all of its own tests. A model checking its own work is a second opinion from the same mind. Acceptance has to come from tests written against the decisions, kept out of the builder’s reach.
Guardrails on what it may touch. An agent that can change schemas, permissions or audit trails needs limits that are enforced in code, not described in a prompt.
A person who is accountable. In regulated software this isn’t optional. Under 21 CFR Part 11 an electronic signature belongs to a person; someone has to own the release.
Deciding what to build. When anything can be built overnight, the expensive mistake is building the wrong thing. Does this feature make the customer’s whole job easier, or does it add one more screen to learn? That judgment needs knowledge of customers, of the market and of the product as a whole, and it gets more valuable as building gets cheaper.
New decisions. Every feature eventually hits a case the rules don’t cover. The agent should stop and ask, a person who knows the domain should decide, and the decision should be written down so the question never comes up again. A team’s speed becomes a function of how quickly it can make and record decisions.
Acceptance. Someone has to look at the result and say: this is what we meant, and it’s good. That review is the new center of the work, so it deserves better tools than reading a diff.
The middle does hollow out. The roles built mainly on translation and coordination shrink first: writing handoff documents, turning tickets into boilerplate code, running manual test scripts, chasing status. What grows sits at the two ends and underneath.
The strong version of the argument is that a software company becomes a small group of people who know exactly what should be built, plus a large bill for tokens. There’s real truth in it: the number of people needed to turn a decision into tested code is falling fast, and companies will produce far more software per person.
But four forces push the other way. Demand grows as software gets cheaper, so there will be far more software, and likely more companies, each smaller. Distribution and trust don’t get cheaper: if anyone can build anything, the advantage moves to whoever customers already know and believe. Accountability needs people, especially in healthcare, finance and other regulated work. And judgment has to come from somewhere: if the junior work in the middle disappears, companies will need a new way to grow the people who make decisions at the ends.
My best guess is that the core of a company becomes the people who understand customers, own decisions, verify the result and earn trust, with a machine in the middle that keeps getting more capable. Smaller teams, more of them, each closer to its customers.
When building is nearly free, a company’s value is in knowing what to build, proving it works, and being trusted to deliver it.
Collapse where the rules are strongest. Start one-ask builds in the areas where your decisions are already written down and your tests are good. Expand as the source of truth grows.
Track how often a feature ships from one ask, and how many new questions each one raises. Both numbers tell you how much the machine can carry.
Turn artifacts into views. Keep generating epics, flows and stories, but as readable summaries of what was decided and built, not as gates.
Move people up the stack, deliberately. Teach engineers to own verification and platforms, and product people to own decisions and journeys. Pair juniors with the agent and with experts so judgment keeps growing.
My experiment used small features with complete rules; real products are messier, and the hardest work is often figuring out what the rules should be. Progress may slow, costs may rise, or long-running agents may stay too unreliable for critical systems. Trust and regulation move slower than technology. And the social cost of hollowing out the middle, for people’s careers and for how expertise is learned, is real and deserves more thought than a timeline.