fakenerd.ai

daily nerdingThe Pocock books

The Pocock books

Matt Pocock teaches developers to code with AI agents. His advice keeps pointing back to four classic software books. Here they are, idea by idea, in plain English, with what each one means now that an agent writes the code.

Jump to the forty ideas, where to start, or try it with your agent.

Eight signals

The whole page in eight boxes. Each one links to where it's explained.

  1. 01

    Fast code isn't cheap code

    Pocock's point: agents write code fast, but a codebase that's hard to change limits how much they can help. The fix is old-fashioned design.

    Show me
  2. 02

    Four books, one idea

    Keep software easy to change. Every idea on this page comes back to that.

    Show me
  3. 03

    The Pragmatic Programmer: habits

    How a good developer works day to day. Own it, fix small mess early, build one thin slice first.

    Show me
  4. 04

    A Philosophy of Software Design: shape

    Small fronts with lots behind them. Hide decisions. Fewer special cases. The shortest of the four.

    Show me
  5. 05

    Legacy Code: safety

    Code without tests is legacy code, even if an agent wrote it this morning. Tests first, then change.

    Show me
  6. 06

    Domain-Driven Design: words

    One shared set of words for the business, in talk and in code. Read the first three chapters.

    Show me
  7. 07

    Book words are agent words

    Tracer bullet, deep module, seam. Short terms the models already know. One precise word replaces a paragraph of instructions.

    Show me
  8. 08

    You design, the agent types

    What's core, where the edges go, when it's good enough. Those calls stay with you.

    Show me

Words on this page

Eighteen terms, in plain words. Skip this if you already write code.

Agent
An AI that reads and writes code for you, like Claude Code or Codex.
Codebase
All the code for one app or project.
Module
Any part of the code with a front and a back: a function, a file, a class.
Interface
The front of a module. What you call, what you pass in, what you get back.
Function
A named piece of code that does one job and can be reused.
Class
A template in code that bundles data and actions together, like an Order.
Dependency
When one part needs another part to work.
Refactor
Change the shape of code without changing what it does.
Test
A small program that checks your code does what it should.
Test-first (TDD)
Write the test before the code, then write code until it passes.
Compiler / type checker
A tool that reads your code and flags mistakes before it runs. TypeScript has one.
TypeScript
JavaScript with types added. The code examples on this page use it.
Domain
The business area the software is for: bookings, banking, bakeries.
Domain expert
Someone who knows the business well. Often not technical at all.
Model
A simplified picture of how the business works, used to build the software.
Legacy code
On this page, Feathers' meaning: code without tests.
Glossary file
A file listing your project's words and what they mean, read by people and agents. Often CONTEXT.md.
Rules file
Instructions an agent reads at the start of every session: CLAUDE.md or AGENTS.md.

Why these four, and why now

On Oct 7, 2026, Pocock posted a short joke about his own path with AI coding. In the replies, Peter Jia listed the four books Pocock recommends in his videos and podcasts, with one tip: read only the first three chapters of Domain-Driven Design.

His post, in eight steps · paraphrased

  1. 1AI can do my job better than me.
  2. 2Software engineering is dead.
  3. 3So vibe code everything.
  4. 4The results are bad, whichever model.
  5. 5What if I constrain the agent?
  6. 6Better. How do I go deeper?
  7. 7Orders twelve software engineering books.
  8. 8Software engineering is alive.

The point under the joke: agents made writing code cheap, but not good code. Holding them to a good design took the ideas in these books. His post

Where Pocock uses these books

AI Engineer Europe 2026 talk, “Software Fundamentals Matter More Than Ever” (about 18 min)

Watch the talk
  • PhilosophyOusterhout's definition of complexity, and deep modules as code an agent can use without reading it all.
  • PragmaticSoftware entropy, and not outrunning your headlights: feedback speed sets how fast you can safely go.
  • DDDUbiquitous language: a shared glossary that makes the agent's plans shorter and closer to what you meant.

The Pragmatic Engineer podcast with Gergely Orosz, Sep 17, 2026

Watch the episode
  • PragmaticTracer bullets as a “leading word”: say it to an agent and the code gets better. He now reads classic books looking for more words like it.
  • PhilosophyTactical vs strategic programming: agents take the tactical work, people keep the strategic part.

His skills repo, mattpocock/skills

See the repo
  • DDDgrill-with-docs interviews you and writes the domain words into a glossary.
  • Philosophycodebase-design aims for deep modules with small interfaces.
  • Legacy Codeimplement drives tests at the seams you name. Work is sliced into tracer-bullet tickets.

From the talk page and the episode notes, not a transcript. The episode's book segment starts at 1:34:01. The list of four is Peter Jia's. Pocock's own post says he ordered twelve books and doesn't name them.

The four at a glance

The Pragmatic ProgrammerDavid Thomas and Andrew Hunt · 1999HabitsHow a good developer thinks and works, day to day. 53 short topics, each one a habit.Read:All of it, in any order. Every topic stands on its own.
A Philosophy of Software DesignJohn Ousterhout · 2018ShapeHow to shape code so it stays simple: deep modules, hidden decisions, fewer special cases.Read:All of it. It's the shortest of the four.
Working Effectively with Legacy CodeMichael Feathers · 2004SafetyHow to change code that has no tests without breaking it: get it under test first, then change it.Read:Part I (Ch. 1–5). After that, look up the chapter for the problem you have. Part II is a FAQ.
Domain-Driven DesignEric Evans · 2003WordsHow to model a business in software, starting with one shared set of words.Read:Chapters 1–3 first, as the list says. Then dip into the rest when you need it.

The forty ideas

Pick a book, then click any idea. Each one opens the same way: the idea in plain words, an everyday example with no code, a code example (or what to say to your agent), what it means with AI agents, what to watch out for, and where it is in the book.

Pick a book

Habits · 1999 · 2nd edition 2019 · about 350 pages

Publisher page

The Pragmatic ProgrammerYour Journey to Mastery, 20th Anniversary Edition

David Thomas and Andrew Hunt

How a good developer thinks and works, day to day. 53 short topics, each one a habit.

What to read

All of it, in any order. Every topic stands on its own.

Who it's for

Anyone who builds software or directs people or agents who do. Coder or not.

10 ideas · click one to open it

  1. 01 · Own your work

    No excuses. Bring options, not complaints.

  2. 02 · Fix broken windows

    Small mess left alone invites more mess.

  3. 03 · Don't repeat yourself (DRY)

    Every fact lives in one place.

  4. 04 · Orthogonality

    Change one part without breaking another.

  5. 05 · Easier to change (ETC)

    The one test for any design choice.

  6. 06 · Reversibility

    No decision is final. Don't lock yourself in.

  7. 07 · Tracer bullets

    Build one thin slice that works end to end, then grow it.

  8. 08 · Don't outrun your headlights

    Take steps no bigger than your checks can see.

  9. 09 · Don't program by coincidence

    Know why it works, not just that it works.

  10. 10 · Good-enough software

    Know when to stop. Let the users help decide.

40 ideas, ten per book. The summaries and examples are ours, not the authors' wording. Chapter numbers are for the editions named on each book. A Philosophy of Software Design uses first-edition numbers. The second edition adds a chapter, so a number may be off by one there.

One idea, four books

Read side by side, the four books keep saying the same few things in different words. Each row is one of those things. Click any box to open it.

  1. 01

    Make change cheap

    The goal under all four books. Good design is design that's easy to change.

  2. 02

    Hide the messy part behind a simple front

    Small fronts, big backs, clean edges. Each book has its own word for it.

  3. 03

    One fact, one place, one name

    Say each thing once, and call it the same thing everywhere.

  4. 04

    Try it small before you commit

    A thin slice, a second design, a new tested function, a real example with an expert.

  5. 05

    Know what the code really does

    No luck, no guessing. Write down the why, record what it does, keep it matching the business.

  6. 06

    Invest a little every day

    Mess builds up quietly. All four say: pay it down as you go, not once a year.

  7. 07

    Guard the borders

    Keep outside things, vendors, errors and other systems' models from leaking into your code.

The rows are FakeNerd's reading. None of the authors draws this table, and Feathers never states the third thread as a rule, so that box is empty.

Where to start

Find the line that sounds like you. Each one names what to read first and three ideas to open now.

  • If you say

    “I direct agents. I don't write code.”

    Read: The Pragmatic Programmer, Ch. 1–2 (Topics 1–15). Then Domain-Driven Design, Ch. 1–2.

    Both are about how to think and how to talk about the work, not syntax. That's most of the job when an agent types.

  • If you say

    “My agent's code is getting tangled.”

    Read: A Philosophy of Software Design, Ch. 2–5, then Ch. 10–11.

    It gives you the words to say what's wrong (shallow, leaky, too many special cases) and what to ask for instead.

  • If you say

    “I have an old app nobody wants to touch.”

    Read: Working Effectively with Legacy Code, Ch. 1–4, then Ch. 13 and Ch. 6.

    It's a step-by-step way to get a safety net under code nobody understands, before anyone changes it.

  • If you say

    “I build for a business with lots of its own terms.”

    Read: Domain-Driven Design, Ch. 1–3, then Ch. 14.

    It's about getting the business's words into the code, and keeping different parts of the business from muddling each other.

  • If you say

    “One book, one weekend.”

    Read: A Philosophy of Software Design, cover to cover.

    It's the shortest, and its ideas, deep modules most of all, are the ones Pocock leans on most when he talks about agents.

Try it, smallest version first

Six steps. The first costs one evening. The rest take a few minutes each with any coding agent: Claude Code, Codex, Cloudroom or bb. Every starter below is FakeNerd's, built from the ideas on this page, not Pocock's wording.

  1. 01

    Read one chapter tonight

    A Philosophy of Software Design, Ch. 4, or The Pragmatic Programmer, Topic 12. Each is short and stands on its own. If you only read one thing, make it one of these.

  2. 02

    Give your agent your words

    Make a glossary file in your project with one line per business term. Ask the agent to use only those words. This is ubiquitous language in ten minutes.

    FakeNerd starter · CONTEXT.md

    # CONTEXT.md — the words we use
    
    One line per term. Use these words in chats, docs and code.
    If a word is missing or wrong, say so and update this file first.
    
    ## Terms
    - Booking: one customer's reserved time slot. Not "reservation", not "order".
    - Guest: the person who comes in. May not be the one who paid.
    - Payer: the person whose card is charged.
    - No-show: a booking where the guest didn't arrive within 15 minutes.
    
    ## Words we don't use
    - "Reservation" (say Booking)
    - "User" when we mean Guest or Payer
    
    ## Areas (each has its own words)
    - Bookings: everything above
    - Billing: Invoice, Refund, Payer
  3. 03

    Put the book words in your rules file

    Paste this into CLAUDE.md or AGENTS.md. Each line is one idea from this page, written as an instruction.

    FakeNerd starter · rules file block

    ## Design habits (from four classic books)
    
    - ETC: when there are two ways, pick the one that's easier to change later.
    - Tracer bullet first: build one thin slice that works end to end, then grow it.
    - Deep modules: small, simple interfaces with the work hidden inside. No pass-through layers.
    - Use the words in CONTEXT.md. One name per idea, in code and in chat.
    - Old code without tests: write characterization tests first. Change nothing until they pass.
    - New code in untested areas: sprout a new, tested function instead of editing deep inside.
    - Before you finish: list what you skipped, guessed or couldn't test.
  4. 04

    Next feature: ask for a tracer bullet

    Instead of describing the whole feature, ask for the thinnest slice that works end to end. Check it, then grow it.

    FakeNerd starter · tracer bullet

    Build this as a tracer bullet.
    
    The feature: [what you want]
    
    1. Build the thinnest version that goes all the way through:
       screen -> logic -> storage -> back to the screen.
    2. Leave out everything else. List what you left out.
    3. Show me it working before adding anything.
  5. 05

    Before touching old code: record it first

    Have the agent write characterization tests, so any change in behavior shows up straight away.

    FakeNerd starter · characterization tests

    Before changing [file or function], write characterization tests.
    
    1. Run the current code with a range of normal and odd inputs.
    2. Write tests that expect exactly what it does today, even if it looks wrong.
    3. Don't fix anything yet. List anything that looks like a bug.
    4. Show me the tests passing. Then we'll make the change.
  6. 06

    Before anything big: design it twice

    Two different designs, compared in plain words. It costs the agent seconds and saves you reviewing the wrong build.

    FakeNerd starter · design it twice

    Design it twice before writing code.
    
    The job: [what this part should do]
    
    Give me two very different designs. For each:
    - the interface: function names, inputs, outputs
    - what it hides from the rest of the code
    - what would be hard to change later
    Then recommend one, in plain words.

Where this fits on FakeNerd

This page is the reading behind two others.

The skills

Matt Pocock's skills

The book ideas turned into agent skills: grill-with-docs (ubiquitous language), codebase-design (deep modules), tracer-bullet tickets, tests at named seams.

The picker

Which skill pack when

Pocock's pack next to Addy Osmani's and pstack. If you want the ideas built in rather than read, start there.

Same advice, different person

Guillermo Rauch's workflow

Vercel's CEO also tells people to learn the concepts, not the syntax, so they can tell an agent what to do and know it's possible.

FakeNerd's take

These are agent instructions in disguise

Each book gives short, exact names to big ideas, and the models learned the same names. “Build a tracer bullet” says in three words what would take a paragraph. That's Pocock's “leading words” idea, and it's why old books pay off now.

Read for the ideas, skip the dated code

Legacy Code (2004) and Domain-Driven Design (2003) use Java and C++ era examples. The ideas have aged far better than the code. Read the reasoning, not the syntax.

Non-coders: start with two

The Pragmatic Programmer's first two chapters and Domain-Driven Design's first two are about thinking and talking, not code. That's most of the job when you direct an agent.

The skill that grows is judgment

Agents type. Deciding what's core, where the edges go, what to test and when it's good enough is still yours. These four books are mostly about those calls.

Attribution

  • The books: The Pragmatic Programmer by David Thomas and Andrew Hunt (Addison-Wesley, 2nd edition 2019); A Philosophy of Software Design by John Ousterhout (Yaknyam Press, 2018 and 2021); Working Effectively with Legacy Code by Michael Feathers (Prentice Hall, 2004); Domain-Driven Design by Eric Evans (Addison-Wesley, 2003). The ideas are theirs. Every summary, example and scenario on this page is FakeNerd's, in our own words. Nothing is quoted from the books.
  • The list of four, and the tip to read only the first three chapters of Domain-Driven Design: Peter Jia (@PeterJiax) on X, Oct 7, 2026, replying to Matt Pocock's post the same day.
  • What Pocock says about each book is from the pages for his AI Engineer Europe 2026 talk and his Pragmatic Engineer episode (Sep 17, 2026), plus his skills repo. We couldn't pull transcripts, so nothing is quoted from him either.
  • Chapter pointers: The Pragmatic Programmer topic numbers from the publisher's table of contents (2nd edition). The other three from printed tables of contents. Page counts are rounded.
  • The forty “with AI agents” lines, the seven threads, the reading picker, every starter and the takes are FakeNerd's. No affiliate links. Not sponsored by anyone on this page.
↑↓ move enter openBrowse every card