How to Run a Spike

Discussing a simple question for an inordinate amount of hours is a time-honoured bit of dev culture.

A simple question will easily eat an afternoon. Architecture, a library, whether to abstract more. Everyone's opinion comes out. It's rare that someone would pull the code out mid-meeting. Rarer still that a test would be run. These kinds of meetings are more entertainment than business. Business gets to the point.

A spike is that. Somewhat rude. We'll stop the conversation, now. This is the time you'll get (a day or two usually does the job), go look, bring me proof. That is why some people hate them: they end the meeting, they leave opinions unsaid - demanding facts instead. That is why some people love coming next standup with "research" and still no decision: they kept the meeting mentality and pushed the problem down the line.

Talk's standing in for full-contact. The spike was invented to kill that. If you still need four hours of discussion and another spike, you have not started. You have scheduled the argument twice.

Before you open an editor

Most spikes die at the handoff, not at the keyboard. Someone says "look into it," everyone nods, and nobody said what an answer would look like. So one never shows up.

Settle four things first:

The question, phrased so it can be answered. "Should we use Kafka?" is a mood. "Can Kafka keep per-customer ordering at our peak volume?" is a question. Yes, no, or which one - if none of those fits, keep rewriting it.

Who decides. Often not the person running the spike. They bring the proof; someone else owns the call. Say who, out loud, before anyone starts.

The clock. A day or two, agreed now, with an end date. When it runs out you report what you have. "We couldn't tell in two days" is an answer (and usually means the question was wrong).

What you're allowed to skip. Tests, error handling, naming, config. The code is a means to the answer. It gets thrown away, so don't dress it up.

While you're in it

The test must be ugly and short. When the time is up, there must be a decision. Build, don't, or the question was wrong. If the interesting part is the code you wrote, you are already building. Don't do that.

Try the option you expect to lose. Write down dead ends as you hit them, one line each - by Friday you'll have forgotten why the second library didn't work, and that line is half your presentation.

The presentation

Go through three simple things:

The stated question (or problem). Declare it, clearly for the room, we're all solving the same problem.

What we will do. Your decision, with proof - what you've found in code, what you've run tests to verify. It's okay to bring more than one option, if all of them are proven, and if you've eliminated more options than you've brought. Make the decision easy to make.

What didn't work. You're not doing spikes correctly if you're not branching out. Show me what broke, what failed, what didn't do the job. If your only attempt was the winning one... you didn't try hard enough.

Copy this, fill it in, paste it wherever your team argues:

# SPIKE: <question - answerable with yes / no / which>

- **Runs it:** <name>
- **Decides:** <name>
- **Timebox:** <1-2 days>, ends <date>
- **Skipping:** <tests, error handling, naming, config>

## QUESTION

<One paragraph. The problem, restated so the room agrees it's the same
one. Why it matters now, and what it blocks if nobody answers it.>

## DECISION

<One paragraph. What we'll do, and why this option over the others.
If you're bringing more than one proven option, say which you'd pick
and what the trade-off is, so the call is easy to make.>

## PROOF

<What you ran and what it showed. Commands, test results, numbers,
links to the throwaway branch. Enough that someone who wasn't there
can check it without asking you.>

## REVISIT IF

<What would change the decision. A volume, a cost, a customer need,
a new version - something you'd notice when it happens.>

## WHAT DIDN'T WORK

### <Attempt 1>

<One paragraph. What you tried, what broke or fell
short, and why that rules it out (or only rules it out for now).>

### <Attempt 2>

<One paragraph. Same again. If this section is empty, you didn't branch out.>

What one looks like

People kept asking me whether their product needed an MCP server so AI agents could use it. I had a hunch, and the benchmarks didn't settle it (one I nearly cited pitted typed tools against an undocumented endpoint and called it a fair fight).

So, one question: does a curated MCP server beat a well-documented REST API at getting agents to finish real tasks? I published my guess before running anything. Same app behind both, seventy agent runs across five models, and a database check after every run instead of taking the agent's word for it.

What didn't work: my first MCP server was wrong - a sidecar calling the API over HTTP, which would have benchmarked my own plumbing. Thrown out before the real run. Then the first pass scored 66 of 70, and three of the four misses were my task setup, not the agents. Both are in the writeup, with the original score left visible.

The decision: a tie. Keep the improved API, don't build MCP expecting better results, add it when a real distribution or auth need shows up. It ended the argument, and left behind a harness I can rerun. Full writeup if you want the meat.

Answer the three, do it within a day or two, bring receipts. That's the spike, in its simplistic beauty.

P.S. On fitting in LLMs

Steal this as a skill. Drop the template into your agent's rules, or just send it this link - an LLM should speak your spike language too.

It's genuinely good at the grunt part. Scaffolding the throwaway, writing the harness, running the same check forty times, reading the logs so you don't have to. In the MCP spike, agents did the seventy runs. I did not type curl seventy times.

It's bad at the two parts that make it a spike: choosing the question and making the call. It will also happily hand you a confident document with a clean winner and a tidy "what didn't work" section full of things it never tried. Check that the failures actually happened.

That said, don't delegate your thinking to the LLM - do the actual research. If the model wrote the presentation and you can't defend it in the room, you didn't run a spike. You made some slop.