Prototype-Driven Development: A New Approach

Q: What is prototype-driven development (PDD)?

Prototype-driven development is the practice of generating several cheap, working prototypes to learn what to build — instead of arguing trade-offs on a whiteboard first — while keeping a durable record of what you tried and why. It takes vibe coding’s bet that the fastest way to learn is to build a few versions and see which holds up, but drops the amnesia: the exploration compounds instead of evaporating.

Q: How is PDD different from vibe coding and spec-driven development?

Vibe coding optimizes for speed and throwaway exploration, with the chat log as its only source of truth — it fails at anything you need to revisit, maintain, or hand off. Spec-driven development front-loads the architectural thinking into a written specification that becomes the source of truth, trading up-front cost for continuity. Prototype-driven development sits between them: the source of truth is the prototype plus the trail it leaves, so you get fast exploration you can actually keep.

Q: Why is backing out of a prototype now one of the most expensive parts of development?

When code generation makes building cheap, the bottleneck shifts from writing code to deciding which prototype to keep and being able to unwind the ones you don’t want. Without a record of why each version was built and what it traded off, that decision — and the backtracking — gets slow, tedious, and error-prone. That’s why PDD pairs cheap prototyping with visibility into the exploration.

Q: What does PDD have to do with token costs and AI observability?

Cheap prototyping is only cheap if you can see what it’s costing and which explorations are worth pursuing. Token costs and context bloat can quietly turn fast iteration into an expensive habit (see Why are enterprise LLM bills exploding?), and breadth only helps if you can tell which prototypes are worth keeping. That visibility is the layer prototype-driven development depends on.

While code-generation tools have sped up the software lifecycle so much that one engineer can prompt a working prototype into existence in an afternoon, they have also given rise to new challenges; now, the hard problems are things like “knowing which prototype to keep” and “being able to back out of the ones you end up not wanting.”

There’s a term for this phenomenon — “prototype-driven development” (PDD) — which refers to the fact that many teams have shifted from arguing trade-offs on a whiteboard before any code is written to simply generating multiple working prototypes to see which approach holds up.

This piece will explore prototype-driven development and how it’s changing where design discipline must be exercised, in Prove AI and in other companies as well. To keep cheap prototyping from quietly turning into expensive (and endless, and tedious) reworking, in other words, I think it is necessary to have at least two different kinds of visibility into your efforts.

Only when both are implemented do teams have what they need to iterate quickly and make full use of AI agent systems.

Vibe coding, spec-driven development, and where prototyping fits

Backtracking from a prototype is now one of the more expensive parts of development. To see why, it helps to place prototype-driven development on a map that the industry has already started drawing, one running from “vibe coding” at one end to “spec-driven development (SDD)” at the other.

Vibe coding is the prompt-driven style Andrej Karpathy named in early 2025: you describe what you want, the code emerges as part of an AI workflow, and you iterate by prompting again. The chat log is the only record of why the system works the way it does. Because it gets lost in the discourse, it’s worth remembering that Karpathy scoped vibe coding to throwaway weekend projects, explicitly outside production. The failure mode everyone now associates with it — shipping a chat log to prod — isn’t a flaw in the idea so much as a boundary people aren’t tracking very carefully.

Spec-driven development grew up to fill that lacuna. Instead of prompting the model with what to build, you do the hard thinking first: you make the architectural decisions, write them into a structured specification that lives in the repo, and let the agent iteratively implement against it. The spec, not the prompt, becomes the source of truth. The payoff its advocates emphasize is continuity; the spec preserves intent across sessions, across team members, even across different agents, so the project’s non-negotiables don’t dissolve every time the context window rolls over or an engineer has their memories wiped by rogue nanomachines.

As we at Prove AI see it, prototype-driven development (PDD) sits somewhere between them. It takes vibe coding’s core bet — that the fastest way to learn what to build is to crank out a few cheap versions and see how they do — and it jettisons the amnesia inherent to most casual vibe coding efforts.

The basic idea is that you prototype to explore; you keep a record so that exploration compounds rather than evaporates. You can also think of it from the other direction: vibe code (perhaps against a spec) to discover the requirements, then formalize them before anything reaches production.

Three approaches, three sources of truth

Though this is all incomplete, the following table encapsulates some of the high-level ideas:

	Source of truth	Built for	Fails at
Vibe coding	The chat log	Speed, throwaway exploration	Anything you need to revisit, maintain, or hand off
Spec-driven development	The specification	Maintainability, shared intent	Up-front cost; false precision on paper
Prototype-driven development	The prototype plus the trail it leaves	Fast exploration you can actually keep	Nothing, if you lay the trail; everything, if you don’t

What if prototypes are nearly free?

There’s an optimistic (and still speculative) reading of all this worth pausing on. If prototypes are nearly free (leaving aside token costs), engineers could theoretically explore a far larger fraction of the design space than we could when each option cost a sprint. Put another way: when every line of code had to be written by hand, there was only so much of the space of possible software anyone could hope to lay their eyes upon. I can’t help but wonder whether that breadth lends itself to the discovery of integrations and architectures we’d never have planned our way into.

Whatever the case may be, one thing I know is true is that breadth only helps if you can tell which of your explorations are actually worth pursuing further.

In Part II, we’ll add many more details to this picture above. Does the concept of prototype-driven development capture aspects of your experience? If you have criticisms or additional thoughts, head over to our Discord server to let us know!