Caveat lector: this post is a reflection on what I've predicted and am currently seeing in my work. As we all learn more during this AI transition, these thoughts might mature and change.
About a year and a half ago I made a bet: once software teams had genuinely capable AI agents, the way they organize their work would have to change — not the tooling alone, but the shape of the team and the order of the work. That future is here now. For the past several months I have been building my answer to it and rolling it out with real teams, in the room with them. This is what I am seeing, and so far it is tracking the prediction closely.
AI is usually sold as a way to make individual developers faster. It does that. The larger effect is on how a team should organize its work.
For most of software's history, our delivery methods were built around one assumption: humans do the work, so the constraint is human throughput. Waterfall, Scrum, Kanban — different shapes, same underlying premise. Organize the people, move the tickets, manage the queue, because people are the thing doing the building.
Once a team has capable, harnessed agents, that premise stops holding, and the way you organize work has to change with it. This is not an argument for less process; it is an argument for more discipline. Turned loose without it, agents add entropy: they produce more output, faster, in more directions, and with less shared understanding, which is just confusion at higher speed. Discipline is what converts that raw speed into sustainable delivery. The goal is not to remove process but to redesign it around a different constraint.
The old models were built for a different bottleneck
It's worth being fair to the methods we're moving past, because each solved a real problem.
Waterfall front-loads planning and then executes in sequence. Its weakness is that feedback arrives late, often after it has become expensive to act on.
Scrum and the broader Agile movement were a correction to that. They shortened the feedback loop and organized human teams around iterative delivery, which was a genuine improvement. The problem is what many teams have turned it into: sprint planning, grooming, standups, retros, tickets, and ceremonies that consume a lot of coordination and don't always produce much leverage. The ritual outlived the point.
Kanban visualizes flow and limits work in progress, which is useful. But it manages the queue; it does not improve the quality of what enters the queue.
All three were built for a world where humans performed most of the work by hand, and they assume the bottleneck is engineering capacity. AI-native engineering moves the bottleneck. When agents can carry much of the build, the limiting factor 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, the quality of the validation, and your ability to keep the agents on the rails.
That is the shift everything else comes down to.
Software delivery is an enrichment pipeline
Think of software delivery as an enrichment pipeline, the way a raw material becomes a finished product.
Software starts as raw material: a half-formed idea. Then it gets enriched, step by step. Business context clarifies the idea. Domain understanding grounds it. User journeys turn it into behavior. A specification turns that into something buildable and testable. Lo-fi and then hi-fi design turn it into an experience. Architecture turns it into a technical plan. That plan becomes a buildable unit of work, and that becomes working software, along with the release notes, metrics, and artifacts that come with it.
Each step adds value. A bad idea becomes a clearer idea, a clearer idea becomes a spec, a spec becomes a design, a design becomes an architecture, and an architecture becomes something an agent can build.
The reason this framing matters is that 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.
ETC: turning this into a repeatable process
We built both the process and the tooling to run it, and named the whole thing ETC — Enter the Chat, which we pronounce "Etsy." ETC is two things at once. It is a framework: the process itself, the opinions baked into it, and the sequence of steps an AI-native product lifecycle should follow. And it is the custom tooling I built to run that process — an agent harness with the deterministic hooks, checks, and gates that keep the work on the rails. I'll keep this at the level of how it changes the work rather than how it is built.
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 defines who is using the system, what they are trying to do, where the value shows up, and where it can fail. A specification phase runs spec-driven development to converge on what should be built — not a ticket, but a clear, testable spec that reflects the company's real needs. Then lo-fi design to explore flow and structure, hi-fi design to make the intended experience concrete, and an architecture phase where engineering takes the lead on feasibility, integration boundaries, data shape, and implementation strategy, with product and design still in the room.
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 the architecture phase is done, the bundle holds enough business 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. That is real. There is more going on under the hood than I will get into here, but the shape is simple: the team scatters, and the Build Manager babysits the build. What comes out is more than code — it is the implementation, plus release notes, phase metrics, timing data, and a clear record of how the work moved through the pipeline.
The new team shape: gather, enrich, scatter
The clearest way to describe the change in team shape is three words: gather, enrich, scatter.
Gather. The team comes together in a focused working session, usually over video — product, design, engineering, and the business stakeholders in one place. They define the problem, sharpen the spec, pressure-test assumptions, and agree on what is being built. This usually takes one to three days of part-time effort; a team that is fully focused and used to the process can get through it in about a day.
Enrich. The idea moves through the pipeline and each phase improves the artifact. Domain context enriches the idea, journeys enrich the understanding of the user, the spec enriches the product definition, design enriches the experience, and architecture enriches the implementation path. The feature bundle gets more valuable at every step.
Scatter. Once the bundle is ready, the team scatters. Most of the team goes back to other useful work. The Build Manager stays with the agentic build.
That is the operating-model change in one line: people do not disappear, they concentrate their judgment where it matters most and then stop creating drag once the machine can execute.
All of this rolls up to the same result: higher sustained productivity, output quality that holds, and a team that works better together. When people deliver more, deliver it more easily, and have more fun doing it, the conviviality of the team goes up along with the throughput.
Why executives get better visibility
The promise to a leader here is not "our developers use AI." It is that the delivery system becomes more measurable, more repeatable, and easier to improve.
Traditional delivery gives leaders blurry signal: story points, sprint velocity, ticket counts, subjective status, "almost done," "blocked," "needs QA." The pipeline model gives you something firmer. You can see how long specification took, how long design took, how long architecture took, and how long the build took, and where the bottleneck moved this time.
That turns into a real improvement loop. If design took twelve hours this time and fifteen last time, you may be getting better at it. If the architecture phase keeps expanding, the codebase may have hidden complexity worth addressing. If the build keeps getting stuck, the spec is probably weak or the architecture is not well documented. These are operating data you can coach against, not impressions from a status meeting.
There is a compounding effect here that I have written about before. The faster you spin the delivery cycle, the more the friction shows itself: problems that used to hide across a long, slow quarter become obvious when the loop runs in days. Visible friction is easier to learn from and easier to fix. And because the process frees up real human time, you can spend it paying down what actually slows you — technical debt, process debt, and the friction itself.
Why teams get better together
When I watch a team work through the domain, the spec, the design, and the architecture together, they build shared understanding. They solve the hard problems before the pressure of implementation is on them. They see how each other think. That builds trust, and it produces more attempts that actually succeed.
Success changes how a team behaves. When the process feels easier and more reliable, people are more willing to use it again. The work feels less chaotic, collaboration starts producing visible results, and people lean into it instead of avoiding it. This is not a nice-to-have on the side: teams that feel good about how they work tend to do better work, and doing better work makes them feel better about the process. It compounds.
What about build quality?
By now a careful reader has the obvious objection ready: how do you know the generated build is any good? That is exactly the right question, and it is not what this article is about. This one is about how AI changes the organization of work — where teams spend their time, how artifacts get enriched, how the bottleneck moves, and how leaders get visibility.
The short version of the answer is that 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.
Enter the chat
The name ETC — Enter the Chat — comes from part of that same bet about where software work is heading: it will look more and more like people entering a shared conversational workspace, doing their part, and leaving. A product leader enters to clarify intent. A designer enters to shape the experience. An engineer enters to define the architecture. A build manager enters to supervise execution. Agents enter to do specialized work. People join when they are needed, contribute their judgment, and step out when their part is done.
You can already see the tooling market moving this way. AI is showing up inside the collaboration layer itself, not just inside the IDE. Before long, agents will not only respond to prompts — they will sit in on meetings, summarize decisions, hold context, answer questions, and eventually take part in the workflow as active participants. ETC was built for that world. It turns "chat" from an informal place people talk into a governed environment where the work actually gets delivered.
A fun side-quest: it just so happens my Grant Aunt's name was Etsy. So, she's the "spirit" of the logo for the ETC project.
What this looks like as an engagement
In practice, this is what we do with companies. We train the team on the process, install and configure the ETC harness, and I embed as a forward-deployed engineer inside the team. I sit with product, design, engineering, and leadership while they learn it, and then we build together.
The goal is not to hand over a tool and walk away. It is to install a new operating model: shared domain context, spec-driven development, disciplined design and architecture, governed agentic build execution, a measurable delivery pipeline, stronger collaboration, and faster, more reliable output. That is what software-delivery modernization for the AI era means at the level of how a team works day to day.
The point
AI-native delivery is not about replacing the team. It is about reorganizing the team around the parts of the work where people create the most leverage. Humans are best at judgment, context, taste, tradeoffs, business understanding, and shared meaning. Agents are increasingly good at execution, transformation, scaffolding, and producing the artifacts. The mistake is to force both into a workflow that was designed for neither. The opportunity is to design one that fits.
ETC is our answer to that: gather the right people, enrich the idea into a buildable feature bundle, and let governed agents execute while a human supervises. This is the shape I bet on a year and a half ago, and it is the shape I now see when I put it in front of a real team. The future of software work looks less like a ticket factory and more like a disciplined conversation that turns into code.
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.