Pragmatic spikes to retire risk

In Agile and Extreme Programming, a spike is a short, time-boxed probe. Teams run one to buy certainty when a hard unknown blocks a design choice or effort size.

Without strict focus, agents either polish a prototype into half-baked app code or write a long essay that retires zero risk. A good spike picks the cheapest method that yields hard proof, stays inside a tight scope box, and stops the moment it answers the blocking question.

🧭 Agile spike types & right-sized methods

Agile splits spikes into two camps. Technical Spikes test how or whether a mechanism works, while Functional Spikes clarify what the workflow, edge-case rule, or contract must be. Smart teams don't write code when a faster check settles the question:

Spike type & unknown	Fastest method	Hard proof produced
Technical: External API, quota, license, or wire behavior	Spec, contract, or upstream source audit to read RFCs, vendor limits, pricing tiers, or library source code directly.	Exact spec clauses, rate ceilings, or upstream source links.
Technical: Legacy coupling, migration cost, or blast radius	System seam & call-graph trace to map callers, state changes, and schema borders in the project.	Caller map, breaking-change list, and clean seam points.
Technical: Runtime speed, memory cap, or SDK fit	Throwaway code or benchmark probe that runs a small script or test in `/tmp` or scratch space.	Measured timings, memory peaks, exit codes, or live traces.
Functional: Unclear domain rules, edge cases, or state flows	Scenario & state-table walk-through to map real inputs, failure modes, and conflict rules in a table.	Decision table, edge-case matrix, and clear rule contract.