Find Out It's a Bad Idea in an Hour, Not a Week

Most features have one genuinely uncertain technical question buried inside an otherwise familiar shape. Explicitly naming it — instead of vaguely feeling unsure about the whole feature — is what lets you target a spike precisely instead of over-building a throwaway prototype.

The discipline of a spike is deliberately skipping everything not needed to answer the risky question — no UI polish, no auth, no persistence, unless the question is specifically about one of those. Confusing a spike with a first draft of the real feature defeats its purpose.

Validate the Risky Part First. A spike is a small, throwaway piece of code built to answer one specific technical question fast — not to ship. Before committing real time to a feature, use AI-assisted speed to spike the riskiest unknown first, so you find out it's a bad idea in an hour, not a week.

Name the Riskiest Unknown Before Writing Any Code. Before prototyping, articulate exactly what technical question is actually uncertain. Ask the model to help you identify it for a concrete feature idea.

What makes something worth spiking, versus just building directly?

• →Genuine technical uncertainty where being wrong would be expensive to discover after the feature is mostly built — that's exactly when a small, throwaway spike pays for itself.
• →Any feature that will take more than a day to build, regardless of how confident you are in the approach.

Build a Throwaway Spike, Fast. Use the AI tool to build the smallest possible piece of code that answers the risky question — not a polished feature, just a proof that the hard part works (or doesn't).

Throw the Spike Away — Keep the Answer. The spike's code is disposable. What you keep is the answer: does the risky approach actually work, and roughly how hard was it. That answer is what makes your next mini-PRD and real build far more confident. Next: reviewing AI-generated code with the same rigor you'd apply to a teammate's pull request.