Prototype with AI before you write the spec

In my line of work, moving a button from right to left costs three weeks. A user asks for it, the business side rewrites the request, it becomes a line in a ticket queue or a change order to the contract, engineering scopes it, a developer picks it up, and if everyone is being careful, someone checks it again in acceptance testing¹, assuming the ticket got prioritized at all. Then the loop often runs a second time, because the button turned out to be better on the right.

I'm a project manager on the business side, not a developer, on projects that take heterogeneous data from highly specialized fields and make it readable for people who aren't specialists. Discretion keeps me from saying more than that, but I can tell you what I do there now that AI can write a screen. The button now moves in 30 seconds, because the two people who decide are in the same room and the screen changes in front of them. The time saved matters less than the rest. A remark that costs three weeks, the business side, meaning the people who will actually use the tool, keeps to itself. The same remark at 30 seconds, they make.

The false yes in every spec

Think back to the last time you bought a car. You read the spec sheet, then you asked for a test drive, because nobody signs for a car they haven't driven. In my job, the spec sheet is called a requirements document, or a PRD² if you work in product rather than projects, it runs a hundred carefully proofread pages, at least by the people who read them, and the test drive doesn't exist. We ask the business side to sign anyway, because back when this way of working settled in, a test drive cost too much to offer them. That era is ending.

A spec fails in two ways, and neither is a writing mistake. Take the most ordinary line there is, "a validation button," and hand it to four people. None of them is wrong, each read it in good faith, and the document is still ambiguous, because "validate" means each person's own process. The gap shows up when someone builds, which is to say too late. The second failure is nastier. Put a user in front of a static image with a stack of case files waiting, and they'll say "yeah, that works" to get back to the stack. I call it the false yes. It looks like agreement, and you pay for it in acceptance testing, or worse, in production.

The false yes has a price tag. Pendo, a company that measures how people actually use software, went through 615 products in 2019 and concluded that 80% of their features were rarely or never used³. Those features didn't fail. Nobody dared to turn them down.

A mockup is for looking at, a demonstrator is for clicking

In meetings, everything is called "the mockup," which is why we talk past each other. Three different objects hide behind that word, and what separates them is what you do with them. A mockup is for looking at. An application is for running, with real data and real constraints, and that's engineering's job. In between, a demonstrator, a clickable prototype, is for handling. It's the only one of the three where the business side gets the keyboard before anything has been built.

A demonstrator, in my practice, is a folder of files that opens in a browser, with nothing to install beyond a text editor, no database, and no connection to the internal network, which makes it physically impossible to feed it real data. The data is fake but plausible ("restaurant, March 12, Bordeaux, 47 euros" rather than "expense 1, X euros"), the flow runs end to end, and everything actually works. It will never go to production and nobody will reuse its code. It does travel with the spec to engineering, though, so developers can see without ambiguity what the document describes. You're not building a product. You're building a conversation.

This is the only place where AI comes in, and in the most mundane way possible. The press calls it vibe coding⁴ and tells it as a story about developers or solo founders. My case is duller, and nobody is making a documentary about it. An agent⁵, the same model as your chat assistant but installed in a folder on my machine, writes the screen I describe, asks permission before acting, and stops on a single word. I describe what I want, I look at what shows up, and I judge by what I see. Coding isn't my job and I rarely read the code. In plain terms, I do my job as a project manager, with a tool that finally builds what I could only describe.

The workshop, four people and one mouse

The workshop decides everything, and it's the part people prepare least. A demonstrator you present is a guided tour, where the users admire it, offer congratulations, and send the project manager home with a handsome screen and zero decisions. A demonstrator you hand over takes preparation.

Four people from the business side, no more, because past that the quiet ones stop talking, and the quiet ones are usually the ones who know the edge case. Three to five questions to settle, written down in advance, with the participants adding their own. A backup screenshot in a corner, because the demo effect shows no mercy and I'm a jinx. Then the role play, "you have to process this request, go," after which the users handle the screen and I watch. That is the hardest move of all, because a project manager's reflex is to grab the mouse the moment someone hesitates. Don't. The hesitation is the information. And the question "what if I click here" is the exact opposite of the false yes, because in front of a screen that reacts, users try things, and what they're replaying is their own work.

While they talk, a decision log stays open on the next screen, each decision with its reason, and it's remarkable what people correct when they can see what you're writing about them. That log is the day's only deliverable. The exclusions are worth as much as the additions, and they only surface in a workshop, like the export feature everyone would have found handy on paper and nobody wants once it's on screen, because they suddenly picture who it would go to. You have to see the screen to understand you don't want to send it.

I watch what the business side gets out of it at every session. People are glad to take the keyboard and try things instead of sitting through a requirements meeting, and it makes them want to commit. The endless meetings where everyone tosses ideas around and nothing comes out have vanished from my calendar, and I don't miss them. In the usual circuit, I took a need from one side, rewrote it, passed it to the other side, and did the same in reverse with the answer. I was the pass-through, and I'm not sure I chose this job for that. Now I watch the need take shape in front of me and I settle it on the spot, which is probably the biggest change in how I work.

What the developer receives

The spec is still owed, in full, and it's richer than before. Its functional requirements, what the tool has to do, are no longer invented, they're recorded, screen by screen, and it lists the exclusions with their reasons, the only thing that keeps a feature from sneaking back six months later through someone who wasn't in the workshop. The agent drafts the document in a few minutes from the log, and it leaves the whole non-functional section, everything that doesn't show on screen, security, backups, how it holds up under load, marked "to be completed by the business side," which is exactly what you want. No user ever asks for a disaster recovery plan on their own, and the tool knows what it doesn't know.

On the engineering side, the buy-in was the pleasant surprise. Today a developer gets a hundred pages to interpret alone, plus whatever was said in a meeting that nobody wrote down. With a demonstrator, they get the same hundred pages and a screen they can open and click. When they're unsure, they don't schedule a meeting. They click. Developers see a project the business side has already validated, so far fewer costly rounds of arbitration, and far less risk of building something users will eventually call unsuitable. Deliveries show it, and negative feedback from end users has become rare.

The strongest objection comes from that side, and it's a fair one. A screen built in HTML in one afternoon bakes in interaction choices that cost nothing there and can cost plenty in the languages and software the final product will actually be built on. That is why the demonstrator is a target to aim at, never a build contract, and why I bring an engineering eye into the workshop rather than waiting for delivery.

Half a day with AI, if you can restrain yourself

My latest demonstrator, a small tool that tracks how long each person talks in a meeting, took five prompts and half a day, workshop and log included, and those two took longer than the generation. If I stopped here, anyone who tried would fail their first three demonstrators exactly the way I failed mine, because the difference between a demonstrator that gets a room talking and a pretty draft you throw away after an hour comes down to a few habits nobody figures out alone.

The first one is written once, in the file the agent rereads at every session⁶. The technical base, what this project is and will never be, and guardrails phrased as refusals. "Don't use a framework," those big developer toolkits a demonstrator has no use for, is a wish. "If I ask for React, one of them, refuse and remind me of the constraint" is an instruction that acts, and it still holds at 7 p.m. the night before a workshop, when I'm the one who forgot my own rule. Same thing for a coworker's first name slipped in out of habit, swapped for a fictional one on sight, and for the save feature the agent would add unprompted, complete with a nice confirmation message, when the whole point was to store nothing. What I don't say, it invents, and it invents well.

The second is asking for the states. A feature is four screens, the empty list, the loading state, the error, and the happy path, where everything goes right, and a mockup only ever shows the last one. Users don't talk in front of the happy path. They approve. They talk in front of the empty list, wondering who fills it in before they get there, and in front of the error message, remembering the special case in their department.

The third is one change at a time. You ask for a button, you get the button, and the agent renamed, reorganized, and prettified while it was in there, like an overeager intern tidying your desk while you're in a meeting. Nothing shows at the time. Everything shows in the workshop, when the flow that worked yesterday no longer works in front of six people. Forbidding improvements isn't enough. You have to give it somewhere to mention them, one line at the end, or it does them anyway.

The last is the order of passes, and I learned it the wrong way around. Behavior first, then states, then styling third and in a single pass, because it's the only one of the four you can't stop, then accessibility last, because a projected screen forgives no bad contrast. On that timer, which I've written about here before, I spent two whole steps polishing the look while the users were waiting for decisions. On the same one, the audit I have the agent run before every workshop caught a button that would have crashed on the projector, in front of everyone, after three people in the room had let it through. When the tool tells you "verified," ask it what it ran and what came back.

None of this is computer science. Anthropic publishes a four-part skills framework, delegation, description, discernment, and diligence⁷, and the prompt, the instruction you write to the machine, takes up one box out of twelve. The other 11, picking the right work to hand off, judging what comes out, owning it, a project manager already knows how to do, because that's the job applied to a new tool. And for projects where no data can leave the building, there are three tiers, in this order. Blur, because the shape of a screen is almost never sensitive when the data is. Go local, with a model that runs on your own machine. Or walk away, which is a decision to make and own like the others.

"It works, ship it"

One day someone looks at my demonstrator and says those words. My answer has to come out before they finish the sentence, because a second's hesitation counts as a yes. Nothing that's missing was forgotten, not the real data, not the permissions, not the save, not the disaster recovery, that's the whole point of the object. Its twin is sneakier, attachment. Users fall in love with what they handled and will find the real version worse. I say it at the first workshop, before the first click. This screen will never be the product, and that's why you can ask it for anything. Planning the funeral at the birth isn't romantic, but it works.

The method isn't for everyone. It demands real decisions, made on the spot and defended afterward to engineering and to the business side alike, and not every project manager wants that role. It works just as well for a product manager or a product owner as for a project manager, with a PRD in place of the spec, since the job is nearly the same and prototyping is already part of that culture. I came up from the business side, which helps me guess what will pay off for them, and I kept enough feel for the constraints engineers and technicians live with to find a fallback when their first answer doesn't fly. That mix is what makes it work for me, and I make no promises for anyone else.

Still, directors and project managers now come to me to see how I do it, and I show them gladly. I believe AI isn't made for everything, and I believe just as firmly that it has turned this part of my job inside out, the part that used to demand endless hours writing a spec nobody wanted to read. A demonstrator goes down a lot easier. If you want to try, don't start with management's strategic project, because if the first attempt is too big, there won't be a second. Start with whatever annoys you.

Notes

1. French IT projects split formally into the maîtrise d'ouvrage, the side that orders the tool and will use it, which I call the business side here, and the maîtrise d'œuvre, the side that builds it, engineering. Acceptance testing is the phase where users try what was delivered before it goes live, and it's where the misunderstandings come out. ↩

2. The product requirements document, the PRD that product managers write, plays the same role in product teams that the spec plays in projects, and it collects the same false yeses. ↩

3. Pendo, "The 2019 Feature Adoption Report", February 5, 2019, across 615 products observed for more than a year. An older figure of 64% gets quoted everywhere, attributed to the Standish Group in 2002, but it rested on four internal applications, as Mike Cohn pointed out. ↩

4. The term comes from Andrej Karpathy, formerly head of AI at Tesla, who described on February 2, 2025 a way of coding where you "fully give in to the vibes" and "forget that the code even exists." A demonstrator is exactly that, except you never forget the screen won't be the product. ↩

5. An agent is a language model installed on your machine that can read and write files and run commands, where a chat assistant only answers in a window, can't see the file, and therefore rewrites the whole thing at every remark. I use Claude Code because it's my daily tool, and Codex, from OpenAI, does the same work. ↩

6. Every agent rereads a project file at the start of each conversation, CLAUDE.md for Claude Code, AGENTS.md for Codex. The image that helped me is a brilliant but amnesiac project manager, replaced before every meeting, to whom you'd slip this document on the way into the room. ↩

7. Anthropic, "AI Fluency: Framework & Foundations", designed with Rick Dakan (Ringling College of Art and Design) and Joseph Feller (University College Cork). The four competencies are delegation, description, discernment, and diligence, each in three parts, twelve boxes in all, only one of which, under description, is about wording the request. ↩