Big Idea

The argument in one line.

Because AI has made code cheap to produce, resolving an open design or logic question by building a throwaway prototype beats trying to nail every detail in a spec before code exists.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You're using an AI coding agent and default to writing a detailed spec before letting it generate anything.
You've had an AI agent build 'the wrong thing' even after you thought you specified it clearly.
You want a repeatable process for turning ambiguous feature requests into working software.
You're curious how to structure custom skills or ticket systems for an AI coding agent.

SKIP IF…

You aren't doing AI-assisted coding at all — this is specific to that workflow.
You're looking for a general introduction to prototyping outside of an AI-agent context.

TL;DR

The full version, fast.

Spec-driven development assumes you can resolve every design and logic question through discussion alone, but some questions — how should this look, does this state model actually feel right — can only be answered by building something and reacting to it. Because AI has collapsed the cost of writing code, that kind of throwaway prototyping is now cheap enough to reach for constantly instead of occasionally. The prototype skill, part of a larger wayfinder ticket system, generates several genuinely different variants of a feature, lets you iterate on them by giving feedback against the running code, and hands the resulting throwaway branch to an implementer as a real reference artifact — closing a much smaller gap to production than a spec ever could.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 01:29

01 · The problem with spec-driven development

People pour effort into detailed specs so AI output will match, forgetting that writing code itself is now cheap — prototyping and spikes have fallen out of fashion.

01:29 – 02:55

02 · Understanding fidelity in design

Design questions sit on a ladder from low-fidelity discussion up through breadboards, wireframes, prototypes, to high-fidelity production code; some questions can only be answered at high fidelity.

02:55 – 03:57

03 · Prototyping in Wayfinder

The wayfinder skill splits a large body of work into typed tickets (grilling vs. prototype); reach for a prototype specifically when the question is how something should look or behave.

03:57 – 06:15

04 · Building a search bar prototype

Live demo: adding a search bar to a tldraw-based diagramming app produces three distinct UI variants (a/b/c) to react to and pick apart.

06:15 – 08:00

05 · Iterating on the prototype

Feedback is dictated directly against the running variants, compacted to retain design decisions while dropping token cost, and folded into a converged variant.

08:00 – 08:53

06 · From prototype to production

A finished prototype becomes a real reference artifact on a throwaway branch that an AFK implementation agent can copy from directly, not just a spec to interpret.

08:53 – 10:03

07 · Prototyping beyond frontend

Prototyping isn't only for UI — a logic prototype answers 'does this state model feel right' via a tiny interactive terminal app that exercises hard edge cases.

10:03 – 10:59

08 · Why higher fidelity matters

Most 'AI built the wrong thing' complaints trace back to low-fidelity discussions; recommends Shape Up by Ryan Singer and plugs the skills newsletter.

Atomic Insights

Lines worth screenshotting.

The cost of producing code has fallen so far that prototyping, not specifying, is now the cheapest way to resolve an open design question.
A prototype is throwaway code that answers a single question; the question decides its shape.
Design questions sit on a fidelity ladder: discussion, breadboards, wireframes, prototypes, and production-ready code, from lowest to highest fidelity.
Basic structural questions resolve fine through discussion, but 'how should this look or behave' questions usually need a working prototype.
A single prototyping session can generate several radically different variants of the same feature so you react to working code, not descriptions.
Compacting an AI coding session at a natural checkpoint can preserve design decisions already made while dropping the token cost of getting there.
A completed prototype isn't just a reference doc — it's real front-end code on a throwaway branch an implementer can copy directly.
Prototyping isn't only a UI technique; a pure logic prototype can be a tiny terminal app that pushes a state machine through hard edge cases.
The jump from a spec straight to production code is large; the jump from a working prototype to production code is comparatively small.
Most complaints that an AI agent 'built the wrong thing' trace back to design discussions that never reached a high enough fidelity.

Takeaway

Prototype the question, don't spec it.

WHAT TO LEARN

AI has made producing code so cheap that the fastest way to resolve an open design or logic question is a throwaway working prototype, not a more detailed spec.

01The problem with spec-driven development

Writing an exhaustive spec before generating any code ignores that the cost of producing code itself has fallen dramatically, making the spec-first instinct outdated.
You do not have to choose between planning and coding — you can write real code while still working toward the eventual spec.

02Understanding fidelity in design

Every open design question sits on a fidelity ladder from discussion through breadboards and wireframes up to prototypes and production code.
Because producing a prototype is now cheap, it makes sense to push more design discussions to a higher fidelity than habit would suggest.

03Prototyping in Wayfinder

A formal planning system can split a large body of work into tickets typed by the kind of question they resolve, not just by feature.
Reach for a prototype specifically when the open question is how something should look or how it should behave, not for basic structural choices.

04Building a search bar prototype

A single prototyping run can produce several genuinely different variants of the same feature so you react to working code instead of descriptions.
Reacting to multiple live, clickable variants surfaces concrete likes and dislikes about layout far faster than describing preferences in words would.

05Iterating on the prototype

Feedback on a prototype is given directly against the running version and folded back into a new variant, compounding decisions instead of starting over.
Deliberately compacting the session at a natural checkpoint preserves the design decisions already made while dropping the token cost of getting there.

06From prototype to production

A completed prototype is not just documentation — it is real front-end code on a throwaway branch that an implementation pass can copy directly.
The jump from a spec straight to production code is large; the jump from a working prototype to production code is comparatively small.

07Prototyping beyond frontend

Prototyping is not just a front-end technique — back-end and state-model questions benefit just as much from being tested in working code first.
A pure logic prototype can be a tiny interactive terminal app that pushes a state machine through edge cases that are hard to reason about on paper.

08Why higher fidelity matters

Most complaints that an AI coding agent built the wrong thing trace back to a discussion that never reached high enough fidelity before implementation started.
Treat the choice between resolving a question in discussion versus building a prototype as a deliberate cost/fidelity tradeoff, not a default habit either way.

Glossary

Terms worth knowing.

Prototype: Throwaway code written specifically to answer one open design or logic question, then discarded once the question is resolved.
Fidelity: How close a design artifact is to real, working software — ranging from a plain discussion (low fidelity) to production-ready code (high fidelity).
Wayfinder: A planning skill that splits a large body of work into a sequence of typed tickets — grilling, spec, tickets, implementation, and code review — so each planning session stays scoped.
Grilling: A structured Q&A session where an AI agent questions the user to pin down the basic scope of a feature before any code is written.
Spec-driven development: An approach to AI-assisted coding that tries to resolve every implementation detail in a written specification before any code is generated.
AFK agent: An AI coding agent left to work through an implementation task unattended, without the user actively steering each step.
Breadboard: A rough sketch of the flow and connections between screens or components, sitting a step below wireframes on the fidelity ladder.
Compacting: Condensing an AI coding session's conversation history down to its key decisions and context, to reduce token cost while continuing the same work.

Resources

Things they pointed at.

00:53toolMatt Pocock's skills repository ↗

10:29bookShape Up by Ryan Singer (free book) ↗

10:34linkMatt Pocock's skills newsletter ↗

Quotables

Lines you could clip.

00:01

“There's something that a lot of people do when they're working with AI to create code that totally drives me crazy.”

strong opinionated cold open→ TikTok hook↗ Tweet quote

00:59

“A prototype is throwaway code that answers a question.”

tight, quotable one-line definition of the whole concept→ newsletter pull-quote↗ Tweet quote

09:00

“You probably just weren't having discussions at a high enough fidelity and you probably should have been prototyping.”

direct diagnosis of a common AI-coding complaint→ IG reel cold open↗ Tweet quote

10:20

“The leap from discussion and spec to production ready code is really big. Whereas if you have a working prototype, turning that into production is pretty simple.”

crisp payoff line that reframes the whole video's argument→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

metaphorstory

00:00There's something that a lot of people do when they're working with AI to create code that totally drives me crazy. And it's sort of something that I've been railing against for a while now. The thing that I've noticed is people tend to think I need to create a spec for AI.

00:16I need to create a plan. Right? Plan mode, spec driven development.

00:20I need to put all of my efforts into making this extremely detailed spec so that when I get some outputs from the AI, those outputs are going to look like the spec. I'm gonna have specified everything up front so that I can just perfectly nail it.

00:33And in this impulse, what they forget to do is they forget they can actually write code. You can write code while you're working towards a spec. Prototyping and spikes are things that we've had around since the days of agile.

00:47Right? I mean, I suppose these are still the days of agile. Agile is still extremely popular, still extremely influential.

00:53But people just aren't prototyping anymore. And so as part of my skills repo, I'm trying to turn this around. I have a prototype skill.

01:00A prototype is throwaway code that answers a question. Everyone is saying that code is cheap, and it's partially true and partially I hate that phrase.

01:08But the thing that is cheap is the cost of producing code has gone way way down. So producing prototypes, producing quick kind of throwaway spikes has never been cheaper and never been a more effective tool.

01:21In this video, I'm gonna introduce this protosampt skill. I'm gonna talk about when you should use it, what it can be used for, and also how it fits into my new wayfinder skill. But first, I want to explain the concept of fidelity, high fidelity and low fidelity.

01:34Whenever you're talking about designing something, you're gonna have questions in your mind that need to be resolved somehow. Some of the questions are gonna be really basic, like the basic frame of the thing you're building. When the model opens up, it should have a cancel button and a confirm button.

01:50Simple stuff. With simple stuff like that, you don't need a lot of high fidelity stuff to answer the question. That can just be resolved in discussion, really.

01:58But let's say that the modal, when it opens up, under some circumstances, it needs to show some data. You might need to go a little bit of higher fidelity on that. How would you display the data?

02:07It's often hard when you're planning out a spec to figure out exactly how things should look and how things should look, how they should behave under certain circumstances, making sure that you've road tested all of this idea in kind of semi working code, that means you need a higher fidelity.

02:23Some questions really can only be answered by prototyping. And because producing these prototypes is now cheaper than it ever has been before, I tend to want more of my discussions at a higher fidelity. Obviously, the basic stuff, I'm gonna just resolve through discussion.

02:40So the agent is gonna ask me some questions, probably through a grilling session. And then I'm gonna say, okay. Yeah.

02:45This sounds good. But then as soon as we get anything that I think, oh, I really need to see this in action. I need to feel it in action, look at it working.

02:54I'm gonna ask for a prototype. Prototyping is a part of my new wayfinder skill, which is a skill that allows you to plan a huge chunk of work. There's a future video coming on wayfinder.

03:04Now, wayfinder, what it does is it tackles a huge chunk of work and it splits it up into different planning sessions. And all of these planning sessions get their own ticket and there should be somewhere in here ticket types just here that tells it exactly what different ticket types there are.

03:20The two that we're looking at here are the grilling type, so it's using the grilling skills, and the prototype ticket type. The default case here is the grilling type, so where you're chatting with the agent, figuring out the basic scope of the thing you're building.

03:35But when you need to raise the fidelity of the discussion, making a cheap rough concrete artifact to react to, outline an of rough take a stub or UI logic code via the prototype skill, links the prototype as an asset, use when, how should it look or how should it behave is the key question. Whether you're using Wayfinder or not, this gives you a really clear criteria for when you should reach for a prototype.

03:57So I'm sure you're dying to see it in action, and here it is. This is what it's done. I've been using Wayfinder to extend my diagramming app here, which is built on t l draw.

04:06And I wanted a way to search through old diagrams. And the data model here is quite complicated. There's, like, diagrams and then snapshots of the diagram through time.

04:15And so I wanted to build a search bar, but I wasn't sure how it should look or behave. So I ran prototype here, and what it did is it created this little picker at the bottom here.

04:26And this picker, if I go between it, it has three different options. So that's option b and that's option c. And each one encodes a few design decisions that I can then react to and iterate on.

04:38So let's start by looking at a. I've just generated this. I've not actually looked at it yet.

04:42So I get to search the diagrams and see what comes up. This one, okay, it's reflow in place grouped rows. So it's grouping the snapshot by the name of the diagram.

04:53I really like the placing of the search box up here, but this grouping doesn't feel right to me. So let's see what b is. Let's search again inside model here and okay.

05:04Now on the left, we have grouping for where it can filter down. Okay. That's quite nice.

05:11What happens if I search for something else and it's already okay. So the filter resets at that point. Now that's okay, but I wonder what c looks like.

05:20I really don't like this search diagrams thing at the top. That doesn't look nice, but let's see what this looks like. So let's search for model and oh, okay.

05:27So now it's everything in line. No filters. So I do actually really like this, but there are a few things that I don't like.

05:34I don't like these current things. It looks like this is really technical weird thing, but the the current one is showing with the diagram snapshot.

05:42So I've got some kind of feedback that I wanna give to the prototype. This prototyping session took about 100,000 tokens.

05:50So I'm actually going to compact and say we're gonna do some more QA on this. Compacting at this point makes sense to me because we kind of need to retain all of the information about the prototype, need to retain all the design decisions that went into it, but we just need to give it some feedback.

06:05So we just need to continue the conversation in the same place in the code base. I should definitely do a video about the design tree that I use for when I've got compact versus clear versus handoff, but, you know, that's one for another time. Okay.

06:16Now I'm gonna give some feedback. I really like the search box of a and I like the layout of c. Okay.

06:23So I've just dictated in some more feedback and I'm gonna send it off. So the idea of this session is I'm iterating on this prototype.

06:29I'm not just saying, okay, this is the best one. I'm gonna actually create some design decisions here, create a super rich asset. All of these design decisions are then going to be encoded into the prototype and I'm gonna save the prototype probably on a throwaway branch.

06:44That means that when the thing actually goes to implement it, it's not only got a spec, it's actually got real front end code that it can usually copy and paste out of it. Now creating these prototypes does take some time. Right?

06:55The higher fidelity you go, the more token cost there is. If we were to try to resolve this in a discussion, we'd be at a lower fidelity, so the answers would be less useful, but we'd also be spending fewer tokens. And we can see it's now starting to give me a d version here, which is kind of what I've been iterating towards.

07:12One note here is that this is actually integrated with the live page. So it's not doing this on a throwaway route.

07:20You can do that if you want to, but I really like seeing it actually plugged into the live route because then it just gives you so much more flexibility. It it like, it's a more honest representation of how the code is actually going to work. Alright.

07:34Looks like it's now created d. So let's see what that looks like.

07:38Yes. We have the box from a. And if we search in here with model, then we can see that everything I asked for actually got done.

07:46Before, we had a duplicate of this one, but now there's only one. And in theory, if I click this, I'm not sure if this will actually work. I don't know whether this is part of the prototype.

07:55Yes. It works. Oh, beautiful.

07:57But there we go. Loads of this functionality looks like it is now just done. And so you might ask, what is the next step after this?

08:04Well, now I consider the prototype to be complete. That was a pretty quick one. Usually, I'm kind of in here doing a lot more.

08:10I would pass this off to an AFK agent to plug in everything, delete the old prototype code, and just make sure that it was compliant with the original spec. And as you can imagine, the results here are incredible because we've had such high fidelity discussion, because we've been able to look at a live running version of it, give our feedback based on that, that feedback is so invaluable and it's already baked into a throwaway branch that our implementer can actually just go and reference.

08:40So many times I see people saying, well, the thing didn't build what I wanted. I created this big beautiful spec and it just did something totally weird. You probably just weren't having discussions at a high enough fidelity and you probably should have been prototyping.

08:54Finally, I don't want you to walk away thinking this is only for UI or front end stuff. Front end definitely benefits a lot from prototypes because how should it look, what should it look like is a really key question that's really hard to answer during the discussion phase. However, when you're doing more complicated stuff, especially back end work, then a question like does this logic, does this state model feel right?

09:17If you're building anything reasonably complex or that needs to work in the real world, then you're gonna run into these questions all the time. And often the best way to get around these kind of questions to build something that kind of serves the needs of your users, especially on something complex, is to build a prototype.

09:36Now it doesn't need to be a UI prototype. And what I've got here is build a tiny interactive terminal app that pushes the statement machine through cases that are hard to reason about on paper. In other words, a pure logic prototype.

09:48And I've had tons of feedback from folks saying that this is such a nice little feature. Both of these branches have their own reference docs here which tell it exactly how to do each one.

09:59So if it's building a logic prototype, it looks here. If it's building a UI prototype, it looks like this. So I beg of you, have your discussions at a higher fidelity.

10:07As agents get better at working with canvases, working with design tools, I'm sure that wireframes will definitely make a comeback as well. And the key point is this, the leap from discussion and spec to production ready code is really big. Whereas if you have a working prototype, turning that into production is pretty simple.

10:24I wanna give a quick shout out to Shape Up by Ryan Singer, which is an extremely good book and very very influential on me. I read this I think in 2019 or something and it totally changed the way that I built applications for people.

10:38It is totally free online and I will drop a link in the description. If you wanna keep up to date with my skills, then my skills newsletter is the place to be. I'm shipping shipping shipping constantly thinking about these skills, how I can make them better, and you can benefit from that the day that I make the changes.

10:53But folks, thank you so much for watching. It's been a pleasure as always bringing you one of my skills, and I will see you very soon.

The Hook

The bait, then the rug-pull.

Matt Pocock has a pet peeve with how people work with AI: they pour their effort into an exhaustive spec, hoping the output will match it exactly, and forget that AI has also made writing actual code cheaper than it's ever been.

Frameworks

Named ideas worth stealing.

01:34list

The Fidelity Ladder

Discussion
Breadboards
Wireframes
Prototypes
Production-Ready Code

Every open design question sits somewhere between low-fidelity (just talk it through) and high-fidelity (real running code); pick the rung the question actually needs.

Steal fordeciding how much upfront design work any ambiguous feature request deserves before writing real code

08:26list

Wayfinder Ticket Pipeline

grill-with-docs / wayfinder
to-spec
to-tickets
implement
code-review

A planning skill that carries a large chunk of work through discussion, spec, ticketing, implementation and review as one continuous, shared map.

Steal forstructuring a multi-session AI coding workflow so nothing gets lost between planning and shipping

08:59model

Prototype Branch Decision

LOGIC.md — does this logic/state model feel right?
UI.md — what should this look like?

The prototype skill picks one of two branches depending on which kind of question is being answered: a throwaway terminal harness for logic, or several UI variants for look-and-feel.

Steal forrouting any 'not sure this will work' moment to the right kind of throwaway artifact instead of more discussion

CTA Breakdown