I watched a PM hand off an AI-built prototype last month and call it done by lunch. The flow looked clean on his screen. Then the first user tried it on a train with one hand and no signal, and the whole thing stopped making sense after the second tap.
That gap never shows up in the deck. It only appears once someone actually needs the thing to work without you in the room.
I stopped writing specs after that.
Explore: Making the Delivery Medium Part of the Prototype
The explore prototype that surfaced the print step problem began with a single prompt to generate a children’s ministry lesson builder. The first version rendered cleanly on screen and passed internal review. When the same flow was printed for a volunteer who only had the sheet in front of her, the required checkbox sequence disappeared and the activity list ran past the bottom margin. That single failure forced the next three iterations to treat print as a first-class output instead of an afterthought. The lesson was not that the agent was wrong; it was that the explore step had not yet included the actual delivery medium.
Expand: Testing the Narrow Loop Under Real Use
How expand changed the volunteer scheduling loop came next. After the print issue was visible, the team expanded the prototype to include a weekly availability calendar that updated in real time. Early versions assumed every volunteer would check the app daily. Real use showed that most only opened it once on Thursday night. The expanded version therefore added an SMS reminder that carried the same state as the calendar, and the completion rate for sign-ups rose without any increase in push notifications. The expansion phase succeeded because it kept testing against the same narrow user action rather than adding features.
Extract: Locking In the Rule
The extract protocol that now lives in every new agent was written only after the expanded version had run for three live events. It consists of four checks that must pass before any generated code moves into the main repository: the flow must complete on paper, the flow must complete on a shared device without login, the error states must be reachable in under two taps, and the success metric must be recorded without an additional screen. The protocol is short because it was pulled directly from the failures observed in the earlier stages, not from a general style guide.
Your Turn: Apply This Today
- Choose one three-step task inside your current product that volunteers or end users complete without training and prompt an AI coding agent to generate a working prototype of just those three steps.
- Print the resulting screen or flow, hand it to one person who matches your target user, and time how long it takes them to finish without asking questions.
- Note the exact point where the prototype broke or required explanation, then write a single-sentence adjustment before you generate the next version.
- Run the revised prototype through the same print-and-time test with a different user the next day and record whether the completion time dropped.
- Extract the one rule that would have prevented the first failure and add it to a short checklist you apply to every new agent-generated file this month.
- At the end of the week, compare the original prototype against the version that passed two real-user tests and delete any code that did not survive the cycle.
The same explore-expand-extract discipline appears in both “The Trust Step Kent Beck Made Non-Negotiable” and “Why Top PMs Still Route Specs Through Sunday Validation”, where the cost of skipping the first stage shows up in later rework rather than in initial velocity.
I consult with product leaders building ministry tools on prototyping workflows, volunteer adoption metrics, and agent-assisted development. Let’s talk.