The demo works. What happens on the second try?

You book the last place in your workshop, see a confirmation and congratulate the AI on a tidy little booking tool. When you press the button again, a second confirmation arrives for a seat that no longer exists.

This is a hypothetical software example, not a test result from a named model or a JustHandled product. A maker asked a coding assistant for a simple booking page. The demonstration covered one customer, one click and one successful response. That looked convincing because it followed the route everyone wanted to work.

The second click asks a different question: what does the system do when a normal person is impatient, uncertain or simply trying to find out whether their first attempt worked?

Describe the promise before you test the page

For the workshop owner, the promise is that each available place can be booked once and each customer can tell whether their booking succeeded. To keep that promise, the saved record, confirmation and response to a retry have to agree with what the page tells the customer.

Write that down before asking the assistant to test its work. A useful request would be: “Show me one successful booking, then try the same request twice. There should be one booking record and one place used. If a response is lost, explain how the customer can find out whether the booking succeeded without creating another.”

The implementation may use a stable request identifier, an authoritative availability check or another appropriate design. Ask the assistant to explain its choice and demonstrate how it behaves when two people compete for the same remaining place; that gives you a basis for reviewing the mechanism.

Give the demonstration an awkward afternoon

Start with the ordinary situations that challenge the promise: a customer who clicks twice, or two people trying for the final place at the same time. Then try losing the response after a booking saves, so the customer has to decide whether to reload or start again. A missing field and a slow confirmation can tell you a surprising amount about how the tool handles uncertainty.

For each situation, ask what the customer sees and what the system actually records. A disabled button might prevent a quick double-click on that screen, yet a repeated request from another tab could still create a duplicate. If a friendly error message appears after the booking has already saved, the customer may reasonably try again. Following that attempt into the saved record gives you a better view of the problem than inspecting the button alone.

Keep the test tied to the consequences. A private color-picker experiment can tolerate rough edges that a booking system can’t. Once software changes availability, sends messages or accepts a payment, the evidence should cover those actions and what happens when they only partly complete.

Give another reviewer something to investigate

Mark Seemann’s October 12 essay on releasing AI-generated software discusses the limits of verification by humans and AI. His discussion raises questions about what a review can establish and where its limits remain. It also notes that the earlier stance attributed to Robert C. Martin had changed, so “a famous programmer no longer reads code” would be a poor foundation for your release decision.

If you ask another agent to inspect the booking tool, give it the promise and the awkward cases. Ask it to “try to create two bookings for the last place and show the saved records,” so you can inspect what it attempted and what happened.

A Vals AI comparison of individual agents and teams found that results depended on the model, reasoning effort and task, with additional costs for teams. Its full-stack application benchmark doesn’t establish that another agent will make your particular tool safe. For this booking tool, give each reviewer a separate case to investigate and collect the records behind their conclusions.

Leave yourself a way back

Before putting the tool in front of customers, preserve the working version and decide how to stop new bookings if something goes wrong. Keep enough information to reconcile a disputed confirmation with the underlying record. Use test customers and test data while checking messages or transactions so a trial doesn’t become an accidental real booking.

For the maker, the second click’s now become part of the release demonstration. The assistant repeats the request, shows one saved record and explains what a customer should do after an uncertain response. If that evidence is missing, the tool needs another pass before customers depend on it.

When a customer gets nervous and presses again, the owner’ll need to find their booking and explain what happened. Keep that moment in the demonstration, right through to the record that lets someone answer the phone.