Prototype to specify, not to deliver
When prototypes are cheap, they substitute for specifications and surface requirements ambiguities specifications would not.
The bottleneck in mid-tier AI delivery used to be engineering. Building a working version of anything took specialists, time and a budget; specifications had to be precise because the cost of getting them wrong was the cost of building the wrong thing twice. Prototyping was a delivery activity that happened after the requirements were settled.
That sequence has inverted. With current AI tools, a working prototype can be produced in fifteen to thirty minutes from a verbal brief or an email — see AI interfaces are generated on demand rather than fixed by design for the broader capability shift. The cost of a prototype has fallen below the cost of a specification document. The prototype is no longer a step toward delivery; it is a way to surface what the specification needs to say.
The tactic is concrete. When a stakeholder describes a system they want — a timesheet assistant, a knowledge-base retrieval skill, a billing summary — build a working version of it in the meeting, or before the next one. Show it to them. Watch what they say. The first reaction is almost never about the prototype’s correctness; it is about something the brief did not anticipate — a constraint, a boundary case, a cross-cutting concern, a workflow assumption. That reaction is the requirements work. The prototype’s value is to provoke it.
Two cautions apply.
The prototype is not the solution. It demonstrates feasibility and surfaces requirements; it does not yet reflect the production constraints — security, compliance, integration with existing systems, error handling — that production work has to accommodate. Stakeholders sometimes interpret a working prototype as evidence the work is done. The advisor’s job is to keep that interpretation off the table.
The prototype must be cheap or it does not work. If a prototype takes a week, it has reverted to being a delivery activity, and the requirements ambiguities it would surface have to be guessed at instead. The discipline is to keep the prototype to under an hour. Anything longer is a specification dressed as code.