Engineer production-ready code with AI using proven practices

Prototype builds throwaway code whose sole job is answering one question, with the question deciding the shape. Two branches: "does this logic or state model feel right?" gets a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper; "what should this look like?" gets several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar. Getting the branch wrong wastes the whole prototype, so if the question is genuinely ambiguous and the user isn't reachable, it defaults by what the surrounding code is - a backend module gets the logic branch, a page or component gets the UI branch - and states that assumption at the top of the prototype.

Use it to flesh out a design before committing to it: a runnable terminal app for state or business-logic questions, or several radically different UI variations toggleable from one route. Both branches share the same discipline: throwaway from day one and clearly marked as such, located next to the module or page it's prototyping so context is obvious, runnable with a single command matching the project's existing task runner, no persistence by default (state lives in memory since persistence is what's being checked, not depended on - a database question gets a scratch DB or a file explicitly named as disposable), and no polish: no tests, no abstractions, only the error handling needed to keep it runnable.

Every action in the logic branch or every variant switch in the UI branch must surface the full relevant state by printing or rendering it, so the user can see exactly what changed. When the prototype has answered its question, it gets deleted or the validated decision gets folded into real code - it should never be left rotting in the repo.

LOGIC.md -> tiny terminal app, state machine, print state after every action
UI.md    -> radically different variations, one route, URL param switch

UI-branch prototypes obey whatever routing convention the project already uses rather than inventing a new top-level structure; logic-branch prototypes run via the project's existing task runner (pnpm, python, bun, or equivalent).

Developers who need a fast, disposable way to validate a state model or compare UI directions before writing production code - and who capture only the answer, not the scaffolding, in a commit message, ADR, issue, or a NOTES.md next to the prototype before deleting it.