radar

Prototyping at higher fidelity: use code to discover the spec

concept 23 July 2026

Prototyping at higher fidelity: use code to discover the spec

Source: Matt Pocock, “Don't waste time on specs: /prototype instead”, accessed 2026-07-23.

Executive summary

Matt Pocock argues that teams over-invest in detailed specs for AI coding agents and underuse working prototypes. The better pattern is to match the fidelity of the artifact to the uncertainty: resolve simple questions in discussion, but build throwaway code when the real question is “how should this look, behave, or feel?” [Source: Matt Pocock, YouTube, 2026-07-23]

Because AI has sharply reduced the cost of producing code, prototypes and spikes are now unusually cheap discovery tools. A prototype is not an early production build; it is throwaway code that answers a question and creates a concrete object for feedback. [Source: Matt Pocock, YouTube, 2026-07-23]

In the demonstrated workflow, the agent generates several UI variants, the human reacts to concrete trade-offs, and the chosen decisions are iterated into a high-fidelity reference implementation. The final implementation agent receives not only a spec but also working code and a record of tested design decisions. [Source: Matt Pocock, YouTube, 2026-07-23]

The approach applies beyond frontend work. Backend logic, state models, and hard-to-reason edge cases can be explored through small terminal apps or other executable logic prototypes. [Source: Matt Pocock, YouTube, 2026-07-23]

Key ideas

Chapters

Raw transcript

The transcript below is YouTube's English transcript, retrieved 2026-07-23. Minor auto-caption errors are preserved for provenance.

[0:00] There'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. [0:11] The thing that I've noticed is people tend to think I need to create a spec for AI. I need to create a plan, right? [0:18] Plan mode, spec driven development. I need to put all of my efforts into making this extremely detailed spec so that when I get some outputs from the [0:26] AI, those outputs are going to look like the spec. I'm going to have specified everything up front so that I can just perfectly nail it. And in this impulse, [0:34] what they forget to do is they forget they can actually write code. You can write code while you're working towards [0:41] a spec. Prototyping and spikes are things that we've had around since the days of agile, right? I mean, I suppose [0:48] these are still the days of agile. Agile is still extremely popular, still extremely influential, but people just aren't prototyping anymore. And so, as [0:55] part of my skills repo, I'm trying to turn this around. I have a prototype skill. A prototype is throwaway code that answers a question. Everyone is [1:04] saying that code is cheap. And it's partially true and partially I hate that phrase. But the thing that is cheap is the cost of producing code has gone way, [1:12] way down. So producing prototypes, producing quick kind of throwaway spikes has never been cheaper and never been a [1:20] more effective tool. In this video, I'm going to introduce this prototype skill. [1:23] I'm going to 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 [1:30] concept of fidelity, high fidelity and low fidelity. Whenever you're talking about designing something, you're going to have questions in your mind that need [1:39] to be resolved somehow. Some of the questions are going to be really basic like the basic frame of the thing you're building. When the modal opens up, it [1:48] should have a cancel button and a confirm button. Simple stuff. With simple stuff like that, you don't need a lot of highfidelity stuff to answer the [1:55] question. That can just be resolved in discussion really. But let's say that the modal when it opens up under some circumstances, it needs to show some [2:02] data. You might need to go a little bit of higher fidelity on that. How would you display the data? It's often hard when you're planning out a spec to [2:09] figure out exactly how things should look and how things should look, how they should behave under certain circumstances. Making sure that you've [2:17] road tested all of this idea in kind of semiworking code, that means you need a higher fidelity. Some questions really [2:25] can only be answered by prototyping. And because producing these prototypes is now cheaper than it ever has been [2:32] before, I tend to want more of my discussions at a higher fidelity. [2:37] Obviously, the basic stuff I'm going to just resolve through discussion. So, the agent is going to ask me some questions, probably through a grilling session, and then I'm going to say, "Okay, yeah, this [2:45] 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," I'm going to ask for a prototype. [2:55] Prototyping is a part of my new wayfinder skill, which is a skill that allows you to plan a huge chunk of work. [3:01] There's a future video coming on Wayfinder. Now, Wayfinder, what it does is it tackles a huge chunk of work and it splits it up into different planning [3:10] sessions. And all of these planning sessions get their own ticket. And there should be somewhere in here ticket types [3:16] just here that tells it exactly what different ticket types there are. The two that we're looking at here are the grilling type. So, it's using the [3:25] grilling skills and the prototype ticket type. The default case here is the grilling type. So, where you're chatting [3:32] with the agent, figuring out the basic scope of the thing you're building. But when you need to raise the fidelity of the discussion, making a cheap rough [3:39] concrete artifact to react to an outline, a 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 [3:48] it behave is the key question. Whether you're using Wavefinder or not, this gives you a really clear criteria for when you should reach for a prototype. [3:57] So, 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 Wavefinder to extend my diagramming app here, which is [4:05] built on TL Draw. And I wanted a way to search through old diagrams. And the data model here is quite complicated. [4:12] There's like diagrams and then snapshots of the diagram through time. And so, I wanted to build a search bar, but I wasn't sure how it should look or [4:20] behave. So I ran prototype here. And what it did is it created this little uh picker at the bottom here. And this [4:27] picker, if I go between it, it has three different options. So that's option B and that's option C. And each one [4:34] encodes a few design decisions that I can then react to and iterate on. So let's start by looking at A. I've just generated this. I've not actually looked [4:41] at it yet. So I get to search the diagrams and see what comes up. And this one. Okay, it's reflow in place grouped [4:49] rows. So, it's grouping the snapshot by the name of the diagram. I really like the placing of the search box up here. [4:56] But this grouping doesn't feel right to me. So, let's see what B is. Let's search again inside model here. And [5:04] okay, now on the left we have grouping for or it can filter down. Okay, that's quite nice. What happens if I search for [5:13] 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. I really don't like this search [5:21] 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 ooh. Okay, so now it's everything in [5:29] line, no filters. So, I do actually really like this, but there are a few things that I don't like. I don't like these current things. It looks like this [5:36] is a really technical weird thing, but the the current one is showing with the diagram snapshot. So, I've got some kind [5:44] of feedback that I want to give to the prototype. This prototyping session took about 100,000 tokens. So, I'm actually [5:51] going to compact and say we're going to do some more QA on this. Compacting at this point makes sense to me because we kind of need to retain all of the [5:59] information about the prototype, need to retain all the design decisions that went into it, but we just need to give it some feedback. So, we just need to continue the conversation in the same [6:08] place in the codebase. 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. [6:16] Okay, now I'm going to give some feedback. I really like the search box of A and I like the layout of C. Okay, so I've just dictated in some more feedback and I'm going to send it off. [6:26] So the idea of this session is I'm iterating on this prototype. I'm not just saying, okay, this is the best one. [6:32] I'm going to actually create some design decisions here, create a super rich asset. All of these design decisions are then going to be encoded into the [6:40] prototype and I'm going to save the prototype probably on a throwaway branch. That means that when the thing actually goes to implement it, it's not [6:47] 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? [6:55] The 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 [7:03] 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 [7:11] iterating towards. One note here is that this is actually uh integrated with the live page. So it's not doing this on a [7:20] throwaway route. You can do that if you want to, but I really like seeing it actually plugged into the live route [7:27] because then it just gives you so much more flexibility. like it's a more honest representation of how the code is actually going to work. All right, looks [7:34] like it has now created D. So let's see what that looks like. Yes, we have the box from A. And if we search in here [7:41] with model, then we can see that everything I asked for actually got done. Before we had a duplicate of this one, but now there's only one. And in [7:51] 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. [7:55] Yes, it works. Oh, beautiful. So there we go. Loads of this functionality. [7:59] Looks like it is now just done. And so you might ask, what is the next step after this? Well, now I consider the prototype to be complete. That was a [8:07] pretty quick one. Usually I'm kind of in here doing a lot more. Um, I would pass this off to an AFK agent to plug in everything, delete the old prototype [8:16] code, and just make sure that it was uh compliant with the original spec. And as you can imagine, the results here are incredible because we've had such [8:25] highfidelity discussion because we've been able to look at a live running version of it, give our feedback based [8:32] on that. That feedback is so invaluable and it's already baked into a throwaway branch that our implement can actually [8:39] just go and reference. So 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 [8:47] something totally weird." you probably just weren't having discussions at a high enough fidelity and you probably should have been prototyping. Finally, I don't want you to walk away thinking this is only for UI or front-end stuff. [8:58] Front end definitely benefits a lot from prototypes because how should it look? [9:03] 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 [9:11] stuff, especially backend work, then a question like does this logic, does this state model feel right? If you're building anything reasonably complex or [9:19] that needs to work in the real world, then you're going to run into these questions all the time. And often the best way to get around these kind of [9:26] questions, to build something that kind of serves the needs of your users, especially on something complex, is to [9:34] build a prototype. Now, 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 [9:42] machine through cases that are hard to reason about on paper. In other words, a pure logic prototype. And I've had tons [9:50] 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 [9:58] do each one. So 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 [10:05] discussions at a higher fidelity. As agents get better at working with canvases, working with design tools, I'm sure that wireframes will definitely [10:12] 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 [10:21] working prototype, turning that into production is pretty simple. I want to give a quick shout out to Shape Up by Ryan Singer, which is an extremely good [10:30] book and very very influential on me. I read this I think in 2019 or something and it totally changed the way that I [10:37] built applications for people. It is totally free online and I will drop a link in the description. If you want to keep up to date with my skills, then my skills newsletter is the place to be. I [10:46] am 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. But folks, thank you so [10:54] much for watching. It's been a pleasure as always bringing you one of my skills and I will see you very