Disposable Code on Purpose: Spikes and Scout Agents

Tier: Core · Workflow area: Feature development

Both exploit the fact that AI has collapsed the cost of writing code you intend to delete. The failure mode they guard against is also shared: disposable code leaking into production.

When to use

• •
  A design decision is blocked on "how would this actually feel/perform?" — spike it.
• •
  A task is risky or unestimatable (framework upgrade, gnarly refactor) and you want the sticky parts mapped before committing — scout it.
• •
  Estimation disputes: a 2-hour scout settles "is this a 2-day or 2-week task" arguments.

Skip it when the answer is already known, or when the "spike" is secretly the first draft of production code — that is pb-03's territory.

Prerequisites

• •
  A coding agent that can run commands and tests (scout), or any assistant (spike).
• •
  Git worktree or a branch you are comfortable deleting: git worktree add ../scout-sqla2 -b scout/sqla2.
• •
  A written question the disposable code must answer. No question, no spike.

The workflow

1. 1.

   Write the question and the expiry. In a scratch note: "Question: can our per-request session pattern survive SQLAlchemy 2.0's changes, and which modules fight back? Expiry: this branch dies Friday." The expiry is a real commitment — put deletion on your calendar.

2. 2.

   Launch with disposable framing. For a scout:

   Copy

   This is a throwaway scouting run - code quality does not matter and
   nothing will be merged. Attempt the SQLAlchemy 1.4 -> 2.0 upgrade on
   this branch. Work until tests pass or you get stuck. Keep a running
   log in SCOUT-LOG.md: every error class you hit, which modules needed
   changes, what pattern caused the most churn, and anything you could
   not resolve. The log is the deliverable, not the code.
   

   For a spike, the same framing with the design question: build the smallest end-to-end slice with option A (e.g., BullMQ queue), then option B (Redis streams), instrumented just enough to compare on the axes you named (ops burden, replay, latency).

3. 3.

   Let it struggle; read the log, not the diff. With scouts, resist reviewing code. You want the map: "23 files touched; Query.get() removal caused 60% of churn; the dynamic relationship in models/cart.py has no direct 2.0 equivalent — needs redesign."

4. 4.

   Extract the intelligence. Convert findings into real-plan inputs:

   Copy

   From SCOUT-LOG.md and your experience in this run, produce:
   1. An ordered task breakdown for the real migration, sized by observed churn.
   2. The 3 riskiest spots and why (cite files).
   3. What to do differently than you did (e.g., codemod the mechanical
      Query.get changes before any manual work).
   

   For spikes: write the decision memo yourself — the spike gives you evidence, you supply the judgment.

5. 5.

   Delete the branch. git worktree remove ../scout-sqla2 && git branch -D scout/sqla2. Keep only the log and the plan. If a fragment truly deserves to live, retype it into a real branch through normal review — retyping is the quality gate.

Tool variants

• Terminal agent (Claude Code, Codex CLI): best scout — it compiles, runs tests, and hits real errors autonomously in the worktree.
• Copilot coding agent (issue → PR): file the scout as an issue labeled "throwaway — do not merge"; read the PR as the log, close unmerged.
• Cursor / IDE agent for spikes: fastest inner loop for building two comparable slices; keep each option in its own scratch project.

Verification

• •
  The original written question has a written answer, with evidence (log excerpts, measured numbers, error inventories).
• •
  The scout-derived plan names specific files and patterns — generic plans mean the scout did not get deep enough; run it again with more time or a narrower target.
• •
  Spike comparisons measured the axes you declared up front, not the axes that happened to be easy.
• •
  The branch/worktree is actually gone.

Pitfalls

• The immortal spike. "It basically works, let's clean it up" ships unreviewed, untested design-by-accident. Retype or die.
• Scouting with production credentials. Throwaway agents get throwaway environments — never real databases, real API keys, or write access to shared infra.
• Judging the scout's code quality. Irrelevant by design; the only review target is the log.
• Unbounded scouts. Cap wall-clock time and scope; a scout that burns a day has answered "this is expensive" — stop it and take the answer.

Restricted-environment variant

Scouts need repo access, so client-restricted work limits you to sanctioned agents (Copilot Business agent mode, in-tenancy assistants) — run the identical workflow there. Without any sanctioned agent, scout manually with a timer: attempt the upgrade yourself for two focused hours, keeping the same SCOUT-LOG.md, and use a local model (Ollama) to explain each unfamiliar error. Spikes on non-client scratch code (synthetic schemas, public libraries) can use any tool — keep client identifiers and data out of the spike entirely.

Success criteria

• •
  A design decision or estimate changed because of evidence, not opinion.
• •
  The real migration/feature plan cites scout findings file-by-file.
• •
  Zero disposable code reached a production branch.
• •
  Total cost stayed under the cap you set (hours, tokens, or both).