The first essay in this series, Never Trust the Agent’s Self-Report, was about verification: why an agent’s account of its own work cannot be trusted the way a human’s status update can. This one is about something upstream of verification. It’s about what an agent is allowed to build before anyone checks anything at all.
The instinct with a fast AI agent is to let it go fast. It can write a working prototype in minutes, so why not let it write the real thing in minutes too. We built our own studio on the opposite instinct, and it’s the single decision that has saved us the most rework.
The rule
Every piece of product work we run, whether it’s a client engagement or one of our own ventures, goes through the same sequence before a single line of production code exists: shape the problem, write a brief, build a throwaway prototype, simplify it, get an explicit human sign off. Only then does real engineering begin.
We proved this end to end on our own client portal. Twelve rounds of a live, disposable prototype, refined in front of the person who’d actually use it, before the backend was built. The prototype was never meant to survive. Its only job was to let a human say yes or no to the actual design, cheaply, before the expensive part started.
An agent that can generate working code in minutes will happily generate the wrong working code in minutes. Speed doesn’t fix that. It just means you find out you built the wrong thing faster.
Why this is an organizational rule, not a technical one
It would be easy to read this as a software engineering practice: prototype before you build, obviously. But the reason it matters for an agentic organization specifically is different. A human engineer who jumps straight to code usually still carries the org’s unwritten assumptions about what “done” looks like. An agent doesn’t have those assumptions unless you hand them over explicitly, and it will confidently fill any gap you leave with something plausible rather than something correct.
The brief and the prototype aren’t paperwork. They’re the mechanism by which a human’s judgment gets attached to the work before the agent has spent real effort on the wrong version of it. Skip that step and you haven’t saved time. You’ve just moved the correction later, when it’s attached to production code instead of a disposable mockup.
The boundary this creates
This is also where an agent’s authority gets scoped, concretely. Our own working rule states it as plainly as we can: no backend in the prototype stage, ever. Not because the agent couldn’t build one. Because the prototype’s entire value depends on staying cheap and disposable, and a real backend is neither.
That boundary only works if it’s written down somewhere the agent actually reads it, not held as an assumption in a person’s head. This is one reason we lean so heavily on version controlled decision records for anything an agent might act on: the boundary has to survive past the conversation where it was decided, and outlast whichever specific agent session is doing the work that day.
What we’d tell another studio doing this
If you’re handing real work to an agent for the first time, the tempting move is to give it a vague goal and let it move fast toward something. Don’t. Give it a narrow, disposable first step, and put a human sign off between that step and anything that becomes permanent. The discipline isn’t about distrust of the agent’s ability. It’s an acknowledgment that speed and correctness are different problems, and an agent solves the first one far faster than it solves the second.
The organizations that get real value from agentic work won’t be the ones that let agents skip the slow parts. They’ll be the ones that figured out which parts have to stay slow on purpose, and held that line even when the agent could have gone faster.