The most valuable file in my last few projects does not work. It has never worked. Every button in it is fake. Every piece of data in it is invented. Every "response" it produces was written in advance, by hand, like dialogue. And it made more decisions about the final product than any file that actually runs.

It is a prototype. Not the kind you were taught to be embarrassed about, the kind you were taught to throw away. This one is different, and the difference is the subject of this post.

Nothing Behind the Doors

Walk through one of the old studio backlots, the kind Hollywood shot on for half a century, and the first thing you notice is how little of it exists. The saloon has a front and no back. The sky is a cyclorama, painted canvas stretched behind the roofline. The doors open onto plywood and scaffolding. The second floor is a facade held up by braces, and nobody has ever climbed the staircase, because the staircase goes nowhere.

And yet the set is the only place where the film's true appearance exists. Not in the script, not in the storyboards, not in anyone's head. The exact color of the light, the texture of the walls, the way the space feels when a character walks through it. All of that is decided on the plywood stage, and the camera records it as truth. The set is a lie in every structural sense and the truth in every visible one.

Cinema never abandoned this; it only changed materials. The plywood became green fabric and render farms, and the lie moved somewhere harder to walk through. The old backlots and the theater stage are where the trick is still visible to the naked eye, which is why they are the versions worth studying.

Picasso said it about art: a lie that makes us realize truth. A prototype is the same kind of lie. Fake data, fake latency, fake everything, and still the only artifact in the entire project that shows the product as it will actually be seen. The implementation, for all its honesty, shows nothing. You cannot look at a reducer and see whether the interface feels right. The truth about how software looks and behaves is only visible in the fake version of it.

Once I started seeing prototypes this way, the embarrassment inverted. The fake was not the corner I was cutting. The fake was the point.

The Prototype Is the Bible

Film and television have a document they call the show bible: the reference that defines how everything looks and behaves, so that a hundred people making ten thousand decisions do not drift apart. Nobody debates the look of the show in episode six. The bible has already answered.

The prototyping literature never offers this option. It gives you a binary: the throwaway prototype, built to answer a question and then discarded, or the evolutionary prototype, which slowly hardens into the product itself, usually along with every shortcut you took while it was "just a prototype."

My prototypes are neither. They are not thrown away, and they will never ship. They get promoted, from sketch to bible. When the real implementation begins, every styling question has one answer: whatever the prototype does. What is the spacing between these cards? Open the prototype. How does the empty state look? Open the prototype. What happens on hover, how fast is the transition, where does the toast appear? The prototype has already answered, the way the set already answered before the camera rolled.

This kills a specific kind of waste I used to accept as normal: making taste decisions inside the implementation. Deciding on a border radius while a build is running. Judging a layout through the fog of half-finished state management, where every visual tweak costs a rebuild and every rebuild tempts you to say "good enough." Taste decisions made in that environment are not decisions. They are surrenders, scheduled by the compiler.

The prototype moves every one of those decisions into an environment where iteration is nearly free. I do the deciding on the set, where changing the sky is a brushstroke. By the time implementation starts, there is nothing left to decide. There is only building left.

Scripted Events

Here is the part that took me longest to get right, because it runs against every instinct an engineer has: the functionality in the prototype must be fake too. Not stubbed. Not simplified. Scripted.

When you press the button, the panel slides open and shows three results. Which three? The three I wrote into the script, the same way a screenwriter writes a line of dialogue. There is no search happening. There is a setTimeout and a hardcoded array, wearing a spinner as a costume.

The classic name for this is Wizard of Oz prototyping: fake the system, keep the experience real, let the user believe the machine is responding while a script produces every answer. In the original technique the script was a human behind a curtain, which is why the technique stayed expensive for decades. Someone had to build the curtain, and someone had to stand behind it. What changed recently is the price of curtains. I describe the choreography to Claude Code, and an artifact appears in which the entire performance is already staged: the click, the delay, the reveal, the error state I asked for on the third attempt. The wizard works for free now.

Why does scripting matter so much? Because a demo and an implementation answer different questions. An implementation answers: does it work? A scripted demo answers: what is it like to use? Users only ever ask the second. While I am deep in the intricate details of styling, the functionality plays alongside it as pure choreography, exactly as a user will experience it, with none of it existing. I am evaluating the experience of the feature before the feature.

The engineering instinct says this is dishonest. Build the real thing, even crudely, or you are looking at a fraud. But the crude real thing is the worse lie. Its jank tells you nothing about the design and everything about its own unfinishedness, and you cannot see the experience through it. The scripted version is the honest one, in the only sense that matters on a set: it shows precisely what the audience will see.

The Ad-Lib

So the prototype is the bible, the script, the source of truth. Film sets are also the place where scripts get overruled, and that is the part of the metaphor I actually care about.

The "tears in rain" monologue in Blade Runner was not in the script. Rutger Hauer cut the scripted speech down the night before shooting and added the closing line himself. In Raiders of the Lost Ark, the script called for an elaborate whip-versus-sword duel. Harrison Ford, too sick to film it, suggested just shooting the swordsman instead, and the scripted duel became a punchline the whole world remembers. The script said one thing. A human on the set saw something better. The better thing won, and then it became the script.

That is the exact shape of the loop I run with AI, and it is why the loop cannot be automated away. The model drafts the prototype fast and tirelessly. The set gets built in minutes, and I have written before about keeping that collaboration conversational rather than burying it in configuration. But the model does not know when the spacing is wrong. It produces the statistically plausible interface: the shadcn-shaped card, the gradient every landing page had last year, the layout that averages ten thousand layouts into one you have already seen. Ask it whether the result is good and it will say yes, with the same confidence it says everything else.

Taste is the ability to look at the plausible version and see the better one. It does not live in the weights, and it cannot be prompted into existence, because prompting it requires already having it. There is by now a whole genre of essays mourning taste as the new bottleneck. I have also written about the cost of articulating taste into words an agent can execute, and about the residue that refuses to become sentences at all. The prototype is where that residue goes to work. Taste that cannot be stated can still recognize. Recognition needs only two things: something visible to react to, and a price of overruling low enough to pay dozens of times an hour.

The prototype supplies both. The model proposes. I look at the rendered thing and say no: tighter, warmer, slower, cut it. The canon updates, and the next take starts from the corrected script. Every pass, the scripted truth gets overruled by a human eye, and the overruling becomes the new truth.

The ad-lib stories do not teach that scripts are worthless. Without a script there is no scene to improve. They teach one thing: when human taste sees past the plan, taste prevails, and the plan is updated to match. A process that cannot absorb the ad-lib ships the worse scene, on schedule.

Roll Camera

The lie has a lifecycle. The set is built before the film, decides how the film looks, and is torn down when shooting wraps, and every frame keeps its look anyway. The prototype is built before the product, absorbs every ad-lib my taste can land, becomes the bible, and never ships a single line into production. Then implementation begins, and it is the calmest phase of the project, because it has been demoted to what it always should have been: photography of decisions already made.

I no longer start projects by writing code. I start them by lying, as precisely as I can, and correcting the lie until it tells the truth.