The Pragmatic Programmer, Re-Read in the Age of AI Pair Programming
The Pragmatic Programmer, Re-Read in the Age of AI Pair Programming
I first read The Pragmatic Programmer in 2019, the year Hunt and Thomas released the 20th anniversary edition. At the time I treated it the way most developers treat classic texts: a checklist of good habits to absorb, nod at, and then promptly forget as deadlines hit. DRY. Orthogonality. Tracer bullets. The broken window theory. I underlined things. I felt smarter.
Then last winter I picked it up again — same book, different world. Eighteen months of daily work with Claude and Copilot sitting in my editor had fundamentally changed what I was looking at. Principles I’d thought were timeless suddenly felt complicated. Things I’d dismissed as dated turned out to be more urgent than ever. And a few assumptions baked into the book’s worldview had simply collapsed.
This is not a review. I’m not here to tell you whether to read it (you should). This is a reckoning — working through which parts of a 1999/2019 text survive contact with an AI pair programmer and which ones quietly require a rewrite.
Quick Context: What the Book Is
For the uninitiated: The Pragmatic Programmer by Andrew Hunt and David Thomas is one of the most-cited books in software engineering. It’s not about a specific language or framework. It’s about craft — how to think about your work, manage complexity, communicate with teammates, and avoid the mental traps that turn good developers into frustrated ones. The 20th anniversary edition updated examples and added new topics, but the core philosophy hasn’t changed. Hunt and Thomas believed in thoughtful, autonomous developers who take ownership of their work and resist the inertia of bad practices.
That philosophy is exactly what AI pair programming puts under pressure.
What Aged Perfectly (and Why That’s Interesting)
The Broken Window Theory Is Now a Fire Hazard
The book’s most memorable analogy: a building with one broken window attracts more vandalism because it signals that nobody cares. The software equivalent is tolerating bad code — a messy module, a duplicated function, a commented-out block nobody dares delete. One broken window invites ten more.
When I re-read this chapter, my immediate reaction was: this is worse now, not better.
AI coding assistants are remarkably good at pattern-matching to existing code. If your codebase has a broken window — say, an inconsistent error-handling pattern, or a naming convention that exists in 40% of files — Claude will faithfully reproduce that pattern when you ask it to generate new code. It’s not doing anything wrong. It’s learning from your context and giving you more of what it sees. The result is that bad patterns propagate faster than they ever could when all propagation required human keystrokes.
I had a codebase where I’d made a mistake early on: I was catching exceptions too broadly in a few API routes and swallowing errors silently. I knew it was wrong. I left it. Three months later, after heavy AI-assisted development, that pattern had spread to 60% of the codebase. Claude had treated the existing examples as the canonical approach and mirrored them every time I asked for a new route.
Hunt and Thomas were right about broken windows. They just couldn’t have known that AI would install industrial machinery to mass-produce them.
The corrective implication: code hygiene matters more now, not less. Clean up the windows immediately because your AI pair programmer is watching and taking notes.
“Your Knowledge Portfolio” Is the Most Urgent Chapter in the Book
There’s a chapter that uses the metaphor of an investment portfolio to describe how developers should manage their skills: invest regularly, diversify across technologies, balance risk, review and rebalance periodically.
In 2019 this felt like reasonable career advice. In 2026 it reads like a survival manual.
The half-life of specific technical knowledge has accelerated dramatically. The configuration syntax for a tool I learned eighteen months ago may now have a Claude-optimized abstraction layer on top. The framework patterns I internalized are being replaced by patterns that make sense specifically for AI-assisted development. The entire category of “write boilerplate” has been largely automated away, which means the skills that survive are the ones AI can’t replicate: judgment about architecture, the ability to debug strange emergent behavior, and — crucially — the ability to evaluate whether what the AI produced is actually correct.
The portfolio metaphor holds, but the asset classes have changed. Investing heavily in memorizing syntax is now a poor investment. Investing in understanding why architectural decisions matter, in the ability to read and evaluate code you didn’t write, in threat modeling and evaluation design — these are now the growth assets.
Tracer Bullets Still Work
This is one of my favorite concepts from the book and I was worried it wouldn’t survive the AI era. Tracer bullets: instead of building each layer of a system completely before moving to the next, fire a thin end-to-end path through the entire system first. Get something that runs from input to output, however incomplete, and then iterate on each layer.
It holds up completely. If anything, AI pair programming makes tracer bullets more valuable, not less.
Here’s why: LLMs are very good at filling in the middle of things and very bad at knowing when the overall structure is wrong. If you let an AI help you build an entire backend layer before testing it against the layer above, you can end up with beautifully generated code that doesn’t compose correctly with the rest of the system. The AI had no way to know — it only saw the slice you were working on.
Tracer bullet first, AI-generate each section second. The end-to-end path gives you the feedback the AI can’t get on its own.
Rubber Duck Debugging Has Become Rubber Duck AI
The technique: when stuck on a bug, explain your code out loud to a rubber duck. The act of articulating the problem forces you to examine assumptions you’d been taking for granted, and often you find the bug mid-sentence.
This practice is now a first-class workflow with Claude, and it works better than the rubber duck for one specific reason: the rubber duck can’t ask follow-up questions.
My current debugging pattern when stuck: open a fresh Claude conversation and explain the bug in natural language, including what I’ve tried and what I expected. Not paste the code and ask “what’s wrong.” Explain it, as if to a colleague who’s smart but doesn’t know my codebase. The act of constructing that explanation does exactly what rubber-duck debugging does. But then Claude asks a question — often the wrong question, but occasionally the right question that redirects my thinking.
Last month I spent two hours chasing a race condition in a webhook handler. I explained it to Claude. Claude asked whether the issue could be in event ordering rather than the handler logic itself. Wrong hypothesis — but the question made me look at the event broker configuration, which is where the bug actually was. I wouldn’t have gone there without the redirect.
The rubber duck got a brain upgrade. The technique is still valid. The tool changed.
What Needs an AI-Era Rewrite
DRY Is More Important at the Architecture Level, Less Obvious at the Code Level
Don’t Repeat Yourself is one of the book’s canonical principles. Every piece of knowledge should have a single, authoritative representation in a system. Duplication breeds inconsistency; when you update one copy of a piece of logic and forget the other, you have bugs.
The complication: AI pair programming makes code-level duplication significantly less painful. When I need similar logic in two places and both are AI-generated, the cognitive cost of generating it twice is near zero. And sometimes — often, actually — the logic is similar but not identical in ways that matter, and a premature abstraction would have papered over an important difference.
I’ve started thinking about DRY differently now: the principle applies with full force at the knowledge and architecture level (don’t encode business rules in multiple places, don’t have two sources of truth for configuration, don’t let schema definitions drift across services) but deserves more nuance at the implementation level where “repeated code” might be two nearly-identical things that will diverge.
Hunt and Thomas were arguing against the era of copy-paste programming where duplication happened because developers were lazy or under time pressure. AI pair programming hasn’t eliminated the risk of duplication — it’s moved it. The duplication now lives in AI-generated logic that looks consistent but represents different underlying concepts. That’s harder to spot and harder to fix.
The principle survives. The application requires more judgment.
“The Power of Plain Text” Is More Nuanced
The book makes a compelling case for storing data in plain text formats rather than binary formats where possible. Plain text is inspectable, versionable, editable with any tool, and doesn’t require specialized software to read. This was partly a reaction to proprietary binary formats that locked you into specific applications.
The principle is right, but the landscape has shifted in an interesting way: some of the most powerful AI-native interfaces aren’t plain text. When I work with vector embeddings, structured function call schemas, or binary model weights, the plain text ideal doesn’t cleanly apply. The code that generates those artifacts can and should be plain text. The artifacts themselves sometimes can’t be.
More practically: the book’s argument was that you should always be able to inspect what your tools are producing. That instinct is correct, and it’s now more important because AI tools can produce outputs you didn’t explicitly write. The question “can I see what’s actually in here?” has become critical for AI-generated artifacts like embeddings, fine-tuning datasets, and evaluation benchmarks. If those artifacts are opaque binary blobs, you lose the ability to audit them.
The spirit of the principle — prioritize formats and systems you can inspect and understand — remains essential. The specific guidance needs updating for a world where some of the most important data in your system is high-dimensional float arrays.
Orthogonality Under Pressure
Orthogonal systems: changing one component doesn’t cascade side effects into others. It’s one of the most important structural properties a codebase can have, and the book makes a strong case for it.
The risk in AI-assisted development is subtle: AI-generated code often introduces implicit coupling that isn’t visible at the call site. An AI might generate a function that solves your immediate problem but secretly depends on global state, or assumes a particular execution context, or has a side effect that only manifests under specific conditions. The function looks clean. The coupling is invisible.
I’ve started treating AI-generated code as an orthogonality audit target. Whenever Claude writes a function of more than about fifteen lines, I ask a specific question: what does this depend on that isn’t in the function signature? Often the answer is “nothing,” which is great. But often enough — especially for anything touching I/O, state management, or configuration — the answer surfaces an assumption I hadn’t spotted.
Orthogonality doesn’t require modification. It requires more vigilance because the failure mode changed: the violations are now in code you didn’t personally write and therefore have weaker intuition about.
What the Book Couldn’t Have Anticipated
The Author Is No Longer Only You
This is the deepest shift, and the book’s entire premise quietly assumes the opposite.
The Pragmatic Programmer is built on the idea of the individual craftsperson who owns their code. You decide to fix the broken window. You manage your knowledge portfolio. You choose to use tracer bullets. The “pragmatic programmer” is a fully autonomous agent who takes responsibility for the quality of what they produce.
When Claude wrote 40% of a module last month, who owns it? Technically: me. Practically: it’s complicated. I reviewed it. I approved it. I ship it. But I didn’t write it in the sense that I didn’t construct each line from my understanding of the problem. I read it, evaluated it, accepted it. That’s a different kind of ownership.
The book has no framework for this. It was written for a world where every line in the codebase passed through your fingers. The craft ethic it describes — the careful developer who takes pride in what they produce — needs updating for a world where production includes curation and evaluation of AI output.
What I’ve landed on personally: the standard of care doesn’t lower because the AI generated something. If anything, it’s higher, because AI-generated code carries risks that hand-written code doesn’t: confidently wrong implementations, subtle misapplications of patterns, and generated tests that test the wrong thing. The ownership has to be total even when the authorship is split.
The Meta-Skill: Evaluating Code You Didn’t Write
The book’s skill model focuses on writing: write clean code, write clear tests, write good commit messages. The implicit assumption is that your primary interface with code is authorship.
AI pair programming adds a second primary interface: evaluation. You now spend significant time reading and judging code you didn’t write, under time pressure, at a level of attention that’s genuinely difficult to sustain.
I’ve gotten burned by this. Not because I’m careless, but because reading code is hard in ways that are different from writing it. When you write a function, you know why each line is there. When you read a function Claude generated, you’re doing a different cognitive task: reconstructing intent from output, checking for edge cases, looking for assumptions you didn’t make explicit in the prompt.
The book doesn’t really address this. There’s a chapter on debugging (reading code to find problems) but it assumes you have context about the code you’re reading. With AI-generated code, you sometimes don’t — you have a description you gave to the AI and a result that may or may not match your intent perfectly.
This is the skill gap I see in teams moving to AI-assisted development: experienced developers who are strong writers of code but haven’t developed strong instincts as evaluators of code they didn’t author. The Pragmatic Programmer’s craft ethic applies here, but the book doesn’t give you the tools to develop this specific skill. You have to find that elsewhere.
“Good Enough” Software Has Been Weaponized
There’s a section in the book on making your software “good enough” — understanding when additional investment in quality yields diminishing returns for the use case. It’s practical advice against perfectionism, aimed at developers who polish endlessly and never ship.
AI pair programming has created a different pathology: shipping things that feel “good enough” because they were produced quickly and the generated code looks plausible. The speed of AI-assisted development compresses the time between “I should validate this” and “it’s already in production.”
The book’s advice was aimed at overthinkers. The AI era sometimes produces underexamination — not because developers are lazy, but because the generation step is so fast that the normal pause for reflection doesn’t happen. You ask, you get, you review briefly, you merge. That review step is doing much more work than it used to.
I’ve had to deliberately slow down at the review phase in ways that feel counterintuitive when the rest of the workflow is moving fast. The pragmatic programmer needs to know when to be slower than the tool, not just when to ship.
The Principle That Hasn’t Changed At All
Near the end of the book there’s a section called “Pride and Prejudice.” The argument: sign your work. Take responsibility for it. Don’t let it leave your hands unless you’re proud of it.
I expected to find this section quaint in the AI era. I was wrong.
If anything, “sign your work” is the correct ethical and practical framework for AI-assisted development. You’re the developer of record. You’re the one who committed it, reviewed it, and let it go. If there’s a bug, it’s your bug. If the logic is wrong, it’s your logic to own. The AI is not a co-author with shared responsibility — it’s a tool, and you’re the professional who chose how to use it.
This isn’t punitive. It’s clarifying. It means the standard of care for AI-assisted code has to be the same as the standard for hand-written code, because ultimately the accountability is in the same place.
Should You Read (or Re-Read) It?
Yes. With the following adjustments in mind:
Take the principles, not the specific practices. The book’s tooling examples are dated. The mindset is not. When it talks about using the right tool for the job, update your mental model of what “tools” now includes.
Read it as a corrective to AI-assisted sloppiness. If you’ve been working heavily with AI coding assistants, there’s a good chance you’ve picked up some habits that the book would diagnose as broken windows — coupling you didn’t notice, duplicated logic the AI reproduced, tests that pass but don’t cover the right cases. The book gives you the vocabulary to name those problems.
Don’t read it for validation. Some developers have started using AI tools as an excuse to skip the discipline the book describes. “The AI handles the boring parts.” Sometimes it does. Sometimes it generates boring parts that are wrong in ways you missed because you stopped paying attention. The book is a useful correction to that drift.
The Pragmatic Programmer is a book about professional craft in the face of complexity and pressure. Those forces haven’t changed. The complexity is higher. The pressure is higher. The tools are more powerful and more capable of creating new problems at speed. The craft still matters — possibly more than it ever did.
Related on Private Labs
- AI Engineering by Chip Huyen — Book Review
- The Lean Startup by Eric Ries — Review
- Mastering TMUX — Terminal Splitting for AI Multi-Agent Systems
More in Books.