Prototype instead of specs - raise the fidelity of design discussions
- YT :: https://www.youtube.com/watch?v=n0VhIVtviC0
- Original title :: Don't waste time on specs: /prototype instead
Matt Pocock argues that people over-invest in detailed specs and plan mode and forget they can write code while working toward a spec. Producing throwaway code is now so cheap that a prototype, code that answers a question, is the best way to resolve design questions that discussion cannot. His /prototype skill (part of his skills repo and of the new Wayfinder planning skill) generates several variants plugged into the live app, he iterates on them, and the result is saved on a throwaway branch as a rich reference for the implementing agent.
The problem with spec-driven development
People believe that if they write an extremely detailed spec, the AI output will match it. In doing so they forget that prototypes and spikes, staples of Agile, are still available. A prototype is throwaway code that answers a question. "Code is cheap" is only partly true, but the cost of producing code has dropped so far that prototypes have never been cheaper or more effective.
Fidelity
Every design has questions that need resolving. Basic ones (a modal has cancel and confirm buttons) can be settled in discussion. Others - how data is displayed, how something behaves under certain circumstances - need semi-working code to road test, i.e. higher fidelity. Because prototypes are cheap, Matt wants more of his discussions at higher fidelity: the agent grills him on the basics, and as soon as he needs to see or feel something in action, he asks for a prototype.
Prototyping in Wayfinder
Wayfinder splits a huge chunk of work into planning sessions, each with its own ticket. The default ticket type is grilling (chatting to figure out scope). The prototype ticket type is for raising fidelity: making a cheap, rough, concrete artifact to react to, linked as an asset, used when "how should it look" or "how should it behave" is the key question. This gives clear criteria for reaching for a prototype, with or without Wayfinder.
Demo - a search bar
Matt was extending his TLDraw-based diagramming app with search over old diagrams and their snapshots, unsure how it should look or behave. /prototype added a picker with three variants, each encoding different design decisions: A groups snapshots by diagram name (he liked its search box placement, not the grouping), B adds left-side filter grouping (filters reset on new search), C shows everything inline with no filters (he liked the layout, disliked some technical-looking labels).
Iterating
The session used about 100,000 tokens, so he compacted: the prototype and its design decisions must be retained, only feedback needs to continue in the same place. He dictated feedback (search box of A, layout of C) and got a variant D with duplicates removed and click-through working. The prototype is plugged into the live route rather than a throwaway route, which is a more honest representation of how the code will work. Higher fidelity costs more tokens than discussion, but the answers are far more useful.
From prototype to production
The prototype is saved on a throwaway branch, so the implementer gets not just a spec but real front-end code to copy from. Matt would hand it to an AFK agent to plug everything in, delete the prototype code and check compliance with the original spec. If the build did not match what someone wanted from a big beautiful spec, they probably were not discussing at high enough fidelity.
Prototyping beyond frontend
UI prototypes suit "what should it look like" questions, but logic questions ("does this state model feel right?") in complex backend work benefit too. The skill has a logic branch: build a tiny interactive terminal app that pushes a state machine through cases that are hard to reason about on paper. Each branch (UI, logic) has its own reference doc.
Why higher fidelity matters
The leap from discussion and spec to production-ready code is big; from a working prototype to production it is small. Matt expects wireframes to return as agents get better with canvases and design tools. He credits Shape Up by Ryan Singer (free online) as a major influence and promotes his skills newsletter.