An AI coding agent is not a chat window with a code interpreter attached. The ones worth using are a pipeline: a planning stage that turns intent into a specification, a build stage where several specialised workers implement against that specification, and a verification stage that refuses to release a build it has not seen run.
Understanding that shape changes how you use one. You stop writing prompts that try to describe a finished application, and start writing briefs that a planner can turn into a contract.
Three phases, not one prompt
Echo exposes the pipeline directly. You choose **Plan** and the run stops after the architecture is written. You choose **Build** and it plans, then executes, then verifies, in one pass. Either way, the phases are the same:
- Planning — requirements, route graph, data model, API contracts.
- Building — specialist agents implement interface, state, data access and server routes in parallel.
- Verification — the project is compiled, requested and rendered inside an isolated browser sandbox.
Phase one: planning
The planner reads your brief and produces a technical blueprint before any file is edited: the routes the application will expose, the tables it will need, and the contracts between them. This step is doing something specific — it is moving decisions out of the implementation phase, where they are expensive, and into the phase where they are cheap to change.
Two things make the plan useful. First, it is a contract: the build agents all work from it, so they do not each invent their own interpretation of "a dashboard". Second, it is inspectable: you can read it, disagree with it, and change it before a single line of implementation code exists.
Phase two: parallel building
This is where an agent-based builder differs most from a single-shot code generator. Instead of one model writing a file at a time, Echo runs several specialist workers concurrently — typically one leading the interface, one on state and data access, one on the server routes, one on quality.
Two properties make this work in practice. The workers edit disjoint parts of the codebase, so they do not overwrite each other, and they share the plan, so they agree about the shape of the thing they are building. The result is a coherent application rather than a pile of files that happen to compile.
Parallelism also changes the economics. Work that is embarrassingly parallel — a list screen, a form, an API route, a test — finishes in roughly the time of the slowest item rather than the sum of all of them. That is where the wall-clock difference between an agent pipeline and a chat-based assistant comes from.
Phase three: verification
This is the phase that most tools skip, and skipping it is why so many AI-generated applications do not run. A build that type-checks is not a build that works: it can still have a route that throws, a component that crashes on first render, or markup that never received its styles.
Echo runs the generated project in an isolated sandbox and checks it the way a browser would:
- A strict TypeScript compilation, so type errors never reach a preview.
- Route requests against the running app, so a 500 on a real path is caught.
- A headless browser render, so the DOM actually appears.
- Styling completeness, so a screen does not ship as raw unstyled markup.
The important detail is that verification happens before the preview reaches you. You are not the first person to load the broken version.
Repair passes and retries
A failed check produces output — a compiler error, a stack trace, a failing assertion. That output is fed back into the build as a specific instruction rather than as a vague "try again". The agent fixes the actual cause and the verification runs again.
This is the part of the loop that is genuinely difficult, and it is why the retry budget matters: a plan that allows several repair passes will keep going after a failure that needs a decision from you. Plans in Echo differ in how many repair passes and retries they allow, and the difference shows up exactly when a build is hard.
Why the order matters
It is tempting to read plan → build → verify as three formatting steps. It is not. It is a cost model. Each phase exists because the alternative is more expensive:
- Plan first, because changing a route graph is a message; changing an implemented feature is a rebuild.
- Build in parallel, because the work is genuinely separable and the plan keeps it coherent.
- Verify before release, because the person who finds a defect is always more expensive than the machine that finds it.
An agent that skips planning to seem faster is making a trade you will pay for later. An agent that skips verification is making a trade the customer pays for.
How to brief an agent
The brief is the interface. A few rules that consistently produce better plans:
- Describe the user and the job, not the feature list. "A studio manager who needs to see which photographers are free on a date" beats "add a calendar page".
- Describe the data in plain language. "An invoice belongs to a client and has many line items" is enough for a planner to design a schema.
- Name the states that usually get forgotten: empty, loading, error, no permission.
- State exclusions explicitly. "Skip invoicing" removes a feature and saves a cycle.
- Break the work into flows. One complete flow beats ten half-built screens.
If you want the full walkthrough for a specific build, the guide on building a web application with AI goes from brief to export step by step.
Where you are still needed
Automation has not removed the parts of software work that require judgement. A verified build proves that the application runs; it does not prove that the product is right, that the data model will survive your second year, that the copy is right, or that the security model fits the business.
The practical division of labour is this: let the agent do the parts that are mechanical, verifiable and reversible — scaffolding, CRUD, plumbing, the boring 80% — and keep the parts that are expensive to reverse. That means you should be spending your attention on the plan, on the review, and on the decision of what to ship next. Everything else is what the pipeline is for.