Welcome to the Encyclopedia of Agentic Coding Patterns

In January 2023, Andrej Karpathy posted a single sentence that caught fire: “The hottest new programming language is English.” Two years later, Jensen Huang told an audience that nobody should need to learn a programming language because the new programming language is human. By mid-2025, Karpathy had a name for the shift: Software 3.0, where prompts are source code, English is syntax, and large language models are the CPUs that execute it.

These aren’t fringe predictions. They describe what’s already happening. AI coding agents read codebases, plan changes, write the code, run the tests, and fix what breaks, all from a description in plain language. A task that took a developer a day can take an agent ten minutes. A task that required hiring a contractor can be handled by someone who has never opened a code editor. The barrier between “having an idea for software” and “having working software” is thinner than it has ever been, and it’s getting thinner fast.

Code is free now. Not free as in open source. Free as in: the mechanical act of producing working software is no longer the bottleneck. The skill that defined professional software development for sixty years is being automated the same way assembly language was automated when compilers arrived in the 1950s.

That analogy holds further than most people take it. When high-level languages replaced assembly, developers didn’t stop needing to understand computation. They stopped hand-managing registers and memory addresses, but they still needed to understand data structures, control flow, algorithms, and system design. If anything, the abstraction freed them to think about harder problems: concurrency, distributed systems, user experience. The compiler took over the mechanical translation. The thinking stayed human.

The same thing is happening now, one layer up. Agents handle the translation from intent to code. But the intent still has to be sound.

Someone still has to decide what the software should do, how it should be structured, what happens when things go wrong, and whether the result actually solves the problem it was meant to solve. Someone has to notice when the architecture is fragile, when a security assumption doesn’t hold, or when the tests prove the wrong thing. That “someone” is you.

The Paradox

Here’s what the “everyone can code” headlines get wrong. Code may be free, but the knowledge behind good software isn’t. Architecture, decomposition, testing, security, product judgment: these concepts matter more when agents write the code, not less.

Think of an agent as an amplifier. It makes your decisions louder. Give it a clear architecture and well-defined boundaries, and it produces clean, maintainable work. Give it a vague prompt with no structure, and it produces a mess at speed. The mess compiles. The mess might even pass a few tests. But it won’t hold up when requirements change, users arrive, or a second agent tries to build on top of it.

Bad decisions have always been expensive. Agents make them faster.

The people building software in this new era need to learn everything except how to type the code. They need to know what to build, how to break a problem into parts an agent can handle, how to verify the output, and how to think about the tradeoffs that no model can resolve for them.

That’s the gap this book fills.

Who This Book Is For

Three groups of people are converging on the same need, and this book was written for all of them.

Nontraditional builders can now participate in software construction for the first time. If you can describe what you want in clear language, you can direct an agent to build it. But “describe what you want” turns out to require the same conceptual vocabulary that engineers spent decades developing. You don’t need to write a for-loop. You do need to understand why separating concerns matters, what a test is supposed to prove, and how to evaluate whether the thing the agent built is actually the thing you asked for.

Developers whose role is shifting already know much of this material. What’s changing is the workflow: directing agents instead of typing code, reviewing output instead of writing it, designing systems at a higher level of abstraction while the implementation happens below you. This book connects the foundations you already have to the agentic workflows where they now apply. It also fills gaps. Most developers learned decomposition and testing on the job, not from first principles. When you’re directing an agent, the principles matter more than the habits.

Team leads, product managers, and founders direct and evaluate work. With agents in the loop, the quality of that direction determines the quality of the output more directly than ever. A product manager who can articulate requirements in terms of boundaries, invariants, and acceptance criteria will get better results from an agent-augmented team than one who can only say “make it work like the mockup.” The vocabulary in this book gives you that precision.

A Pattern Language for the Agentic Era

The book’s structure borrows from a proven framework. In 1977, the architect Christopher Alexander published A Pattern Language. He catalogued 253 recurring design problems and their solutions, each with a context, a tension, and a resolution: Pattern 159, Light on Two Sides of Every Room. Pattern 112, Entrance Transition, the passage between street and building that prepares you to shift contexts. Pattern 53, Main Gateways, the points where you cross from one neighborhood into another. His real insight was that these solutions formed a language: patterns at one scale created conditions for patterns at other scales, and together they gave ordinary people a vocabulary for shaping the built environment.

In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (the “Gang of Four”) published Design Patterns: Elements of Reusable Object-Oriented Software. The book applied Alexander’s framework to code and gave a generation of programmers a shared vocabulary for talking about software structure. When a developer says “use a factory here” or “this violates single responsibility,” everyone on the team knows what they mean. The pattern name carries the concept.

The Encyclopedia carries that tradition into the agentic era. The problems have changed: how do you decompose a task so an agent can handle it? How do you verify output you didn’t write? How do you give an agent enough context without overwhelming it? How do you set boundaries so an autonomous process doesn’t wreck your codebase?

These questions have answers, and those answers connect into a language. This book names them. What Are Design Patterns? covers the full lineage.

What’s Inside

The book is organized as a progression. It moves from strategic to tactical, then into agentic specifics. The arc is deliberate: each section builds the vocabulary the next one relies on.

It opens with product judgment: what to build, for whom, and why. These questions precede any code, and skipping them is the most expensive mistake in software. From there it moves through intent and scope, where vague goals become concrete requirements and constraints.

The middle sections cover the foundations of software construction. Structure and decomposition teaches how to break problems into parts. Data and state covers how information is represented and kept consistent. Computation and interaction explains how software does things. Correctness and testing builds confidence that the software works, and keeps that confidence as it changes. Security and trust protects against things going wrong, whether by accident or by intent.

These aren’t relics of the pre-agent world. They’re the load-bearing knowledge that agents can’t supply on their own. You can skip them if you already have them. You can’t skip them if you don’t.

Then comes the section the book is named for: agentic software construction. Models, prompts, context windows, tools, verification loops, steering loops, instruction files, and the workflows that connect them. This is where the book maps new territory: the concepts that didn’t exist five years ago and that most teams are still discovering on their own.

If you already know how software is built and you’re here for the agentic layer, start there. How to Read This Book offers five curated learning tracks if you want a guided path.

Where to Start

The book is designed for multiple entry points.

New to all of this? Read What Is Agentic Coding? first. It explains what agents are, how they differ from earlier AI tools, and what your role becomes when you direct work instead of writing code.

Developers adopting agents can jump to the Agentic Software Construction section or pick up Track 4 in How to Read This Book. You’ll find the foundations familiar and the agentic material immediately applicable.

Product people and team leads should start with Product Judgment, then read the agentic patterns that shape how teams work with agents: Instruction File, Verification Loop, and Human in the Loop.

Or browse the sidebar. Every entry links to related patterns, so you can follow whatever thread catches your attention.

A Book That Builds Itself

One more thing worth knowing. The Encyclopedia is the world’s first self-writing book. Initiated and guided by Wolf McNally and his consultancy LockedLab.com, it’s maintained by an autonomous improvement engine: an AI agent that researches topics, writes new entries, edits existing ones for quality, and deploys the live site in a continuous loop. No one presses a button between cycles. The engine reads the style guide, consults the editorial plan, picks the most useful action, executes it, and commits the result to version control. It also periodically evaluates its own process, measuring which actions produce the best results and adjusting its approach accordingly. Those self-evaluations are public: the Meta Report is the engine’s lab notebook, recording what it measured, what it learned, and what it changed. A human designed the system, set the editorial standards, and reviews the results, but the engine operates within those bounds on its own.

This isn’t a gimmick. It’s a consequence of taking the book’s own ideas seriously. The patterns described in these pages (instruction files, verification loops, steering loops, feedback sensors) are the same patterns that keep the engine running. The book teaches what it’s built from. If you want to see how that works in practice, How This Book Writes Itself breaks down the architecture.

You’re reading a proof of concept. Every page was produced by the same class of tools and workflows the book describes. When the prose standard says agents need verification loops, the engine that wrote this page runs one before every commit. When an entry explains context engineering, the engine practices it to decide what to write next. The book doesn’t just describe the agentic era. It’s a product of it.