Prototyping is using an agent to throw together a rough version of something fast, so you can see it, poke at it, and decide what to actually build. The output is disposable by design. You are buying information about the idea, not shipping the code. Prototyping is where vibe coding earns its keep: you steer on feel because the code is not meant to last.
Why agents changed this
Prototyping used to carry a cost: even a throwaway version took real hours, so you thought twice before building one. Agents collapse that cost. You can stand up three different approaches in the time it once took to argue about one, then keep the version that feels right and bin the rest. The cheapest way to learn whether an idea works is often to build a scrappy version and look at it.
The trap is letting the prototype quietly become the product. Code written for speed skips the things that make software safe to run: error handling, tests, structure. That is fine while it is a prototype and a real problem the moment it is load-bearing.
- Optimise for speed and learning, not correctness or polish.
- Discard freely. A prototype that taught you something did its job.
- If you decide to keep it, rebuild it properly rather than patching the throwaway.
Related terms
Vibe coding
Vibe coding is building software by prompting an agent and steering on feel, accepting the code it writes without reading every line. It is fast and freeing for prototypes and personal tools, and genuinely risky the moment the code has to run in production.
Read definition →Spec
A spec is a written description of what to build and why, handed to the agent up front. Specs-as-context reliably beat vague one-line requests.
Read definition →Design doc
A design doc is a short written description of how you plan to build something, written before you build it. It forces you and the agent to commit to an approach and surfaces problems while they are still cheap to fix.
Read definition →