loading…

Tracer Bullets

Ship the smallest end-to-end slice first — one thin path through every layer — then thicken. Term from The Pragmatic Programmer; matt pocock repurposes it as the main defense against AI slop: agents produce volume, so constrain each ticket to a verifiable slice. [source: aihero-dev-homepage-2026]

ticket = slice-through-all-layers (UI stub -> data -> back)
verify = demo the slice end-to-end
then   -> thicken, one layer at a time

Why it beats big-bang with agents

• Reality referees early: integration lies surface on slice one, not week three (richard feynman: “nature cannot be fooled” — production either).
• Each slice has crisp success criteria → enables karpathy four guidelines #4 goal-driven looping.
• Review load stays human-sized; slop can’t hide in a 4,000-line diff.

In practice

Decompose specifications into tracer-bullet tickets with explicit blocking edges; each implementation phase builds one slice via tdd with agents. See idea to ship flow. “What I cannot create, I do not understand” — Feynman’s dictum; the tracer bullet is the created-therefore-understood proof, per ticket.

Failure Modes

Symptom	Root cause	Fix
Slice never reaches production	“Thin” interpreted as UI-only, skipping data layer	Slice must touch every layer, even with stubs
Slices sprawl into mini-projects	No verifiable done-criteria per slice	Each slice gets one observable success check before the next starts
Agent gold-plates slice one	No explicit scope fence	Constrain the ticket: “only the slice; do not extend” (karpathy four guidelines)

Rule of Thumb

If a ticket cannot be demoed end-to-end in one sitting, it is not a tracer bullet - split it. The demo IS the verification.

Related

idea to ship flow, tdd with agents, karpathy four guidelines, richard feynman.