Three weeks into a build and we haven’t opened Figma. Not once.

Not because we’re making a point. It’s just what AI product development actually looks like when you’re moving fast. The tools we learned to prototype with weren’t designed for agentic interfaces, dynamic model outputs, or systems where the “design” changes based on what the model returns. Figma is excellent for a lot of things. AI-native prototyping isn’t one of them.

If your design-to-dev handoff feels slower and stranger than it used to, this is why. Here’s what works instead.

What does AI prototyping actually look like?

AI prototyping is building a working version of an AI-powered product quickly enough to test real behavior before committing to full development. For traditional software, that meant wireframes, clickable mockups, and usability testing flows.

For AI products, those artifacts answer the wrong questions.

The problem: AI product behavior is generative. The interface isn’t static. What the model returns shapes what the user sees. You can design a container for a generative output. You can’t design the output itself. A Figma frame can’t simulate a hedging model response, a 14-second API call, or a hallucinated result your error handling wasn’t built for.

Real AI prototyping looks like code running against a live model. A working agent that does the thing, or gets close. Not a screen that looks like an agent might one day do it.

The fastest teams treat the prototype as a functional artifact, not a visual one. Working code over pretty mockups, every time.

Why Figma breaks down for AI product interfaces

Figma is a screen design tool. It excels at static layouts, component systems, and interaction states you can predict in advance.

AI interfaces are none of those things.

When you’re designing an agentic workflow, the critical questions aren’t about button placement. They’re: What does the interface show during a 12-second API call? How does the user correct the agent mid-task without losing context? What happens when the model hedges instead of answers? These questions don’t have answers in a Figma file. They have answers in running code.

The handoff problem compounds this. With traditional UI, a designer hands off a Figma file and a developer builds it. With AI products, the prototype is the implementation. The model behavior, the prompt structure, the output parsing, the error handling — these are design decisions made in code. A designer who can’t participate in that environment gets cut out of the most consequential design choices on the project.

We’ve seen this play out. The Figma file gets built. Engineering gets access to real model responses and rebuilds half the screens. The team has paid for two rounds of design. The second one is where the real design work actually happened.

What AI prototyping tools are actually replacing it

Here’s what’s in our stack:

Claude Code as the primary build tool. We use Claude Code to go from rough spec to running prototype in hours. The shift: you’re not designing how it looks, you’re designing what it does. A working prototype that answers a user’s question with real model output teaches you more in one session than a week of Figma iterations.

Direct LLM API access. Packaged AI tools are fine for demos. Real prototyping requires direct API access so you can understand latency, output variability, and prompt architecture from the start. We write against the raw API on day one.

Prompt files as design artifacts. The spec for an AI prototype is almost always a prompt. We version and iterate prompt files the same way you’d version a component library. They’re first-class design documents, not developer notes.

Short evaluation loops. AI design critique isn’t “does this button look right?” It’s “does this output help the user?” That requires running the thing. We build 24-hour evaluation loops into the first week so design decisions get tested against real outputs fast.

The mindset shift is what matters. When you accept that the prototype is code and the design is behavior, you stop spending time on artifacts that can’t answer your actual questions.

This is central to how we approach product design and software engineering — both practices operate on the same prototype from day one.

Prototype in week one vs. mockup in week four

Traditional product development assumed design comes before development. For AI products, that assumption breaks everything downstream.

The traditional workflow spends weeks producing artifacts that break the moment engineering touches the model. The AI-native workflow produces something testable in week one and refines from there.

A team with a working AI prototype and real user feedback by week four is in a different category from a team that’s still in Figma when the model API budget runs out.

The best product teams we work with adapted to this quickly. Designers moved from designing screens to designing behaviors. The teams that struggled held on to the old workflow because it felt safer. Our MVP development process is built around this: ship something testable fast, then build around behavior that’s already been validated.

What this changes about design and engineering collaboration

The line between design and engineering blurs in AI product development. That’s by design.

When your prototype is running code, the designer needs to understand what a prompt does to model behavior. The engineer needs to understand why a particular output feels wrong to a user. These aren’t separate competencies anymore. They’re the same conversation, happening in the same place.

What works: pair a designer and an engineer from day one. Not as handoff partners. As collaborators in the same build loop. The designer brings judgment about what the user needs. The engineer brings understanding of what the model can actually do. The prototype is where they meet.

Your team doesn’t need to figure this out alone. When Cabin builds AI products, your engineers work alongside ours. By the time we hand off, your team has lived through the build decisions, not just received documentation about them. That’s the difference between a team that can extend the product and a team waiting for the consultants to come back. More on how we think about that: consultant knowledge transfer that actually works.

Frequently asked questions

What is AI prototyping? AI prototyping is building a working, functional version of an AI-powered product quickly enough to test real behavior with real users. Unlike traditional software prototyping, which uses visual mockups, AI prototyping involves running live model interactions from day one. The goal is to validate behavior, not appearance, because AI interfaces are generative and can’t be fully designed in static tools.

Can you prototype AI products in Figma? You can prototype the static UI shell of an AI product in Figma, but not the AI behavior itself. Figma doesn’t connect to live models, can’t simulate variable outputs, and can’t answer questions about edge cases, latency, or hallucinations. Teams that try to fully prototype AI products in Figma typically rebuild significant portions once they encounter real model behavior in development.

How long does it take to build an AI prototype? With the right tools and a focused team, a functional AI prototype that tests core behavior can ship in week one. This isn’t a polished product. It’s a working system that answers real questions about whether the AI does what you need it to. The best teams we work with compress the design-to-prototype cycle to days.

What’s the difference between AI prototyping and an MVP? A prototype tests a hypothesis about behavior. An MVP ships enough product for real users to get sustained value. A good AI prototype answers the hardest questions first: does the model behavior solve the actual user problem? An MVP then builds the surrounding product around behavior that’s already been validated. Skip the prototype, and you’re building around a guess.

Does Cabin use Figma at all? Yes, for the right problems. We use Figma for component libraries, design systems, and interface work where outputs are predictable. For agentic workflows and dynamic AI interfaces, where model behavior is the design question, we prototype in code first. The tool should match the problem, not the habit.

Cabin is an AI transformation consultancy based in Charlotte, NC. We architect AI-native products, build agentic systems, and pair with your engineering team while we work so the capability stays after we leave. Our team has shipped 40+ enterprise products together. Learn more about Cabin.