Throwaway UI Prototypes: Stop Describing UI to Your Agent
You ask Claude Code for a delete confirmation modal. It says done. You open the browser, and the button sits in the wrong place. The copy reads like you are about to nuke the database. So you type three paragraphs describing a problem you could point at in two seconds. By round four you wonder whether building it yourself would have been faster. Throwaway UI prototypes fix half of that loop. The review step fixes the rest.
Why Your Agent Cannot See What You Describe
Matt Pocock has been vocal about this. His argument is blunt: the model cannot see a UI, full stop. It writes markup fine. It has no idea whether the spacing is off or the copy reads as scary. So he leans on disposable variants. He asks an agent for three prototypes he can click between in a throwaway route, evaluates them visually, then commits to one before real code exists.
I buy that completely. The annoying part is the return trip. You still narrate visual problems in English. “The second button. No, the one to the left of that.” That is exactly the bottleneck prototyping was supposed to remove. You traded “the agent cannot see the UI” for “I can see it fine, but describing it in prose is slow and lossy.” The second problem gets far less attention than the first.
Throwaway UI Prototypes Cost Nothing to Get Wrong
The mental model is short. Prototype cheap. Review by pointing. Decide before you build real components.
The first half is discipline, not a tool. You ask the agent for a single disposable HTML file. Not production React. Not wired to your actual data. It exists to be thrown away, and that is the point. Mistakes in a throwaway file cost nothing. Mistakes in a merged PR cost an afternoon.
Neither half works alone. Disposable variants plus a clumsy review loop just relocate the bottleneck. A slick annotation tool pointed at production code defeats the purpose entirely, because every note now describes something expensive to change.
Reviewing by Pointing Instead of Typing
The tool I used is lavish-axi, built by Kun Chen. I want to be precise about what it does, because “prototyping tool” makes people assume it draws mockups. It does not generate UI. It opens whatever HTML the agent already wrote in a local browser. You click an element or highlight text and leave a note right there. That note travels back to the agent with the exact element attached. No screenshots. No “the button, you know, the blue one.”
It ships as an AXI, an agent-executable interface. That is just a CLI your agent runs on your behalf. No dashboard, and nothing to configure past installing the skill.
Running it on a real feature
I tried this on the family pictures feature in AllFamilyTree. You pick a family member, generate a picture, and it lands in the gallery. Nothing lets you delete one. A bad result stays there permanently.
I handed Claude Code the problem in plan mode. Then came the move that matters: I did not accept the plan. I switched to auto mode, pulled in the lavish skill, and asked for three prototypes of the delete feature in one tab-switchable file. Three separate files would have forced me to context switch myself.
Claude opened the prototype in the browser with three tabs and a chat panel. Variant A puts a trash icon behind a confirmation modal. Its copy warned that the delete is permanent, which reads more alarming than it needs to, so I clicked the sentence and asked for something softer. Variant B deletes instantly, with a five-second countdown and an undo right on the picture. Variant C adds a manage mode with multi-select. I picked A in the chat panel, ended the session, and the plan in the IDE updated to match.
Where it falls short
Not every custom control takes the click. Annotating the multi-select state in variant C simply did not register. Worth knowing before you lean on it. Here it did not matter, since bulk delete is more than this feature needs. One picture at a time is the real use case.
What the Prototype Loop Cannot Tell You
One step I would push you to add: before you lock a variant, check it against what your backend can actually support. Nothing in a prototype loop tells you that. It will happily let you approve a design your data model cannot back, and it will look just as convincing as the version that works. The click-through judges what a human can judge, which means spacing, copy, and flow. It says nothing about feasibility.
Key Takeaways
- Coding agents cannot see the interfaces they generate, so the fastest correction is visual rather than verbal.
- Asking for two or three disposable variants in a single throwaway file costs almost nothing to get wrong.
- Annotating an element directly beats describing it in prose, which is both slow and lossy.
- A tool like lavish-axi only pays off when it points at throwaway code, never at production components.
- A prototype loop validates design only, so you still need a separate check that your backend can support the variant you picked.
Conclusion
The next time a UI feature has more than one plausible design, resist asking for the final version first. Ask for a few throwaway UI prototypes in one file, then judge them by pointing at what is wrong. Whether you reach for lavish-axi or wire up something simpler, the shape holds: prototype cheap, get fast visual feedback, decide once, then let the agent build.
