Though it’s certainly a relevant factor, I don’t view enhanced speed as the most important dividend of cheap prototyping; I think the real payoff is greater reach. When building a second or third version of something took an entire sprint, you probably did what I used to do: commit to the first approach that worked at all while arguing the rest on a whiteboard. When it only costs an afternoon, however, you can make a few different bets and see which one holds, which means you end up exploring parts of the design space you probably wouldn’t have planned your way toward.
We’ve spent decades learning to wrangle logic into useful shapes, but, in all that time, we’ve largely surveyed the territory on foot. With cheap prototyping, however, it’s as if we’re witnessing the development of the first aircraft: riding atop the engines of automated workflows and AI agent coding assistants, you can cover more ground in an afternoon than you used to in a quarter, and structure that was invisible from the trail comes into view when you take to the air.
Part two of this series was about discipline: lay the breadcrumb trail so a wrong turn is a revert instead of a teardown. This part is about what that discipline buys you. Explore more of the design space, and I think you will learn (at least) two things at once:
- You learn about the problem you’re solving (“problem-side learning”);
- You learn about the solutions available to you (“solution-side learning”).
Both types of learning are better served if you keep a record of what each exploration taught you, and we’ll discuss why in more detail below.
Finally, another idea I want to take up naturally falls out of these speculations, and it revolves around having an assistant to explore with, not just one you fence in after you’ve figured out what you want to build.
With that in mind, let’s get into it!
What parts of the territory are reachable through prototyping?
Not every state is equally reachable with cheap prototypes, a point made during a discussion in our Discord server for multi-agent systems engineers (M.A.S.E.). This particular objection came from someone with a lot of experience in backend and frontend engineering, who pointed out that frontend work can often be validated by looking: you mock the interface, wire up fake data, click through, and can tell in short order whether it feels right. Backend work, the argument went, is different. The parts that matter — data model, performance under load, concurrency, failure modes — don’t show up in a prototype, so one that “works” tells you almost nothing, because the things that break it only appear once it’s carrying real weight.
But I don’t read this objection as saying that “the design space is narrower for backends,” I think it’s more that you can’t tell which bets are good by simply looking. Put another way, the two domains differ in where the evidence lives. Frontend evidence sits on the surface. Backend evidence only exists once the system runs and you watch what it does. Some things you learn from the forward record, some only from the backward one, i.e., the trail of what happened when the code met reality.
The concurrency bug, the query that melts at production volume, the failure mode nobody designed for — these are constraints you likely couldn’t have specified up front; you find them by building something and running into them. That’s the problem-side learning made concrete, but the teaching only happens if you run it and monitor it using tools appropriate for AI observability (or just observability in general).
Where do these practices actually sit?
It helps to render the terrain as a literal map, with two axes: what you keep as you build, and what role the assistant plays for you while you go about building:
Vibe coding
no trail kept
Spec-driven
owns the spec
Prototype-driven
both trails kept
Design partner
co-design mode
In this map, the vertical axis pertains to what record you keep, ranging from “nothing,” to “a spec,” to “both the spec and the telemetry trail.” The horizontal axis is new, and it addresses the role the AI agent assistant plays. On the left, it is left unsupervised to make decisions. In the middle, you own the decisions and the assistant executes them, with the spec functioning as a fence erected to keep it from doing something you don’t want. Vibe coding sits bottom-left (keeps nothing, supervises nothing), which is why it was only ever a weekend tool. Spec-driven development adds the forward trail and takes the wheel, but its whole posture toward the assistant is to constrain it.
Though the concept of prototype-driven development is still pretty new, I think at least some of its variants sit directly above this cell — both the forward and backward trails now exist, but the relationship is largely unchanged inasmuch as the agent is an executor, not a partner.
Notice what that arrangement shows: everything we’ve discussed so far treats the assistant as something to hem in, with the only question being how good a record you keep while doing it. The more interesting cell is the top-right: both trails kept, and an assistant you actually design with rather than around. That is the question the rest of this piece takes up.
What if the AI agents were design partners?
Let’s start by asking who benefits from the wider design space. If you’re vibe-coding a throwaway, five candidate architectures are worth nothing to you, because you’re not operating at the level where the differences register. The payoff is reserved for people who care about the architecture, who can look at three data models or two coordination strategies and tell what each one commits them to. I suspect that’s most of the engineers reading this and participating in the multi-agent systems engineering (M.A.S.E.) Discord server, and it’s the first reason the design-partner idea isn’t a toy: seeing more of the space only compounds if you’re equipped to read what you’re seeing.
This surfaces a split in how practitioners actually experience today’s assistants. The optimistic case says that, when used well, an assistant surfaces patterns from a far wider distribution than any single engineer has internalized; it has read more architectures than you have, and can propose ones you wouldn’t have reached for. Builders shipping real systems have sometimes reported the opposite: the assistant pushes generic patterns that don’t fit the actual constraints, habits that aren’t easy to squash without opening every prompt with a list of what not to do (which would surely lead to the kinds of duplication that cause ballooning token costs).
The resolution starts with asking why the patterns come out generic in the first place. They’re generic because the assistant is being used as an executor, being handed an implementation task with no seat at the design table and no view of the constraints that would rule the median option out. A model that doesn’t know your load profile, your consistency requirements, or your failure budget will reach for the most common pattern, because, absent constraints, that’s the safest guess. The generic output is less a real ceiling and more of what you’d expect from a simple executor when it’s omitted from the conversation that would have made it more tailored to local design specifics.
If you change the mode by bringing the assistant into the architectural discussion before implementation, with the constraints as the subject rather than after-the-fact corrections, the same model that produced slop as an executor could become a source of real alternatives as a partner.
Three things move:
- Constraints enter up front instead of as “don’t do X” patches;
- The assistant makes proposals at the level of approaches you can weigh against each other, not code you have to reverse-engineer;
- Exploration is decoupled from commitment, so you’re comparing designs rather than debugging the one you’re already married to.
My hypothesis is that this is a mode that is commonly missing — a high-level architectural back-and-forth with the assistant, run on its own, independent of whatever you happen to be implementing. We have “code, observe, constrain.” We don’t yet have “design together, then build.”
Why does collaboration need the trail?
Go back to the empty corner of the map and notice there is no practice at the bottom-right — collaborative relationship, no record kept — because the cell is incoherent. You cannot design with something that retains nothing about what you decided or what the last attempt did. Strip out the record and the design conversation resets every session; you re-litigate the same trade-offs, re-discover the same constraints, and the assistant proposes the median pattern again because nothing in the room remembers why you ruled it out. Collaboration and grounding aren’t separate virtues, and the trail is what makes a design partner possible at all.
This perspective changes how we think about what each trail is for. The spec stops being a fence erected after you caught the assistant misbehaving and becomes the co-authored record of a design conversation covering the approaches considered, the ones rejected, and the constraints that led to their demise. That’s a richer artifact than a list of prohibitions, and it lets the next conversation start where the last one ended. The backward trail does the other half: it tells both parties what a candidate approach actually did when it ran. Without it, you’re not comparing designs; you’re comparing opinions about designs, which is the whiteboard argument the whole practice was supposed to replace.
That second requirement is where the general claim of this piece meets its hardest case. Deterministic software has had decades of tooling for watching what it does. AI systems — and especially those constructed around the power of AI agents — produce behavior that is non-deterministic and opaque from the outside, and the questions you need answered to evaluate a design are not the ones traditional monitoring answers. Host latency and error rates won’t tell you why the coordination strategy you tried degraded on the third hop, or which tool call sent the run sideways, or whether the failure is in the architecture or in one bad prompt. The evidence a design partner would need is exactly the evidence agentic systems make hardest to get.
So the frontier has a prerequisite, and it isn’t a new model. It’s the ability to see what a candidate actually did: the decisions, the tool calls, the intermediate outputs that explain how you arrived at the outcome rather than merely what the outcome was.
Conclusion
Cheap prototyping widens the design space you can afford to explore, and exploring it teaches you two things at once: the constraints you couldn’t have named up front, and the approaches you’d never have planned toward. Those learnings compound, but only if you keep what each lap turns up — otherwise you’re wandering the space rather than mapping it. That much is true of any software. Where it gets interesting is the frontier: today we tend to fence an AI agent out of the architectural conversation and then complain that its architecture is generic. The alternative is to bring it in, constraints first, before the code exists, and to give both parties enough visibility into what the candidate approaches actually did that the conversation can be about evidence rather than opinion.
Prototype fast, keep the trail, and start designing with the assistant instead of around it.
Hopefully, this matches your own experience and ambitions. Whether it does or doesn’t, I’d love to hear your opinions in our M.A.S.E. Discord server, where we debate these and many other topics involved in AI testing, AI engineering, and generally getting the most out of modern tools. Join us!
Frequently asked questions
Self-hostable and free. Connect your existing observability stack and see your top three issues in minutes.
Download on GitHub
