Once a team has capable, harnessed agents, the slowest part of shipping software stops being the code. An agent can carry a large share of the build. What it cannot do is decide, correctly, what to build — and that is where the work, and the risk, now live.
I have been rolling this out with real teams for the past several months. The pattern that works is consistent, and this is how an AI-native team organizes the work around the build.
The bottleneck moved upstream
Waterfall, Scrum, and Kanban were all built for a world where humans performed most of the work by hand. They assume the bottleneck is engineering capacity, so they organize people, shorten feedback loops, and manage the queue. That was the right design when people were the thing doing the building.
When agents can do much of the building, the limiting factor changes. It is no longer how fast people can type. It becomes the clarity of the business context, the quality of the specification, the correctness of the design, the architectural fit, the strength of the constraints, and the quality of the validation. Every one of those is upstream of the first line of code.
This is why an AI-native process is not less disciplined than what came before. It is more disciplined. Turned loose without discipline, agents add entropy: more output, faster, in more directions, with less shared understanding, which is just confusion at higher speed. Discipline is what converts raw speed into sustainable delivery.
Software delivery is an enrichment pipeline
Think of delivery as an enrichment pipeline, the way a raw material becomes a finished product. Software starts as a half-formed idea, and each step adds value. Business context clarifies the idea. Domain understanding grounds it. User journeys turn it into behavior. A specification turns that into something buildable and testable. Design turns it into an experience. Architecture turns it into a technical plan. That plan becomes something an agent can build.
Pipelines have bottlenecks, and improving an upstream step makes every downstream step easier. That one property is the whole strategy.
Shift left, harder than you're used to
Traditional teams tend to iterate late. They discover ambiguity during implementation, argue about requirements during review, and find architecture problems after the code already exists. Each of those is an upstream problem surfacing downstream, where it is most expensive to fix.
The AI-native move is to push in the other direction, harder than most teams are comfortable with. Spend more effort up front — on context, spec, design, and architecture — so those questions are settled before the build begins.
This is not about slowing down; the point is to make the build phase almost boring. When an agent runs the build, the expensive mistake is no longer writing code slowly. The expensive mistake is letting unclear thinking reach the build phase, because the agent will build the wrong thing faithfully, at high speed, and with full confidence.
The pipeline in practice
The process we use for this is called ETC — Enter the Chat. It is both a framework, meaning the process and the opinions baked into it, and the custom tooling I built to run that process. I will keep this at the level of how the work flows.
It starts with initialization. Before any features, the harness helps the team write down what the project actually is: a domain description, a project description, and — for an existing system — a real discovery pass over the current architecture, conventions, and behavior. The important part is what it does with that. It does not inspect the codebase and quietly guess. It brings its findings back to you for ratification. If your DTOs live in five different places, it does not pick one on your behalf; it asks which convention is authoritative and then writes that down. Once ratified, the context is organized, documented, and locked, so every agent works from the same operating model.
From there the work moves through the pipeline, one enriched artifact at a time: a journey phase to define who is using the system and what they are trying to do, a specification phase that runs spec-driven development to converge on a clear, testable spec, lo-fi design to explore flow and structure, hi-fi design to make the experience concrete, and an architecture phase where engineering takes the lead on feasibility, integration boundaries, data shape, and implementation strategy.
The feature bundle is a directory the process allocates at the very start of the work, and it gets enriched as the work moves through it. Each phase writes its findings into the bundle — the domain context, the journeys, the spec, the design, the architecture. By the time architecture is done, the bundle holds enough context, product intent, design direction, and architectural guidance that the build can proceed with very little ambiguity left in it.
Then the build runs. If the upstream work was done well, no one needs to watch every keystroke. One person acts as the Build Manager. They supervise the run, review progress, and handle escalations. One of ETC's principles is to fail fast and loud: when the system hits a problem, or a decision it should not make on its own, it stops and surfaces the moment to a human rather than pressing on. Those stops are the escalations. When a client follows this pattern with the tooling, their builds run ten to twenty hours with little intervention. What comes out is more than code — it is the implementation, plus release notes, phase metrics, timing data, and a record of how the work moved through the pipeline.
What about build quality
The obvious objection is: how do you know the generated build is any good? Quality does not come from trusting the agent. It comes from enforcement — deterministic checks, spec enforcement, architecture constraints, tests, review gates, and release validation. I have written about that enforcement side at length elsewhere, and building it in is much of why ETC exists in the first place.
The point for engineers
When you build with agents, your work shifts from writing prompts to building the system that supervises the agent. The prompt still matters, but most of the reliability comes from the structure around it: what the agent can see, what it is allowed to do, and how you detect when it is wrong.
You do not build all of it at once. Start with a narrow task, watch where the agent goes wrong, and add a rail each time it does. Over time those rails become your harness. The capability comes from the model. The trust comes from the structure you put around it.
There is a leadership side to this shift too — what it does to delivery metrics, team dynamics, and how a business plans work — that I have written up separately for that audience.
Jason Vertrees is the founder of Heavy Chain Engineering (heavychain.org), which helps lower middle-market vertical SaaS companies and PE firms turn scattered AI usage into measurable delivery leverage — 85% faster feature velocity, six-to-eight-week projects shipped in days. If you want help building an AI-native engineering organization, book an AI Delivery Assessment (app.onecal.io/b/jason-vertrees/30-mins) or email jason.vertrees@gmail.com.