Prototype Driven Development: Keep Your Plan Flexible as You Build with AI

Prototype Driven Development is a way of building with AI where you keep your plan but hold it loosely. When you hit a decision you can’t make on paper, you spin off a fast, throwaway prototype to settle it, then fold the answer back into the plan. Here is the shape of the workshop, and the seven ideas it is built around.

Most of us were taught to plan everything up front. Write the document, think it all through, get it right on paper, then build exactly what it says. The plan becomes a contract, and changing it feels like failing.

When you’re building products with AI, that’s backwards. A plan you’re scared to break turns every new thing you learn into a threat instead of a gift. You discover halfway in that a feature you were sure about feels clumsy in practice, and now you either admit the plan was wrong or keep marching toward something you no longer believe in. Most people keep marching, because the plan said so. That’s how products end up technically finished and quietly wrong.

You don’t need a plan you can’t change. You need a plan that bends.

That framing is where this workshop starts.

That is the shape. Here is what each part actually covers.

Start With a Spec, Not a Blank Prompt

Spec Driven Development (SDD) gives you the plan. You write down what you’re building and why, before an AI agent writes a line of code. That document is what the agent builds from, and it’s the difference between building and just messing around.

You almost always know what you want. You have the product in your head. You’re starting at point A, today, with nothing built, and you know you want to reach point B. What you don’t have is the route. From where you’re standing at A, you cannot see every turn between you and B, and no amount of staring at the document will reveal them.

Why Rigid Plans Fail When You Build With AI

Some ideas cannot be judged in your head or on paper. You can describe a screen in a document and feel great about it. Then you see it running, you tap through it, and within ten seconds you know it doesn’t work. No amount of additional planning would have told you that. You had to build the thing to find out.

So the problem isn’t that you made a plan. You should have a plan. The problem is treating the plan as fixed when the whole point of building is to learn. Prototype Driven Development (PDD) is what keeps the plan honest: it gives the spec a way to get smarter every time you discover something, instead of cracking the moment reality disagrees with it.

A Prototype Is a Probe, Not the Product

When most people hear “prototype,” they picture an early, rough version of the real thing, something you’ll clean up and grow into the finished product. Drop that picture. A prototype is a probe. You send it out to answer one question, it comes back with an answer, and then you throw it away.

Once you believe that, something freeing happens. The prototype’s code does not have to be good. Not clean, not well structured, not tested, not built the way your real product is built. None of it matters, because it’s never going into your product. That’s exactly why a prototype can be fast and cheap: you’ve given yourself permission to skip everything that makes real software expensive, because you’re not making real software. You’re asking a question.

The Loop, and Knowing When to Run It

The method itself is a short loop you run over and over while building. You work your plan. You hit a decision you can’t make on paper. You spin off a quick prototype built only to answer that one question. You click through it and form a real opinion. You fold the decision back into the spec, and you keep building until the next one.

The hard part isn’t running the loop. It’s knowing when to.

If you can settle a decision by thinking about it, settle it and keep moving. If you genuinely cannot judge it until you see it running, that is a prototype.

Prototyping has a cost, and a builder who prototypes everything never ships. We spend real time on this judgment, because it’s the difference between a method that speeds you up and a permission slip to tinker forever.

Keep the Learning, Throw Away the Code

The most tempting mistake in prototyping is reusing the prototype’s code in the real build. It feels efficient. You already wrote it, why waste it? But the moment you do, the throwaway code stops being throwaway, and every corner you were allowed to cut is now a corner cut in your actual product. Worse, you start defending the prototype’s choices because you’re attached to the code, instead of choosing what’s actually best.

What you keep is the verdict: we tried three layouts and the second one felt right, that feature we were excited about turned out to be confusing. Those sentences are worth more than any code the prototype contained, and they’re the part that flows back into the spec. You’ll practice capturing them, and feeding them back so both the plan and the build reflect the decision.

When B Turns Out to Be C

Sometimes you set out for B, and what you learn along the way is significant enough that B stops being the right destination. You prototype an idea, you see it running, and you realize the better product is slightly to the left of where you were headed. You end up at C instead of B.

That is not the method failing. That is the method working. A rigid plan would have dragged you all the way to a B that no longer made sense. PDD lets you notice, in time, that C was better all along.

And Then You Build One

Most of the session is hands-on. We’ll build a small app together from scratch using Cody Product Builder, with PDD as the backbone, and you’ll run the whole loop yourself: start with a spec, hit a real decision, spin off a quick prototype to settle it, capture the verdict, and feed it straight back into the build.

No coding experience is required. This is for domain experts and non-developers who have a real product in their head and AI to build it with. You’ll leave having practiced the exact workflow on a real app, with a repeatable method for moving fast without flying blind on your own projects.

Seats are limited, since the hands-on portion only works if the group stays small enough for me to help people individually. Early bird pricing is still open, so if you are considering it, now is the time to grab a spot.