Spike Then Decide
Buys certainty about an unknown approach with a throwaway experiment on a fixed budget.
When to reach for it
When you and the agent are weighing two approaches and neither of you actually knows — an unfamiliar library, a new API, a performance question you cannot settle by reading.
What changes
- The agent names the single question the experiment must answer, so you can tell when it is finished.
- A budget is stated before the work starts, and the agent stops at it instead of sliding into building the real thing.
- Spike code is written in a throwaway file and deleted at the end, so it never quietly becomes production code.
- You end with a written answer and a decision, not a branch that half works.
- If the experiment settles nothing, the agent says so instead of picking a winner to look decisive.
Pairs with
- Dependency AuditDecides whether a library earns its place, or whether twenty lines of your own would do.
- Rewrite or RepairForces an honest answer to 'fix it or start over', costed in evidence rather than taste.
- Assumption CheckMakes the agent state what it is assuming — and verify it — before it writes a line.
Spike Then Decide
Use this when the right approach is genuinely unknown. The output is an answer, not a feature.
1. Write the question
One sentence, with a yes, a no, or a number in the answer. "Can this library render 5,000 rows without dropping frames on a laptop?" "Does this endpoint return the fields we need without a second call?"
If the question cannot be settled by running something, this is not a spike, it is research. Go read instead.
2. Set the budget before starting
State a limit out loud: a number of minutes, or a number of files touched. Say what happens when it runs out — usually "report what we learned and choose with incomplete information".
3. Build the ugliest thing that answers it
In a scratch file, outside the real app if possible. Hard-code everything. No error handling, no types, no tests, no care about naming. Every minute spent making the spike nice is a minute not spent learning.
4. Record the answer while it is fresh
Write down three things:
- The question, and the answer with its number or its yes/no.
- What surprised you.
- What the spike did not cover, so nobody assumes it did.
5. Delete the spike, then decide
Delete the code. Then state the decision and the reason in two sentences. If both options still look equal, say the spike was inconclusive and name what would settle it.
Rules
- Do not keep the spike. Code written under "no error handling, no types" is exactly the code you will regret shipping.
- Do not let the spike grow into the feature. If you are adding a second screen, the budget ran out a while ago.
- Do not skip the written question. A spike without one ends when you get bored, not when you know something.
- Do not report "it works". Report what worked, on what input, at what size, and what you never tried.