Agile's feedback loop starts one slice too late

We were already agile about it. Slice the work small, ship a thin slice, put it in front of stakeholders, loop. Map the stories, settle the design, build the top slice clean. And it mostly works — until someone uses that first real slice and says “oh — not like that.” The stories were right. The shared understanding wasn’t. So we loop again — except now we’re reworking shipped code, not a sketch.

The agile loop only starts after you’ve built something real. Getting feedback before the first slice would have meant building a full prototype up front, and that was never worth it — cheaper to ship the slice and find out. Story mapping (Jeff Patton) already points you toward prototyping the riskiest slice before building it. We did the mapping — we just skipped the prototype most of the time, and the times we didn’t, it ate too many resources up front.

That math just changed. A running prototype now costs a few tokens and a coffee’s worth of wait time. So the move is obvious — add one more loop, before the expensive one.

Vibe-code a throwaway, hand it over, and pipe what people say straight into the slices you were going to build anyway.

before:  map → design → ship slice → feedback → rework shipped code → loop
after:   map → design → prototype (the cheap loop) → feedback → ship slices that already aim right

Why this isn’t just a spike (or a walking skeleton)

• A spike (XP) produces a decision or a technical answer — it’s not something a stakeholder clicks.
• A walking skeleton / tracer bullet is deliberately not throwaway — it’s thin production code you keep and build on.
• A design sprint (Jake Knapp) is the closest: build a prototype, test it with users. But it’s a facilitated five-day workshop with a façade — a realistic-looking fake.

What’s new is the cost. A design sprint costs a week and a room; this costs a few tokens and a short wait. Cheap enough to build, click, and delete per feature — by the developer, in the normal flow — at higher fidelity than a façade and with none of the keep-it pressure of a tracer bullet.

The catch — which is why it’s only an experiment

Two real risks:

1. “Prototypes don’t get thrown out.” A vibe-coded demo convincing enough to test is convincing enough that someone says “just ship that.” The only defense is discipline: declare it disposable, keep it unmergeable, and actually mean it.
2. The upfront cost is real. Tokens and time spent before any “real” code exists. The entire bet is that early, concrete feedback prevents more rework than the prototype costs.

I don’t know yet whether it pays off. I’m going to run it on the next feature and report back: did the throwaway prototype catch a “not like that” before it got expensive — or was the initial passive spend just… spent?

The cheapest place to be wrong is in code you’ve already agreed to delete. The same argument, one step later in the process, is why I now read the decisions before the diff.

Follow-up resources

• User Story Mapping — Jeff Patton — the “shared understanding, not requirements” source, and the prototype-above-the-line idea.
• Spike (software development) — the XP research timebox, for contrast.
• Tracer bullets / walking skeleton — why those are explicitly not throwaway code.
• The Design Sprint — GV — Knapp’s prototype-and-test-with-users process, the nearest existing practice.