Prototyping to settle an argument
When discussion stops converging, build the throwaway version. Cheap generation makes this a much better move than it used to be.
Some design questions cannot be resolved by talking. Does this API feel right to call? Is this abstraction worth the indirection? Will the query be fast enough? Prototyping is having the agent build a rough version specifically to answer one question — and then deleting it.
This used to be expensive enough that you argued instead. It no longer is, which changes the calculus: if a prototype would settle the question in twenty minutes, it is almost always cheaper than another round of discussion.
The rules that keep it useful
- Name the question first. "Prototype to find out whether the plugin API can express the three existing integrations." Not "prototype the plugin API". A prototype without a question becomes a draft of the real thing.
- Prototype on a branch you will delete. Say so out loud, in the session and to yourself. The moment a prototype might survive, you start making it good, and you have quietly started the real implementation without a spec.
- Skip everything not needed for the answer. No error handling, no tests, hard-coded data, one path only. Tell the agent explicitly — it will otherwise produce something responsibly complete and slow.
- Timebox it. One session. If the prototype needs two, the question is too big; split it.
Throwaway prototype. I will delete this branch. Question to answer: can the proposed plugin interface express our Stripe, Slack, and CSV-export integrations without special cases? Build the interface and the three plugins as thinly as possible. No tests, no error handling, no docs. Hard-code anything you need. Stop as soon as the question is answerable and tell me the answer.
Two prototypes beat one
When comparing designs, build both. Generation is cheap enough that a real comparison is now affordable, and the difference is usually obvious in the calling code, which is exactly the part you cannot judge from a description.
Build the same three call sites twice: once against design A, once against design B. Show me only the call sites, side by side. Do not argue for either.
Then throw it away
Actually delete it. Write down what you learned — two or three sentences — and start the real implementation from a spec, in a clean session. A prototype promoted to production is the origin story of a surprising amount of bad code, and now that prototypes are cheap, the temptation is stronger than it has ever been.
Watch out
Prototyping does not answer questions about scale, concurrency, or production failure modes. A hard-coded happy path tells you how an API feels, not how it behaves under load. Do not let a pleasant prototype substitute for thinking about the hard part.
Try it
Take a design decision you have been going back and forth on. Write the one question. Prototype both options in one session each. Then delete both branches and write the three sentences.
Takeaways
- Name the single question the prototype must answer before building it.
- Strip everything not needed for the answer, and say so explicitly.
- Delete the prototype and start the real work from a spec.
What is the tell that a prototype has stopped being a prototype?
You start adding error handling, tests, or naming things carefully. Those are signals you have begun treating it as code that will survive — which means you are now implementing without a spec and without a plan, from a codebase built to be thrown away.
A course by Pieter Zandbergen