Why AI prototypes need different kinds of constraint at different stages.
Generation has made producing an interface cheap. It has not made producing a coherent product cheap, and the gap between those two things is where a lot of AI prototyping falls apart.
The obvious correction is to constrain the model harder. Give it the component library on the first prompt. Point it at the MCP server. Make every prototype follow production rules from the beginning. This feels like the responsible move.
It also produces a specific failure. Hand a model the full system before you know what you're building and it becomes exceptionally good at showing you new arrangements of what you already have. Your spacing is correct. Your components are real. The idea never got a chance to exist.
The mistake isn't the amount of context. It's assuming the right amount is constant.
I've started thinking of the workflow as a three-layer cake: exploration first, design language second, production system last. Each layer adds context and deliberately narrows what's possible. That narrowing is useful, but only if it happens at the right moment.
The first layer is intentionally loose. No component library, no tokens, no exhaustive documentation. Give the model enough context to understand the problem, then permission to wander.
Show me three ways someone could accomplish this.
Say you're designing a way to schedule a recurring report. One generation might give you a step-by-step wizard. Another might put scheduling controls directly on each report. A third might produce a rules editor where schedules are just one kind of automation.
The third option may be completely wrong. It may also reveal that "schedule a recurring report" was a narrower framing of the problem than it needed to be.
That's the value of this layer.
Let the model make choices you wouldn't. Let it invent a component you don't have. Let the spacing be wrong and the buttons look nothing like your buttons. The output you want isn't a candidate to polish. It's surface area.
There's a useful parallel to wireframing here, with one important difference. We strip fidelity out of wireframes so structure is the thing left to argue about. AI prototypes arrive with the fidelity already applied, which means the discipline has to come from you. A generated screen can look thoroughly resolved while representing a decision nobody has actually made.
Polish is not maturity. At this stage, it can be actively misleading.
The useful work is reaction. This interaction makes sense. That hierarchy doesn't. This version assumes too much. That weird third option contains one idea worth keeping. Reacting to possibilities is often easier than specifying the right answer from nothing, and those reactions begin to expose what you actually care about.
There's a practical benefit to staying light, too: context isn't free. More context means more tokens to process, potentially slower turns, and more information competing for the model's attention. At the exploratory stage, that's a strange price to pay for constraints you're deliberately trying not to impose yet.
Context should earn its place.
A design system is very good at supplying answers. That's exactly why I don't necessarily want all of it in the room yet.
Layer one is about possibility.