The Prototype Is The Spec Now

The written spec no longer settles an argument about what a feature should do. The prototype does, and treating that as a discipline problem to fix, instead of the new default to design around, is a mistake.

The Agile Manifesto put a version of this preference in writing twenty-five years ago: "working software over comprehensive documentation." The manifesto is careful to say the item on the right, documentation, still has value; it is a statement of priority under limited attention, not a claim that specs are worthless. What has changed since 2001 is how early "working" can now arrive. A round of artificial intelligence (AI)-assisted prototyping can produce something clickable in the time it used to take to draft the first paragraph of a requirements document, which moves the working-software side of that trade-off much earlier in a project than the manifesto's authors were describing.

Basecamp's Shape Up formalizes the same shift as a deliberate practice rather than an accident of tooling speed. Its "breadboarding" technique borrows a concept from electrical engineering: a breadboard prototype has all the components and wiring of a real device but no industrial design, so a team can debate whether to include a feature before anyone debates where the knob goes. Shape Up's method sketches three primitives only, places a person can navigate to, affordances they can act on, and connection lines between them, deliberately excluding visual layout so a room stays on structure instead of drifting into typography.

A concrete instance of a prototype substituting for a written brief shows up in a documented Precisely developer portal project: five separate application programming interface (API) demos (Reverse Geocode, GeoTAX, Emergency Info, Time Zone, and Wi-Fi) were consolidated onto one shared interactive evaluation pattern instead of five separate specs. The inspectable design path moved from eight setup steps to three in-portal steps, and AI-assisted front-end work let the pattern get tested in code quickly, though the case study is explicit that the clarity still had to come from the underlying product decisions, not from the tool. The scope was interaction and front-end design across the five demos; engineering owned production delivery and the API roadmap was not part of that scope.

The strongest reasonable counterargument to this thesis is that a prototype's silence can pass for a decision already made, and a documented boundary condition shows exactly how that happens in practice. A retrospective on my own Philips Cardiocare graduation project, a seven-month concept apprenticeship rather than a shipped product, names a specific instance of the same failure this article is otherwise making an argument against: the flow tracked health data across connected devices and ran an AI companion on personal medical information, and it shipped without a designed consent screen attached, no plain statement of what each data source was used for, no granular opt-in, no way out as easy as the way in. A clickable prototype had nothing to say about consent because consent was never built into the click path, and its absence from the demo read as a non-issue rather than as an open question. Business rules, compliance requirements, and data contracts share that property: a prototype's silence about them is not evidence they were considered.

What stays written, on purpose

• List every rule that only triggers at a scale, an edge case, or a regulatory boundary a demo cannot simulate, and write each one down as its own line item.
• Name consent, data retention, and compliance requirements explicitly in a document before the prototype ships, even if the prototype never renders them.
• Assign one owner for updating the written constraints whenever the prototype's scope changes, so the two artifacts do not quietly drift apart.
• Treat a prototype's silence on a topic as an open question to resolve, not as evidence the topic was already handled.