Rapid prototyping started as a manufacturing term, where it still means 3D printing a physical part overnight. In software it names something else: a working method that compresses the loop between an idea and something you can put in front of a person. The material is different. The logic is the same. Make the next version cheap enough and you can afford to be wrong about the current one.
That last sentence is the entire method. Everything else is technique.
The loop, and why speed changes what you learn
The rapid prototyping cycle has four beats: build a rough version, show it to someone, learn what breaks, build the next one. Nothing about that is controversial. What teams underestimate is that shortening the loop does not just deliver the same lessons sooner. It changes which lessons you can afford to buy.
When one iteration costs three weeks, you get maybe four real attempts before a deadline, so you spend them cautiously. You test the version everyone already agrees on. When an iteration costs an afternoon, you can spend attempts on long shots: the weird navigation idea, the version with half the features removed, the layout nobody is sure about. Most of those die. The ones that survive are the insights a cautious process never finds, because a cautious process never runs the experiment.
Cheap iterations buy you the right to be wrong. That is the asset. Guard it.
Three techniques that keep the loop honest
Timebox the build, not the learning. Give a prototype a hard budget, half a day, two days at most, and let the deadline decide what gets faked. When the time runs out, you show what exists. Prototypes that miss their timebox have usually drifted into becoming the product.
Prototype the risky slice first. Most teams prototype the part they already know how to build, because it demos well. Backwards. Build the part you are least sure about: the onboarding step people might abandon, the data-entry screen that might be unbearable, the pricing page. If the risky slice fails, you just saved the cost of everything around it.
Run variants in parallel, not refinements in series. Serial refinement converges on a local maximum: version two is version one with the feedback applied, forever. Building two or three deliberately different takes and comparing them side by side is more work per round but converges on better answers, because the comparison itself teaches you what matters. This is where a canvas beats a document. Variants want to sit next to each other.
What changes with an agent in the loop
The historical constraint on all of this was build cost. Even a rough coded prototype took a developer-day, so teams substituted clickable mockups, which are cheaper but can only answer questions about appearance and flow, never about behavior.
With an AI agent on a canvas, the loop runs at conversation speed. You describe the screen in a sentence, the agent writes real code, and a running version appears next to your notes. Critique it, point at what is wrong, and the next take arrives while the conversation is still warm. Parallel variants stop being a discipline you must enforce and become the default, because asking for three takes costs roughly the same as asking for one. Where a wireframe is the right level of fidelity, sketch it first and let the agent build from the sketch. If you want to try that loop directly, start with an AI prototyping tool and give it a screen you are unsure about.
The method survives the tooling change intact. Timeboxes still matter, because agents will happily gold-plate. The risky slice still comes first. The thing that changes is the number of experiments a week can hold.
What rapid prototypes cannot tell you
A rapid prototype answers product questions: does anyone want this, can they use it, which version is better. It does not answer engineering questions. Nothing about a two-day build tells you how the design holds up under real load, real data volumes, or three years of feature growth. Treat any performance observed in a prototype as fiction, pleasant or otherwise.
The other standing risk is the prototype that refuses to die. A rough version that demos well acquires momentum, and someone will propose shipping it. Sometimes that is even right. But it is a decision about scope and quality that deserves to be made deliberately, which is the subject of prototype vs MVP. The rest of the craft, from fidelity choices to who should be in the room, lives in our prototyping pillar.