In AI-orchestrated development you are the orchestrator. One piece of work moves through stages, and each stage happens in whichever tool does it best: a conversation with one model to plan, a design tool for the interface, an agent in the editor to build, something else to review, a pipeline to deploy. Nobody designed this as an architecture. It emerged because different tools are better at different stages, and it is how many experienced people already work.
It looks like a question of tool choice. Underneath it is a coordination problem: keeping one intention intact while it passes through tools that share no memory and were never meant to work together.
What it is for
- Work that genuinely has stages, where a better tool at one stage is worth the cost of the handoff.
- Solo builders and small teams shipping whole products, who cover planning, design, building, review and running it themselves.
- A reviewer that did not write the code. A fresh read from a different tool can catch what the author missed.
Who it suits
Experienced engineers and tech leads who already work from written specifications, and who can say why each tool in the chain is there. It suits people who would notice if one stage quietly changed what the stage before it decided.
How to tell this is your category
- You move work between tools by hand, copying text, files or links.
- Each stage of the work has a tool of its own, and you could name them in order.
- The plan lives in a document rather than in any one conversation.
- If several agents work in parallel on parts of the same stage, that is multi-agent software engineering, the other category on this rung. The two often combine.
What it costs you later
The layer page covers what the rung shares: coordination becoming the work, your attention as the ceiling, and the chain of tools as a maintenance surface. These costs come from the handoffs.
- You are the integration layer. Every handoff is you copying something from one tool into the next, and every copy is a summary. Whatever the planner decided and did not write down never reaches the builder. The fix is to stop handing over conversations and hand over files instead: requirements, design and tasks in the repository, which every tool in the chain reads and none of them owns.
- Each tool reinterprets. Every tool brings its own defaults. The planning stage assumes one way of handling errors, the building stage applies another, and the review stage judges against a third. Without one set of conventions that every stage reads, the work drifts a little at each step, and no single step is wrong. One plain rules file in the repository does more here than any one tool's settings.
- Review without the intent. A reviewing tool given only the diff reviews the diff. It can tell you the code is tidy and miss that it is the wrong change. Give the review stage the requirements and the design, and ask whether the change satisfies them, not only whether it reads well. Code review is the new bottleneck makes the case for reviewing the why.
- Your code in many places. Each tool in the chain is a separate account, a separate retention policy and a separate place a pasted secret can end up. Know what each one keeps and for how long. On client work that list is the client's business too, and worth agreeing with them before their code goes to five providers.
- Choosing tools becomes the work. There is always a newer tool for some stage, and evaluating it is time not spent shipping. Change a stage's tool when that stage is the bottleneck, not when something new appears. Learn the category and you can judge next year's tool in an afternoon.
Keeping the chain replaceable
- The input and output of every stage is a file in the repository: the requirements, the design, the tasks, the change and the review.
- Conventions live in one plain rules file that every tool reads.
- No stage depends on another tool's private format or memory.
- For each stage, you can say what you would use if its tool disappeared tomorrow.
Then every tool is replaceable, and what you keep is the method. A prompt is disposable. The specification behind it is not.