Do disposable interactive prototypes improve agent-built product decisions?
Do disposable interactive prototypes improve agent-built product decisions?
Question and origin. Dru said in a September 30, 2026 discussion that agents can anchor on an early implementation; he wants real, early user interaction but often would throw away discovery code or prototype outside the future implementation environment. This note tests preserving observations while declining to inherit architecture. See planning and tracking and feature-to-outcome.
What a good answer looks like. A primary same-team trace or comparative study: interactive prototype and observed user feedback; explicit disposition of prototype code; changed acceptance/design decisions; production implementation with agent involvement; quality, schedule and later repair. Do not treat advocates’ advice to discard prototypes as comparative proof or visual-ideation fixation studies as coding-agent evidence.
Subquestions and findings, September 30. (1) Discovery → agent implementation? A first-person Hacker News comment by interleave specifies a reproducible sequence: spike branch → agent-built prototype → markdown specification → discard prototype code → agent-supported XP/TDD implementation from main → review and ship. This is an anonymous workflow description; no identified product, actual customer feedback, code artifacts, post-ship quality or comparative outcome. Developer Aaron Brethorst’s own account argues cheap working prototypes put ideas before potential users and lower the cost of discarding failed ideas; for ideas that survive, he suggests refactoring/hardening. It reports no individual completed feedback-to-release trace. (2) Discard versus evolve comparison? None found in targeted searches; the evidence here is operating claims, not a measured design-fixation or maintained-quality contrast. (3) Preserve with boundary? Linear’s designer distinguishes concept choice from execution; throwaway code is one permitted sketch medium, not a blanket requirement. Brethorst acknowledges security, schema and error-handling gaps in prototype code, but provides no audited hardening case. (4) What persists? The HN author preserves a markdown spec, but not an inspectable user observation or rejected alternative. Linear argues goal, context and chosen concept should precede implementation. Even a clean code discard could carry an old solution through a frozen spec: compare concept alternatives and revise acceptance criteria from actual user interaction before delegating implementation.
Short primary-source list. Karri Saarinen, Linear, December 19, 2025; Brethorst, October 20, 2025; interleave’s first-person HN workflow. Faire reports plan-to-implementation, not user discovery feedback. The controlled AI-image ideation experiment is indirect.
Missing and next test. Same product, two approaches or clearly documented decision record: number of ideas actually shown to users, changed concept after prototype, proportion of code/architecture reused, spec changes, human planning/review minutes, maintenance events. In particular, ask whether the markdown spec encodes the prototype’s premature solution despite deleting its code.