Hold the Spike to One Clear Hunk

A late review opened a ninety-minute spike branch and found a green suite beside a renamed helper. The original assertion had been rewritten into a softer check, and the diff touched three modules that never failed. The clock had already expired, so the team could not tell whether the assistant had repaired the defect or merely hidden it. That evening the branch was deleted, and the next spike received one narrower rule about clarity.

The rule treats a spike as a timed experiment with one hypothesis and a ship-or-kill verdict. Success means the original assertion passes again while the diff stays inside the file that owns that assertion. Failure includes any green suite produced by renames, broad reformatting, or a weaker replacement for the check. A recent developer discussion separates clean code from clear code, and this spike turns that distinction into a timer.

The fixture begins as a tiny billing helper that hides one off-by-one defect inside a boundary calculation. The failing test names the expected total and refuses to accept any nearby substitute value at all. Before the assistant starts, the operator copies the repository into a disposable worktree and records the hypothesis. That file is the only brief the assistant receives, aside from the exact test command and the time limit.

The artifact below is a proposed harness, and it is not a recorded benchmark from any named model. It creates the fixture, plants the defect, and later scores the diff against the original assertion text. Operators should run it on a machine they control and should treat every timing number as local evidence only. Nothing in the script claims a token quota, a hardware shape, or any permanent free-tier promise.

mkdir -p /tmp/clear-hunk-spike && cd /tmp/clear-hunk-spike
git init -b main
git config user.email "[e-mail]"
git config user.name "Spike Operator"
mkdir -p billing tests
printf '%s\n' 'Restore tests/test_invoice.py::test_quarter_keeps_the_fourth_week within 90 minutes.' 'Do not rename symbols, reformat unrelated lines, or edit the assertion text.' 'Ship only if that exact assertion passes and the diff stays in billing/invoice.py.' > HYPOTHESIS.txt

# billing/invoice.py — proposed fixture, unexecuted until an operator runs it
def quarter_total(cents_by_week):
    # Defect: the slice drops the last week, so a four-week quarter undercounts.
    window = cents_by_week[:3]
    return sum(window)

# tests/test_invoice.py — pin this text before the clock starts
from billing.invoice import quarter_total

def test_quarter_keeps_the_fourth_week():
    assert quarter_total([100, 200, 300, 400]) == 1000

# score_spike.py — proposed scorer; label: unexecuted example
import subprocess
from pathlib import Path

ROOT = Path(".").resolve()
ASSERTION = "assert quarter_total([100, 200, 300, 400]) == 1000"
OWNED = "billing/invoice.py"

def git(*args):
    return subprocess.check_output(["git", *args], cwd=ROOT, text=True)

def main():
    test = subprocess.run(
        ["python", "-m", "pytest", "-q", "tests/test_invoice.py"],
        cwd=ROOT,
    )
    names = git("diff", "--name-only", "HEAD")
    changed = [line for line in names.splitlines() if line.strip()]
    stat = git("diff", "--numstat", "HEAD")
    added = deleted = 0
    for line in stat.splitlines():
        parts = line.split()
        if len(parts) >= 2 and parts[0].isdigit() and parts[1].isdigit():
            added += int(parts[0])
            deleted += int(parts[1])
    assertion_intact = ASSERTION in Path("tests/test_invoice.py").read_text()
    local_diff = changed == [OWNED]
    small_enough = added + deleted <= 12
    passed = test.returncode == 0
    ship = passed and assertion_intact and local_diff and small_enough
    print(f"passed={passed} assertion_intact={assertion_intact}")
    print(f"changed={changed} churn={added + deleted} ship={ship}")
    raise SystemExit(0 if ship else 2)

if __name__ == "__main__":
    main()

# Commit the red fixture first, then start the ninety-minute clock.
git add billing tests HYPOTHESIS.txt && git commit -m "seed one boundary defect"
python -m pytest -q tests/test_invoice.py   # expect a failure before any assistant edit
# After the assistant stops, score once from the worktree root.
git diff --numstat HEAD
python score_spike.py
# exit 0 means ship; exit 2 means kill the branch and keep the score lines

The scorer refuses to congratulate a passing run when the assertion text has moved. A renamed function can make a new test pass while the original defect remains available to production callers. A reformatted file can also hide a one-line repair inside a noisy diff that a reviewer cannot audit before the next meeting. The twelve-line churn ceiling is a local budget for this fixture, not a universal law for every repository.

The ninety-minute bound is enforced outside the assistant, with a wall clock the operator can see. When the timer ends, the scorer runs once and the branch is either kept or deleted. A second attempt on the same worktree would mix warmup effects with the repair, so a fresh worktree is required for any repeat. The hypothesis file stays unchanged during the run, because editing the question after the answer arrives turns the spike into a story.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode enters this method only as one possible assistant that can be pointed at the worktree, using the operator-supplied free model access and free server option. The free server is useful here because the disposable worktree, the test process, and the scorer can live away from the laptop that holds unrelated client code. Free model access matters only so the spike can start without a separate procurement step, and current limits should be read from the product documentation on the day of the run.

The approach fails when the defect is not local to one file. A migration, a generated client, or a cross-service contract will violate the owned-file rule before the assistant has a fair chance. It also fails when the team wants exploratory redesign rather than a yes-or-no repair, because the scorer will kill ambitious cleanups that might still be valuable later. Operators who cannot spare a clean git history, or who need a measured comparison across many models, should not treat one ninety-minute branch as evidence of general quality.

Teams that already know the failing line and only want a narrative explanation should skip the harness as well. The script does not grade prose, security review, or performance, and it will ship a tiny wrong abstraction if that abstraction happens to satisfy the pinned assertion inside the churn budget. A kill result is also not proof that the assistant cannot code, since a clock, a fixture bug, or a missing dependency can end the run before any patch appears.

A practical close is to keep the killed branch’s score output next to the hypothesis file in the notes, then start the next spike from a new worktree. Readers who want to try the same boundary with MonkeyCode can point a free-server session at this fixture and keep the scorer outside the assistant’s instructions. The useful result is not a slogan about cleanliness, but a branch that either shows one clear hunk or disappears before it wastes a review.