In a fictional demonstration, a customer chooses a service, selects a date and submits a booking. A confirmation appears, the dashboard updates and everyone can understand the idea.
That’s a successful prototype. It has helped people see and discuss a possible product.
Now try cancelling the booking after a deposit has been recorded. Or submit the same request twice. Or sign in as another customer and try opening the first customer’s booking.
The next set of questions is different. A prototype shows that an interaction can make sense. Production software needs to preserve the business rules while real people, real data and imperfect connections move through it.
The March 2025 discussion of vibe coding makes this distinction timely. Simon Willison separates building with AI without reviewing the generated code from AI-assisted development that includes understanding and verification.1 Using AI does not remove the engineering work, and a prototype does not need to pretend it has already completed it.
Inspect the booking behind the green tick
A convincing prototype can resemble a film set. The front door works, the windows look lovely and nobody has yet asked where the rainwater goes.
For our sample booking tool, a practical review would follow the whole operation:
- Validate the request on the server, including the selected service and available slot.
- Check that the signed-in person is permitted to view or change the booking.
- Protect the operation against duplicate submissions and competing claims on capacity.
- Define what happens when payment and booking confirmation don’t complete together.
- Make cancellation and recovery follow the agreed business policy.
Each point is a design responsibility. A loading spinner and a disabled button can help the interface, but they do not establish that two requests cannot arrive from different browser tabs.
The server needs to enforce the capacity rule. The application needs to retain enough information to distinguish a new request from an attempt to finish one already in progress.
We build AI agents with clear jobs and sensible limits. See how.
Likewise, removing a booking from the screen does not necessarily cancel the associated work. If a deposit has been taken or another team has started preparation, cancellation may involve further steps. Those steps need clear ownership and an honest status.
It is perfectly reasonable for an early prototype to simulate some of this behavior. The team should label those boundaries when evaluating it. A mocked payment response is useful for discussing a flow; it cannot establish that the real integration reconciles correctly.
I also want to know whether someone can explain the code that performs the important actions. If a generated change appears to fix a symptom, inspect why it works and what else it changes. Passing the demonstration by avoiding the troublesome path is a creative direction best reserved for the demonstration.
Tests should focus on meaningful behavior. For the booking example, verify that two customers cannot obtain the same final slot, unauthorized access is rejected and a retry doesn’t create another chargeable operation.
Related read: The AI demo answered beautifully. Now try the awkward questions.
If the product itself uses AI, add evaluations for its uncertain behavior as well. A deterministic validation test and an assessment of whether a generated summary preserves the facts answer different questions.
Finally, establish operational ownership. Someone needs to deploy updates, observe failures, restore data when necessary and support the people using the system. A repository and an enthusiastic handover message do not perform those jobs.
None of this takes away the value of the prototype. It can reveal the right interaction, expose a missing requirement and make a difficult conversation much easier.
Treat it as evidence about the idea. Then make the production decision using evidence about the system. The green tick can remain, once we know exactly what it is celebrating.