You review AI patches every day. You never reviewed the tool that wrote them. The fix is a time-boxed spike. One hypothesis. Ninety minutes. Ship-or-kill evidence. That is the whole method.
The Evaluation Trap
Teams evaluate AI coding tools for weeks. They compare leaderboards. They read benchmark posts. They never ship.
Open-ended evaluation produces open-ended conclusions. "It seems good" is not evidence. "It works for some tasks" is not a decision.
A spike replaces vibes with a deadline. You test one hypothesis. You record one decision. Then you move on.
What Is a Ship-or-Kill Spike?
A spike is a time-boxed experiment. It answers one question. Should this tool touch this task class?
SHIP means the tool earns a place in your workflow. KILL means you drop it for this class.
The budget is fixed. Ninety minutes. No extensions. No "one more try."
The timer is the discipline. Without it, evaluation drifts into procrastination. Constraint forces a decision.
Write the Hypothesis First
A good hypothesis has three parts. Task. Tool. Review budget.
Example: "My chosen tool can implement a paginated REST endpoint with tests, and I can review the diff in under 30 minutes."
Write it down before you start. If you cannot write it, you are not ready to spike. The hypothesis defines what evidence you will accept.
Pick the Right Task
Choose a task you already understand. If you cannot review the output, you cannot judge it.
Choose a task with a testable result. "Refactor this module" is vague. "Add pagination to /orders with tests" is testable.
Avoid your hardest task. The spike tests a workflow. It does not test a miracle.
The 90-Minute Runbook
This is a template. Adjust it to your stack. The commands are illustrative, not executed on a specific project.
#!/usr/bin/env bash
# spike.sh — 90-minute ship-or-kill runbook (template)
set -euo pipefail
SPIKE_DIR="spike-$(date +%Y%m%d)"
mkdir -p "$SPIKE_DIR" && cd "$SPIKE_DIR"
echo "Minute 0-10: copy one real task from your backlog into TASK.md"
echo "Minute 10-40: open the repo in your AI coding tool, paste TASK.md, request a patch"
echo "Minute 40-70: inspect and test"
git diff --stat
git diff | wc -l
npm test # or: pytest / go test ./... / cargo test
echo "Minute 70-90: read every changed line, then decide"
Three checkpoints keep the spike honest.
- Minute 10: the task is in TASK.md. The timer is running.
- Minute 40: the patch exists. No patch means a stalled attempt. Record it.
- Minute 70: tests ran. Review started. No skimming.
The Decision Table
Collect evidence. Then apply the table.
| Evidence collected | Decision |
|---|---|
| Tests pass, diff reviewed under 30 min, no unexplained lines | SHIP for this task class |
| Tests pass, but review took 60+ minutes | KILL — review cost beats hand-writing |
| Two attempts failed the same test | KILL — record the failure mode |
| Tool stalled or refused twice | KILL — not ready for this class |
Mixed evidence is a kill signal. A tool that half-works costs more than a tool that fails cleanly.
Record the Evidence
Write the decision down. One paragraph. What passed. What failed. What you would change.
Future you will forget. Future you will re-evaluate the same tool. The note prevents that.
Why Free Access Changes the Spike
A spike dies when setup costs money. Token bills and GPU provisioning are friction. Both kill the 90-minute budget.
MonkeyCode is an open source project. It offers free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The free model access includes a 10-million-token quota. I did not benchmark it. I did not verify its limits.
The point is structural. A zero-cost target removes the last excuse for skipping the spike. The free server removes the "where do I run it" question.
Verify current availability on the project page before you start. Free tiers change. Blog posts age. Your spike should test the tool. It should not test a stale claim.
What the Spike Does Not Prove
One task is not a benchmark. A passing spike says nothing about refactoring. It says nothing about debugging. It says nothing about multi-file migrations.
Ninety minutes is too short for integration-heavy work. If your task needs a database migration plus auth plus UI, split it. Spike one slice.
The free server is for spikes, not production. Do not build a business on a free tier. Do not assume permanence.
Who Should Not Use This
Skip the spike if you already run a proper evaluation harness. You have better evidence.
Skip it if you are mid-migration. You need a plan, not a go/no-go.
Skip it if you need throughput numbers. The spike gives a decision. It does not give a metric.
The One Rule
When the timer hits zero, you decide. SHIP or KILL. No third option.
If the evidence is mixed, kill it. You can always spike again next month. The codebase will still be there.
Try It
Pick a real task. Write the hypothesis. Start the timer.
If you want a zero-cost target for your first spike, MonkeyCode's free model access and free server option are live. Verify the details on the project page, then run the runbook.
Either way, you leave with evidence. That is the point.
Top comments (0)