# Guides

- [What Is a Design Pattern](https://aipatterns.dev/guides/what-is-a-pattern.md): A design pattern is a named, reusable solution shape for a recurring design problem. Learn what one contains and how it differs from an algorithm or library.
- [History of Patterns](https://aipatterns.dev/guides/history-of-patterns.md): Where design patterns came from, from Christopher Alexander's architecture books to the Gang of Four catalog, and what changed in how they are used today.
- [Why Learn Patterns](https://aipatterns.dev/guides/why-learn-patterns.md): What knowing design patterns buys a developer or coding agent: shared vocabulary, faster code reading, better refactoring targets, and knowing when to stop.
- [Criticism of Patterns](https://aipatterns.dev/guides/criticism-of-patterns.md): The main arguments against design patterns, including missing language features, misuse, and over-engineering, and how to apply patterns without those failures.
- [Classification of Patterns](https://aipatterns.dev/guides/classification-of-patterns.md): How the 22 classic design patterns are grouped by purpose into creational, structural and behavioral, plus other useful ways to slice them.
- [Factory Comparison](https://aipatterns.dev/guides/factory-comparison.md): Tell apart a factory function, static creation method, simple factory, Factory Method and Abstract Factory, and pick the smallest one that fits.
- [Visitor and Double Dispatch](https://aipatterns.dev/guides/visitor-and-double-dispatch.md): Why overloading alone cannot pick a method by an argument's runtime type, how Visitor uses double dispatch to fix it, and when pattern matching replaces it.
- [Choosing a Pattern](https://aipatterns.dev/guides/choosing-a-pattern.md): A decision guide that maps concrete code symptoms to the pattern that fixes them, and tells you when plain code beats any pattern.
- [Eval-Driven Development](https://aipatterns.dev/guides/eval-driven-development.md): Write the task-and-verifier pairs before the tool, prompt or agent, then let the numbers decide changes - the same discipline as tests-first, applied to components whose output is text.
- [How Agents Should Use This Reference](https://aipatterns.dev/guides/for-agents.md): Rules for AI coding agents using this reference: diagnose a named smell, read the exclusions first, apply one technique at a time and verify with tests.
- [What Is Refactoring](https://aipatterns.dev/guides/what-is-refactoring.md): Refactoring changes the internal structure of code in small, behavior-preserving steps so it becomes cheaper to read and change.
- [Technical Debt](https://aipatterns.dev/guides/technical-debt.md): Technical debt is the extra cost every future change pays because of shortcuts and drift in today's code. Learn its causes and how to pay it down.
- [When to Refactor](https://aipatterns.dev/guides/when-to-refactor.md): Refactor right before you change code, while fixing a bug and during review. Skip it when the code is due for deletion or has no tests.
- [How to Refactor](https://aipatterns.dev/guides/how-to-refactor.md): Refactor in small named steps, run tests after each one, never mix in behavior changes, and stop when the code is clean enough for the task at hand.