Miro AI Prototyping outputs a spec, not an app

What lands on the canvas when you hit generate

The Miro Prototype generator (Sidekicks > Formats > Prototype in the current UI) takes a text prompt, a screenshot, or a selection of existing frames and produces a draft directly on the board. You can pick device type (mobile, tablet, desktop) and choose single-screen or multi-screen at generation time. The draft is a stack of canvas frames with arrow connectors between them, plus a few default interaction states the AI guesses (a button tap routes to the next screen, a back arrow returns to the previous).

Last item is the load-bearing one. Everything Miro generates is a canvas object. Drag it, comment on it, restyle it. None of it is a running web app. The clickable preview is a stitched-together flow inside Miro, served from Miro’s board renderer, accessed by sharing a Miro board URL with people who have a Miro account.

Where working code is supposed to come from

Miro publishes a design-to-code workflow page that admits this gap and resolves it with a second tool. The shape of the recommended path:

Each arrow is a real piece of work. You build context on the canvas (a problem statement, user stories, frames). You generate the prototype with the AI Sidekick. You authenticate Miro’s MCP server. You connect a coding agent (Claude Code is the one Miro names in the docs) to that MCP server. The agent reads the board, writes code into a repo, you deploy that repo somewhere. The clickable canvas is one step inside a chain of five.

That chain is the whole product, not an edge case. Reading the Miro docs as a working sequence (rather than as marketing) lands on a clear claim: Miro AI Prototyping is a specification tool that hands off to an AI coding agent. It is not, on its own, an app maker. The canvas is the artifact you align around; the running app is downstream.

The case for spec first, code second

Splitting the spec layer from the build layer is a defensible choice. A canvas full of frames, sticky notes, decisions, and rejected variants carries more context than the final code does. When the coding agent runs, it gets to read all of that, not just the latest frame. Teams that already live in Miro for design review get to keep their existing workflow and bolt on code generation at the end, instead of replacing the workflow entirely.

When the canvas step is dead weight

Flip the audience. If the next person who needs to look at the prototype is a user, the canvas mockup is dead weight. A user wants a link they can open on their phone. They cannot open a Miro board on a phone in any useful way; they will not sit through a click-through that is rendered by Miro’s preview engine. They want to tap something that behaves like an app.

The same logic applies to throwaway prototypes you build to settle an internal argument. If the goal is “does this idea work at all,” reading running HTML on a phone gets you to the answer faster than reading a canvas on a laptop. The handoff to MCP and a coding agent doubles the surface area without doubling the signal.

The interesting thing about the second case is that the spec layer becomes a tax instead of an asset. You wrote the prompt twice, once into Miro to generate the canvas, once into Claude Code to generate the code. Half the time the second prompt drifts away from the first because the agent re-interprets the board. A code-first AI builder collapses both prompts into one input and writes the running app from a single sentence.

Concretely: open mk0r.com, type a sentence, watch HTML stream into a phone-shaped preview pane. The default fast path uses Claude Haiku 4.5 streaming directly into the browser; the deeper path runs the agent inside an E2B sandbox (template ID 2yi5lxazr1abcs2ew6h8) where Vite, React, TypeScript, Tailwind v4, and Playwright MCP are pre-installed at /app, and a dev server is already listening on port 5173. The agent has Playwright MCP wired in via src/core/e2b.ts:170-191 so it can open the running app in a real Chromium instance and verify what it just wrote before handing the iteration back to you.

The honest decision

Pick the tool that matches the audience for the artifact, not the tool with the most features.

If the artifact is going to a person who lives in Miro and the conversation around the canvas is the value, Miro’s prototype generator earns its credits. The MCP handoff to Claude Code is a clean way to keep that conversation context when you eventually need code. Two tools, two layers, an honest split.

If the artifact is going to a user and the running app is the value, the canvas step is friction. A code-first AI builder writes the running app from one prompt and skips the second tool entirely. Same reason a designer would not draw a Figma mockup of a tweet before sending the tweet: the running version is cheaper to produce than the spec.

A small experiment if you are stuck

Pick the next prototype you owe somebody. Build the same idea in both tools. In Miro, generate the canvas, share the board URL with whoever asked. In a code-first builder like mk0r, type one sentence and share the preview URL. Watch what they open first. Watch which one gets feedback you can act on. Watch which one survives the next twenty-four hours.

That experiment, run twice, settles the question for your specific audience faster than any blog post. Including this one.