Prototype to learn in code

Why this matters

Say a client can't picture the new scheduling flow from your Figma frames. A prototype lets them feel it — and gives you proof for the next call. Working with an agent, code is often the fastest medium: real wrapping, real keyboard input, real motion, real content, with nothing specified twice.

What to understand

You don't need a fidelity debate before every build. Just ask: what must feel convincing in this review, what must actually work, and what can stay faked?

Pick the medium that exposes your open question. A sketch can compare navigation; clickable frames can test understanding; code can test interaction; a real connection can reveal waiting time and data limits. Mix them freely.

When this doesn't apply

Code isn't always the answer. When the question is navigation or understanding, a sketch or clickable frames decide faster. Save code for when interaction, wrapping, input, motion, or data limits are what you need to learn.

In practice

Say you're testing crew scheduling: let a foreman assign a crew and a crew member find tomorrow's site. Use realistic test data and finish the whole path. Five connected states teach you more than twenty pretty but disconnected screens.

A fake role switch shows what a role feels like. It proves nothing about who-can-do-what enforcement. Use clearly isolated test data, never real customer data, unless the environment is ready for it.

Build a runnable prototype for the crew scheduling task.
Use the existing app and components. Show one complete assignment flow.
Use clearly isolated fixture data; preserve edits within this demo session.
Include a narrow layout and a failed-save state with retained input.
Keep payroll and notifications out of scope.
Open the result, replay the task, and tell me what remains simulated.

When the build is approved, your agent should build the thing — not hand you another plan. Use $prototype for this workflow and $craft when the composition or interaction needs a deeper pass.

Give your reviewer something to do without explaining the screen first. Watch where they pause, misread a status, or hunt for a missing action. Write down what you saw separately from what you think it means.

Track keep → change → test again against the client's original goal. Recheck each fix in the running prototype. One state can explain the problem — you rarely need to rebuild everything.

When a prototype graduates to a real project, list everything faked: test data, demo-only saved state, pretend success, missing permission checks. Keep the good components and what you learned about interaction; replace the fakery at clear boundaries.

Ask your agent: "list everything in this prototype that is still faked, and where each fake ends."

Related skills

Use $slice to build one real workflow and $readiness to judge whether it's ready for its intended use. Even a tiny pilot with real data needs who-can-do-what checks, recovery, and clear ownership.