The old handoff
A requirements document used to be a one-way handoff. A product person wrote down what should exist, a team read it, asked some questions, and went away to build it. Getting it right mattered a lot, because the next chance to correct a misunderstanding might be weeks away, at a review.
That cost shaped the document itself. Requirements got long, because long felt safer than wrong. Edge cases got written down because there was no other way to raise them before the build started.
What changes with intent
Intent is the same basic idea (what do you want?) but it isn't a one-way handoff any more. You state it, something builds it in minutes, and you react to the result straight away. If the brief is wrong, you find out in the next minute, not the next sprint review.
That changes what good intent looks like. A requirements document tries to be complete, because it's expensive to go back. Good intent tries to be clear about the outcome and the one or two constraints that genuinely matter, because going back costs almost nothing. "Build me a booking page for a dog groomer, maximum 12 slots a day, send me an email for each booking" is enough to start. You don't need to specify the button colour up front. You'll see it and say so.
Where this goes wrong
The failure mode isn't under-specifying. It's treating intent like a requirements document anyway: writing three pages before the first attempt, instead of one honest sentence and a fast correction. That drags the old cost structure back into a loop that was supposed to be cheap.
The other failure mode is the opposite: being vague about the one thing that actually matters (who can see this data, what happens if a payment fails) and precise about things that don't. An AI will build exactly what you asked for, including the part you didn't think to mention. Knowing which details are load-bearing, from your own experience of the problem, is still a human judgement. The AI can't supply it for you.
What stays the same
Good intent and good requirements share one thing: they both come from actually understanding the problem. Nothing about Continuous Creation removes that. What it removes is the cost of being wrong on the first try, which means intent can afford to be a first guess rather than a final answer.
Where we work
This is the first stage of the Continuous Creation Loop: Intent, Create, Validate, Deploy, Learn, Repeat. Getting intent right shortens every stage after it. Getting a prototype from that loop into something a real customer can rely on (the legal, hosting and compliance parts that intent alone doesn't cover) is where we work: see what that actually takes, or get in touch if you're past the prototype and stuck on what comes next.