Iterate, don't one-shot. The answer is in the route table.

Iterate. The short reason: a single prompt cannot describe an app well enough for the model to converge on the first try. The structural reason, at least in mk0r: the anonymous trial budgets 6 turns instead of 1, and the chat API exposes /undo, /redo, /revert, and /history but no regenerate-from-scratch endpoint. The product was rebuilt away from a 2-turn cap when the comment in src/app/api/chat/route.ts:21-22 noted that 'two turns was way too tight, users were getting blocked before they finished their first prompt cycle.' Iteration is what the surface area allows.

One-shot is one prompt in, one app out, with no follow-ups. If you want to change something, you write a fresh prompt and accept a fresh app, byte-for-byte different from the previous one. Iterate is one prompt in, one diff out, applied on top of the previous version. The agent edits files in place, not regenerates them. In mk0r the iterate path commits each turn to a git repo inside the VM (commitTurn at src/core/e2b.ts:1759), so a turn is undoable on its own and the previous version is recoverable byte-for-byte by SHA.

Because telemetry showed users were not getting through their first iteration loop at smaller numbers. The constant lives at src/app/api/chat/route.ts:23 as ANON_TURN_LIMIT = 6, with the comment 'Two turns was way too tight, users were getting blocked before they finished their first prompt cycle.' The number is the floor for a useful evaluation: one prompt to seed, two or three to refine, one to undo a misstep, one to retry. Below 6, you are evaluating the first draft alone, which for any non-trivial app is the wrong sample size.

Yes, for one specific case: when the app you want is small enough to describe in one sentence and you do not care if the result diverges from your sentence. A meme generator, a static landing tile, a tip calculator. The Quick Haiku mode that lives in the codebase exists for that case, fast and disposable. Anything with state, multiple screens, or a brand voice that has to be consistent across the app, you will iterate. Even a 'simple' to-do list usually needs one follow-up to fix the empty state.

The directory contains route.ts (one prompt, one turn, one commit), and the subdirectories /undo, /redo, /revert, /history, /cancel, /mode, and /model. There is no /regenerate, /generate, or /restart route. The only way to throw away a project and start fresh is to delete it and provision a new VM, which is intentionally not a one-click action. Once you have committed a turn, the cheapest path is always to iterate on top of it.

Because iteration without recoverable state is not iteration, it is gambling. commitTurn at src/core/e2b.ts:1759 runs `git add -A` and `git commit` inside the VM after every successful turn, then pushes the SHA onto a historyStack. undoTurn at src/core/e2b.ts:1855 walks that stack back via `git checkout <previous-sha>` and creates a new commit with the message 'Undo to <short-sha>'. The undo is itself a commit, so undo of undo (redoTurn at line 1868) also works, and the timeline survives the VM restarting. Without that substrate, 'undo' has to be 'please write back the version you wrote two prompts ago' and the model will get it close but not exact.

Sometimes. A detailed prompt is closer to a tightly scoped iteration than a true one-shot, because you are doing the iteration in your head before sending. The catch is that long prompts hit the same drift problem as long context: the model loses track of details from the front of the message by the time it gets to the back. In practice, a 200-word prompt followed by three 20-word follow-ups outperforms a single 400-word prompt, because each follow-up gets the full attention of the model on a small change.

Yes. Because /undo and /revert are real endpoints that map to byte-exact restore, the cost of being wrong is one click. That changes the kinds of prompts users send. They take more swings: 'try a totally different layout', 'now make it dark', 'go back two and try again'. With one-shot, the cost of being wrong is the wall-clock time to regenerate plus the cognitive cost of describing the prior version back to the model. Users converge to the first acceptable output and stop swinging. The taste muscle does not get the reps.