The problem
AI agents make it very easy to build the wrong thing quickly.
You can open a chat, describe an app, and ask the agent to implement it. Sometimes that works. But for product work, especially UI work, one-shot prompting usually produces a mess. The agent adds too much text. It invents extra panels. It explains the interface inside the interface. It includes settings, labels, dashboards, and status sections that sound reasonable but do not belong in the actual product.
The issue is not that the agent is useless. The issue is that asking one chat to go from vague product idea to final implementation is too much. Product design is iterative. You need to clarify what the thing is, see it visually, react to what feels wrong, cut the extra pieces, and only then implement the real version.
So I stopped treating one chat as the whole workflow.
Now I build products across multiple agent chats, each with a different job.
The flow
The workflow looks like this:
clarify → mock up → critique → implement
Each step creates context for the next one.
The first chat is not allowed to build. Its job is to ask questions. I use my clarify skill for this. It interviews me until the product shape is clear enough to act on. What is the primary screen? What belongs in this app versus another app? What should be removed? What should the user actually do first? What should be out of scope?
This step is annoying in the useful way. It forces decisions before code exists. The agent asks the questions I would otherwise skip because I am impatient to see something on screen.
Once the product shape is clearer, I ask another chat to make an HTML mockup. Not a production implementation. Not the real framework. Just a fast visual artifact.
The HTML mockup is disposable, which is the point. It lets me react to the product without caring about component structure, backend wiring, state management, or whether the code is worth keeping. I can look at the screen and say: this section is unnecessary, this label is wrong, this button belongs next to that one, this whole panel should disappear.
Then I do the most important step: I critique the mockup.
The critique step matters
Agents overproduce UI by default.
They add explanatory copy because they are trying to be helpful. They add status indicators because they know systems have status. They add configuration panels because the schema or requirements mention related concepts. They add headings that explain the obvious. They add sections that make sense in a spec but feel dead in the actual app.
A human has to look at the result and say no: that text does not belong, the user does not need to see that, and this screen should just say “Chat.”
This is why I do not try to get the final UI in one shot. The first mockup is usually too verbose. That is fine. Its job is to give me something concrete to reject.
Once I start rejecting specific things, the design improves quickly. The prompt changes from “make me a UI” to “move this button next to Send, rename this section, remove this panel, remove this explanatory text.” Those are much better instructions. The agent is no longer guessing the product. It is editing against my taste.
Why HTML first
I like HTML mockups because they are cheap.
They are real enough to inspect in a browser, but not precious enough to defend. If the layout is wrong, I can throw it away. If the copy is bad, I can cut it. If the agent invented too much, I can delete entire sections without caring about breaking the app.
That changes the emotional cost of iteration.
If the first thing the agent builds is a real React implementation, critique feels heavier. Now there are components, files, state, styles, and maybe tests. Even if the code is disposable, it feels like work has been done, and that makes it easier to rationalize mediocre design.
HTML avoids that. It keeps the early stage where it belongs: fast, visual, and temporary.
Once the mockup feels right, then I ask an implementation chat to build it in the actual framework. At that point the agent has a much narrower job. It is not inventing the product and implementing it at the same time. It is translating a refined design into real code.
Takeaway
Use separate chats to clarify, mock up, critique, and implement. The mockup gives the human something concrete to cut before the implementation agent turns a vague product idea into durable code.