I build design prototypes as real, running applications, not clickable Figma wireframes. Claude Code makes that fast enough for a designer to iterate without an engineering team. This post is about why coded prototypes answer questions that fake ones can’t, and how I built a working onboarding flow in two frameworks, Astro and Expo, in a matter of days — the same onboarding flow eight users told me was backwards.
AI Prototyping: Why Real Code Beats Fake Prototypes
The onboarding research turned into a working prototype you could click through. Five web screens in Astro, React 19, and Tailwind. Then seven mobile screens in Expo with a real state store and clean TypeScript. When round two confirmed users wanted a conversational, structure-first flow, I rebuilt the entire mobile chat experience: three mock personas, 50 industry-matched items each across five subcategories, and a real CSV import path that parses your columns and auto-detects which one holds the item name.
None of that would have been possible with a Figma prototype. You cannot test a CSV import path in a clickable wireframe. You cannot watch someone navigate a real state store and see where it breaks. You cannot hand someone a phone and ask them to build their folder structure from scratch while the app actually responds. Faked prototypes answer whether the layout makes sense. Real prototypes answer whether the feature works.
The turnaround speed is the part that changes the economics. Five screens in one framework, seven in another, rebuilt after round two of research. In a traditional design-to-engineering handoff, each cycle would take weeks. With Claude Code, I built the first version in days and rebuilt it in days. The prototype stayed one step behind the research instead of one project phase behind.
The token handshake
Day one of the onboarding project, I pulled the brand tokens out of Figma, saved them to a reference note, and built the prototype against those exact values. The red, the type, the step palette all matched because the token never got re-typed by hand. Re-typing is where drift starts.
This is where the coded approach pays a second dividend. A Figma prototype uses Figma’s own rendering of those tokens, which is close but not identical to what ships. A coded prototype uses the actual CSS values against a real browser. When a color looks off, it is off in production, not just in the prototype. The gap between prototype and product shrinks to zero.
What broke, and what I changed
The honest part. The setup did not arrive clean.
A state-store selector caused an infinite render loop in two screens. A modal race condition killed the document picker until I added a 350ms delay. A vector-centering bug in Figma threw two icons off-center until I measured the rendered path instead of trusting the node bounds. None of these are interesting on their own. What matters is that each one is written down, so the next time I hit it, the fix is a search away.
I also learned to reject the clever answer when it is wrong. When a teammate proposed having AI auto-create folders from imported item data, I pushed back with the actual failure mode: 40 hammers spread across five real locations would collapse into one “Hammers” folder. Folder structure is organizational intent, not item taxonomy. At 800 items, the clever feature is worse than the problem it solves. A coded prototype let me test this claim before it became a committed feature.
The takeaway
Claude Code does the unglamorous heavy lifting. Scripting audits, generating screens, wiring state stores. So you can spend your energy on the design decisions that matter. The prototype runs in a real browser or on a real phone, the token values are the production values, and the bugs you catch are production bugs. Faking it answers the easy questions. Building it answers the hard ones.
