Architecture & design · Book notes
The Pragmatic Programmer and an agent that outruns its headlights
The Pragmatic Programmer's advice on small steps and fast feedback hits differently when an agent can write a whole feature before anything runs.
An agent can build an entire feature before anything is even run. If typing speed is no longer the limiting factor, what dictates the pace? This brings us to the old book The Pragmatic Programmer by David Thomas and Andrew Hunt, which keeps coming up in agent discussions.. specifically the 20th Anniversary Edition from 2019.
In the AI Engineer talk in April, Matt Pocock described how the agent can sometimes overreach, dumping lots of code and only then doing type checks or tests after. He called this “outrunning your headlights” (a phrase from the book) and put it as “the rate of feedback is your speed limit.” There’s a thread on r/ExperiencedDevs from spring asking if it’s still worth reading in 2026. Most of the replies were along the lines of yes, or at least learn its ideas.
The headlights thing is from the chapter on pragmatic paranoia. It says if you’re going faster than your headlights let you see the road, you’re in trouble. So take small deliberate steps and check the feedback before going further. The companion tip to that is “Only look ahead as far as you can see.” The small steps tip is new to the 2019 edition (about three quarters of the original text was changed). So the most-quoted rule in the agent talk is one of the youngest in a book first published in 1999.
Later chapters talk about tests in a similar way, describing them as a form of design feedback and the first user of your code, rather than a bug hunt. Pocock’s remedy for agents is test-driven development, so the agent gets a signal after every small step before moving on to the next one.
Not everyone found the book profound. Hacker News readers have long complained that the advice is obvious or Goldilocks advice (do enough, but not too much). Some say it only confirms lessons they learned the hard way. And perhaps that criticism is true for people. But Pocock counters that software agents by default are bad at taking small, deliberate steps, so even obvious advice must be built into them.
The agent discussion moved this idea from “personal habit” to “the tooling around the agent”. Ben Borgers writes without feedback loops, you’re the feedback loop. If the agent can’t test its own work, you end up being its QA. So give it the means to check itself (curl calls, browser automation), write a little, test a little.
My own setup gives me another perspective: I run several Claude Code sessions in parallel, and sometimes the relevant feedback comes from a different session. For example, one peer session raced two commands and lost the update in 60/60 runs. The very next Memento release included a lock and a race test that would have failed on the old code. I talk about this more in Running six to nine Claude Code sessions at once.
If feedback is the speed limit of your agent, who provides the headlights? Does the agent write its own tests? Do you run a second checking agent? Or is it a human approving the change before it ships?