Nobody one-shots good software. The first spec produces a prototype, and the real shape shows up as you use it. Plan for the first ten versions to be wrong, and get to the eleventh as fast and as cheaply as you can.
“One-shotting” imagines a perfect spec going in and finished software coming out. But most of what a product needs is unknown until something exists to try. The spec is an input to the first version and an output of the later ones: each round makes it sharper.
So the prototype isn’t the end. It has to be questioned, proven and refined. Agents don’t remove that work. They make each round cheap enough to do many of them.
Works for small, well-known problems. For anything new, “done” is a prototype that nobody has used yet.
The dashed steps repeat. Each round changes the code and the spec, and records what was learned.
There are two questions about every version. Does it do what we said? And is what we said the right thing? The first can be made deterministic. The second can’t.
| Correctness | Fitness: product and performance | |
|---|---|---|
| Question | Does it do what we said? | Is what we said right? Is it usable, fast enough, shaped well? |
| Check | Tests, types, lint, schema, conformance | Use it, integrate it, measure it, judge it |
| Once set up | Deterministic and low-attention. The agent loops run it without you. | Needs iteration, and needs someone to decide what “better” means |
| Where it’s covered | Agentic Loop Engineering, Rules that enforce themselves | Point them at a number, and this chapter |
That is what the guardrails are for. When correctness checks itself, attention is free for the question no guardrail can answer.
If the first ten versions are going to be wrong, what matters is how long it takes to get through them, and how much human attention each one uses.
Faster code alone doesn’t get you there. If every version still waits for a person to check that it works, the person becomes the queue. Guardrails take correctness off that person’s plate, and a network of consumers does the first pass on fitness. Then a round costs hours, and the human time goes into judging the result.
The durations are illustrative, not measured. Choose a way of working and watch the eleven rounds.
Not every version is cheap to throw away. Once an API is published, people build on it, and changing it breaks them. So the rounds have to happen before publishing.
For an API, fitness means ergonomics: can someone use it for real work without fighting it? You only find out by using it. So implement it, then consume it from several different integrations. Each integration is a first user. Every awkward call, workaround and wrong first guess is feedback that arrives before anyone outside depends on the API.
“Given enough eyeballs, all bugs are shallow.” The same works for fitness, with the eyeballs replaced by a network of integrations. One engineer can run it: agents write the API, then agents write the integrations that consume it.
For the Camunda SDKs, the network is the seven SDKs generated from the API spec and the harnesses built on top of them. Choose a consumer to see what it found before (or soon after) release.
Agents raise the rate at which features ship. Every feature brings its share of defects and fitness problems. If the number of consumers stays the same, the share they catch stays the same, and everything else lands on users.
So when the code speeds up, the integration and scenario network has to grow with it. That is cheap to do, because agents write the integrations too.
An illustrative model, not a measurement: each feature brings one problem, and each consumer independently catches a quarter of what reaches it.
Agent consumers find friction fast: calls that take too much setup, names that mislead, operations that are easy to misuse, things that are missing. They don’t share your users’ goals, and they share blind spots with the agents that wrote the API. The proxy network gets you to version eleven before publishing. Real users and production telemetry judge it after.
Don’t expect to one-shot it. Make correctness deterministic so it costs no attention, build a network of consumers that uses each version before anyone else does, and grow that network as fast as the code. Then go through the wrong versions quickly and cheaply, and publish the eleventh.