A prompt-driven style of AI-assisted programming, named by Andrej Karpathy in early 2025, in which you describe what you want, the model generates the code, and you iterate by prompting again. The chat log is the only record of intent. Karpathy scoped it to throwaway projects, outside production.

Prototype-Driven Development, Part II: Twin Trails

Q: What is spec-driven development?

A methodology in which a structured specification—not a prompt or a chat log—is the source of truth. You make the architectural and requirements decisions first, write them into a spec that lives in the repository, and have the agent implement against it. The spec preserves intent across sessions, contributors, and agents.

Q: What is prototype-driven development?

A practice of generating several working prototypes to discover which approach holds up, rather than settling the trade-offs through up-front planning. It treats cheap, throwaway prototypes as the primary way to learn what to build—while keeping enough of a record that the learning compounds instead of evaporating.

Q: How is prototype-driven development different from vibe coding?

Both move fast by building cheaply. Vibe coding keeps no durable record of intent or behavior, which is why it doesn’t survive contact with production. Prototype-driven development keeps the trail—forward (the spec) and backward (the telemetry)—so a wrong turn can be reverted rather than rebuilt.

Q: Why do AI prototypes look finished before they are?

Because AI systems produce a working-looking result early, often around 30% of the way to something releasable. The interface responds and the demo lands well before the approach has been proven, so teams commit to a path that later requires expensive backtracking.

Q: What does “laying the breadcrumb trail” require in practice?

Two records, captured at two times: a specification written before you build (what you intended) and telemetry captured as the system runs (what it actually did). Together they let you step back to a known-good intermediate state instead of discarding the whole pipeline.

Q: How does Prove AI facilitate prototype-driven development?

Prove AI works on the production end of this problem: once an AI system is live, figuring out what it’s actually doing — and which of the day’s issues is worth your time — is its own discipline. The platform is built for debugging and remediating AI systems in production, where the unsolved problem is rarely a shortage of things you could investigate; it’s knowing which one matters.

In traditional software, a result that looks 20% done means you’re probably about 20% done. When working with AI agents and the other productivity-boosting tools available today, however, you get a result at 20% done that looks almost finished because the interface responds, the demo lands, the pope blesses the pilot, etc. Then, the last 80% — the part where you find out the approach doesn’t actually hold — arrives as a series of expensive backtracks, wherein you swap your single-agent setup for a multi-agent one, for example, or realize that a retrieval strategy that worked in the demo crumbles under real traffic.

Each of those backtracks is the same move. You realize a decision made early was wrong, and you try to step back to the last good intermediate state and take a different branch. Whether you can do that — cheaply, or at all — is the whole question. And it turns out to depend on two records (I think of them as two breadcrumb trails) pointing in two different directions.

The two trails of productive development

The first trail runs forward. It’s the spec: the record of what you were trying to build and why, written before anything was actually built. This is the trail SDD is obsessed with, and for good reason. In its absence:

Your decisions live in a chat thread instead of a document;
A new engineer has nothing to read but a sequence of prompts;
Technical debt accumulates invisibly as the system takes its shape from conversational pivots rather than deliberate design.

The industry has a name for where this ends: architectural drift, where every prompt-and-response cycle makes a locally reasonable decision, the decisions are globally incoherent, and you wind up with a system with good performance and solid benchmarking but that nobody — including the model that wrote it — fully understands. Without the forward trail, you can’t back out of a dead end because you no longer know what “correct” was supposed to mean.

The second trail runs backward. It’s the telemetry generated from AI monitoring tools, the record of what the system actually did as it ran. When engineers are under pressure to ship and they don’t lay this trail, they proceed on the assumption that iteration and remediation can be done from whichever spot they land on. The trouble is, when the approach turns out to be wrong and you’ve kept no trace of how the system behaved, “throw it away and iterate” ends up being “throw it away and start over from scratch,” which isn’t at all the same thing. Your AI testing can’t be followed with a return to an intermediate state if you never recorded one.

Worse, this move might erode confidence because there are people (perhaps your boss or a decision-maker on an adjacent team) who saw what looked like an almost-functioning prototype, and now they can’t understand why you’re starting from zero.

As we discussed in Prototype-Driven Development Pt. 1, vibe coding, in its pure form, skips both trails, operating with no forward record of intent and no backward record of behavior, just a chat log and a result that looked finished at a third of the way through. That’s why it was always a weekend tool too inefficient to set a real project up for long-term success. As the vibe coding era draws to a close, it is being replaced with a more mature approach, prototype-driven development, which attempts to keep vibe coding’s speed without inheriting its blindness. The trails described above are the mechanism by which this is achieved, leading to more productive troubleshooting.

Lay both trails, and a wrong turn stops being a catastrophe and becomes a simple (or at least a simpler) rewind. The spec tells you which branch you’re abandoning and why; the telemetry tells you what the abandoned branch actually did, so the next attempt is informed rather than blind. You step back to the last good state instead of back to nothing. This is the same detect-to-remediate arc we talk about for production systems — notice something’s off, localize it, fix the specific thing — pulled forward into development, where the prototypes are still cheap and the cost of being wrong is supposed to be low. The trail is part of what keeps that cost low.

The forward trail is well-served today; specs are markdown, version control is a solved problem, and the SDD tooling is maturing fast. The backward trail is harder, and it’s where much work remains to be done. Capturing enough telemetry to reconstruct what an AI system did — not just latency and error rates, but the decisions, the tool calls, the intermediate outputs that explain why you got the result you got — is easy to defer. At Prove AI, we’ve come around to the view that a real solution will store this trail, make the intermediate states inspectible, and let you return to one without reconstructing it by hand.

Until that’s standard, the discipline has to cover for the tooling: lay the trail deliberately, because nothing is laying it for you yet.

This concludes part two of our treatment of prototype-driven development. The concept is still inchoate, as it is meant to capture an important aspect of a rapidly changing domain. If you’d like to discuss it or any other aspect of multi-agent systems engineering, we’ve set up a Discord server dedicated to exactly these subjects. Join us!