Build to Learn, But Faster
The Pragmatic Programmer introduced me to tracer bullets. You fire in the dark not to hit the target, but to see where your shots land. You adjust. You fire again. Eventually you're on target.
The principle underneath: build to learn. Don't wait for perfect information before acting. The feedback loop is the method.
That principle hasn't changed. What changed is that the cost per shot collapsed.
The Economics Shifted
Classic tracer bullets require deliberation. Each shot costs something real: time to set up the experiment, time to interpret the result, and the cognitive load of holding the question in your head while you do it. That cost is why the advice was always "fire a few, carefully."
With AI, the cost per shot approaches zero. So you can fire fifty directions at once.
This isn't a metaphor. When I approach an unfamiliar system, I ask about every part of it simultaneously. What does this service do? What are its dependencies? What are the common failure modes? What does the test suite cover? Which endpoints are undocumented? The answers arrive in parallel, and a picture of the system assembles itself faster than any sequential investigation would have produced.
Sequential investigation has a hidden tax people underestimate: you have to decide what to ask next, and that decision is made with the least information you'll ever have. Firing broadly sidesteps the ordering problem entirely.
This is also the argument for building a first-90-days RAG when you join a team. Your early questions are tracer bullets: they reveal the system, the vocabulary, the undocumented dependencies, and the places where everyone answers from memory. Capture those questions and verified answers as retrieval material, and the investigation compounds instead of evaporating when onboarding ends.
Two Modes, and Knowing Which You Need
The same technique works in two quite different registers, and the skill is telling them apart.
Precise mode. You have a specific question with a specific answer. What does this function do at this edge case? What does this error actually mean? You want an exact answer and no elaboration.
"What does the
authenticate_userfunction do, specifically around token expiry? I want the exact condition where it returns None."
Expansive mode. You want to explore. What's in this codebase? What patterns exist? What has the team already tried? You want a map, and you're willing to accept that a map is directionally correct rather than perfectly accurate.
"Give me a map of this codebase. What are the main services, how do they talk to each other, and what are the pain points based on the commit history?"
Expansive mode is also how I learn a domain now:
"I need to understand MQTT. Give me the mental model: what is it, how does it work, what are the common failure modes, and what does a simple publisher/subscriber setup look like in Python?"
The failure mode is using the wrong one. Ask an expansive question when you needed precision and you get a plausible summary that papers over the exact detail you were chasing. Ask a precise question when you needed the map and you get a correct answer to a question that wasn't the important one.
There's a second failure mode worth naming: firing a lot of shots and treating each landing spot as fact. An expansive answer is a map, and maps are wrong in specific places. Before anything from a broad sweep becomes load-bearing, it needs checking, because one run against a stochastic model isn't evidence. Cheap shots are only an advantage if you stay honest about which ones you've actually verified.
Where this fits in the rest of the loop is the workflow post. Reconnaissance is the opening move, not the whole game.
What Hasn't Changed
The purpose of the tracer bullet is the same. You're still building to learn. You're still adjusting based on where the shots land.
What changed: the cost per shot, the number you can take, and how fast the target resolves.
What didn't: knowing when to fire and what to aim at. A minigun doesn't help if you're pointed at the wrong hill. It just gets you to the wrong conclusion faster and with more supporting evidence, which is arguably worse than being slow.
That judgment is still yours. It was always the expensive part.
Content on this blog was created using human and AI-assisted workflows described in my standards and workflow posts. Original ideas and editorial decisions by Justin Quaintance.