What Are Design Patterns?

Every profession has a body of recurring problems and recognized solutions. Cooks call them techniques. Architects call them forms. Software developers call them patterns.

The word sounds formal, but the idea is plain: when the same problem shows up in many different contexts, it deserves a name and a description. Naming it lets people think about it precisely, talk about it efficiently, and recognize it when they see it.

Where Patterns Came From

In 1977, the architect Christopher Alexander published A Pattern Language. He observed that certain design problems (how to place a window seat, how to connect a neighborhood to the street) appeared again and again across different buildings. He catalogued 253 of them, each with a context, the tension it resolved, and a solution. The solutions weren’t blueprints. They were principles that could be applied differently in each situation.

Alexander’s real contribution was the word “language.” Patterns don’t just exist individually. They connect. A solution at one scale creates the conditions where patterns at other scales apply. The town connects to the neighborhood, the neighborhood to the street, the street to the building entrance. Together they form a vocabulary for describing how spaces work and how to make them better.

The Crossing Into Software

In 1994, four software researchers published Design Patterns: Elements of Reusable Object-Oriented Software. The authors (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) noticed that experienced programmers kept solving the same structural problems the same ways. They catalogued 23 of these solutions and organized them into a book that shaped how an entire generation of programmers talked about code. The authors became known as the Gang of Four.

Their patterns had the same character as Alexander’s: each described a recurring context, the forces creating tension in that context, and an approach that resolved those tensions. None were recipes to follow literally. All required judgment in application.

The vocabulary caught on. Once you know what a factory is, or a strategy, you can say “use a factory here” to another developer and be understood in seconds rather than paragraphs. The pattern name carries the concept.

Why It Matters More Now

When you direct an AI agent to build something, you’re describing what you want, not writing code yourself. The clearer your description, the better the agent’s output. Pattern vocabulary earns its keep here.

Compare these two instructions to an agent:

“Break this into smaller pieces so it’s easier to change.”

“Apply Decomposition to separate the data-fetching logic from the display logic, and keep Coupling low between the two components.”

Both ask for roughly the same thing. The second produces better work, consistently, because it’s precise. The agent knows what decomposition means structurally. It knows what low coupling requires. It doesn’t have to guess.

The same applies when you’re evaluating output. If an agent returns code where a change in one place breaks things in five others, you can recognize that as high coupling and direct the agent to fix it, rather than vaguely asking it to “clean this up.” Patterns give you the vocabulary to notice problems and name them clearly.

This matters whether or not you ever write code yourself. You can direct Abstraction, evaluate a Prompt, and spot a Code Smell without touching a keyboard. The vocabulary does the work.

How Each Entry Is Organized

Every pattern entry in this book follows the same structure:

Context: The situation where this pattern is relevant. What kind of project, what kind of team, what conditions apply.

Problem: The tension you’re facing. Not a task to complete, but a conflict between competing concerns that can’t all be satisfied at once.

Forces: The pressures pulling in different directions. These explain why the problem is hard.

Solution: The approach that resolves the tension. Not a prescription, but a principle.

How It Plays Out: Concrete examples showing the pattern in action. At least one scenario involves directing an AI agent.

Consequences: What changes after you apply the pattern, both gains and tradeoffs.

Related Patterns: Patterns that often appear alongside this one, or that this one creates the conditions for.

You don’t need to read entries in order. Start with what’s relevant to you and follow the links. That’s what a language is for.

Patterns Are a Thinking Tool

The goal of learning patterns isn’t to follow them mechanically. A pattern names a situation and suggests an approach, not a blueprint. Whether that approach fits your situation is a judgment call you still have to make.

What patterns give you is a quicker path to that judgment. You recognize the situation faster. You recall solutions that have worked before. You have words for what’s wrong when something feels off.

That’s as true when you’re directing an agent as when you’re writing code. The agent handles implementation. You handle thinking. Patterns are what you think with.