When code is cheap, systems design matters more.

AI writes the code now. The lasting work is judgment: where to draw boundaries, which tradeoffs to accept, what to constrain. Systems Playbook is a connected atlas of 209 durable ideas, distilled from 23 classic books, built to think with.

New here? Start with Software Design Foundations.

Ideas
209
Mental models
15
Sources
23
Paths
10
ArchitectureComplexityDecision MakingDesignOrganizationsProductSystems
209 entries, 23 sources, one map · explore it in 3D

Open a shelf

Jump straight into a layer of the graph, or run a filtered search across everything.

Graph explorerSearch & 3D map

Search every entry, then explore its neighborhood in the full interactive graph.

Reading paths10 curated routes

Follow lightweight sequences through the graph for common reader goals.

Concepts158 entries

Core ideas, principles, biases, and system properties extracted from the playbook.

Patterns6 entries

Promoted repeatable practices that connect ideas to concrete engineering moves.

Mental Models15 entries

Reusable lenses for reasoning about systems, organizations, products, and decisions.

Categories7 entries

Top-level library shelves that organize the knowledge graph by domain.

References23 entries

Source summaries that provide durable provenance for the graph.

Guided ways into the graph

Use these optional paths for a first pass through practical themes, then branch into related entities.

  1. Architecture Decision-Making
    Practical7 steps

    Use tradeoff thinking, quality attributes, decision records, timing, reversibility, and boundaries to structure design reviews.

    • Everything Is a Tradeoff
    • Architecture Characteristics
    • Fitness Functions
  2. Decision-Making Under Uncertainty
    Practical7 steps

    See how human judgment is systematically bounded, then walk the specific biases that distort estimates and choices so they can be recognized in the moment.

    • Judgment Is Bounded
    • System 1 and System 2
    • Anchoring
  3. Designing Choices
    Practical8 steps

    Design the decision, not just the option: defaults, framing, mapping, and structure all shape what people choose, so arrange the easy path to be the good one without removing freedom.

    • Structure Drives Behavior
    • Choice Architecture
    • Default Options
  4. Designing for Failure
    Deep8 steps

    Treat failure as the normal condition of a complex system and build the reasoning that follows: partial failure, latent flaws, tolerance, graceful degradation, and resilience.

    • Failure Is Normal
    • Partial Failure
    • Latent Failures
  5. Flow and Constraints
    Practical9 steps

    Read a system by its flow: name the goal, find the one constraint that sets the pace, and subordinate everything else to it instead of optimizing parts in isolation.

    • Optimize the Whole
    • Define the Goal
    • Throughput
  6. Judgment in the AI Era
    Deep10 steps

    The capstone path. When code is cheap to produce, value moves to deciding what is correct and proving it: specify intent, draw the boundaries, then verify, operate, and learn.

    • Verification Over Authorship
    • Ubiquitous Language
    • Bounded Context
  7. Keeping Code Changeable
    Practical8 steps

    Treat changeability as the asset: read the signals of decay, restructure safely, and pay down debt so the code keeps absorbing change cheaply.

    • Design Is an Investment
    • Technical Debt
    • Code Smells
  8. Product and Organization Systems
    Practical7 steps

    Connect product direction, metrics, choice environments, Conway effects, and team interfaces as one socio-technical system.

    • Start From the User
    • Working Backwards
    • Input vs Output Metrics
  9. Software Design Foundations
    Introductory9 steps

    Work from the diagnosis that complexity is the core problem down to the concrete techniques that keep code understandable: hiding decisions, deep modules, precise names, and obvious code.

    • Complexity Is the Root Cause
    • Complexity
    • Essential vs Accidental Complexity
  10. Systems Thinking Foundations
    Introductory7 steps

    Build a first path through system structure, feedback, delays, leverage, traps, and complexity before branching into the wider graph.

    • Structure Drives Behavior
    • Stocks and Flows
    • Feedback Loops

Useful shelves to open first

Begin with a mental model, a promoted pattern, or a category, then follow relationship links across the graph.

  1. Mental ModelAdversarial Mindset
    decision-making

    Reason about a system from the perspective of other agents who pursue their own interests and will exploit your assumptions, not only from how the system is meant to be used. Whether the other party is an attacker probing for a weakness or a rival anticipating your next move,...

  2. Mental ModelComplexity Is the Root Cause
    complexity

    Complexity, especially the accidental complexity we introduce ourselves, is the dominant source of difficulty in software, so the highest leverage work is relentlessly reducing it. The enemy is not lines of code or scale but the loss of understandability as a system grows. Com...

  3. Mental ModelComplexity Should Be Hidden
    complexity

    Complexity is inevitable, but it should be concealed behind simple interfaces and pushed down and inward, so that most people most of the time never have to confront it. The quality of a design is measured by how little complexity it exposes, not by how clever its internals ar...

  4. PatternContext Mapping
    architecture

    Making the relationships between bounded contexts, and the teams that own them, explicit, so that integration between separate models is a deliberate design choice rather than an accident. Domain Driven Design names the relationship types (shared kernel, customer/supplier, con...

  5. PatternContinuous Delivery
    systems

    Keeping software in a continuously releasable state, so that shipping to users is a routine, low risk, on demand event rather than a painful, infrequent project. It is assembled from working in small batches, automating the build test deploy path so quality is built in rather...

  6. CategoryArchitecture

    The structure of software systems: boundaries, components, and the tradeoffs between competing options. Architecture characteristics and the reasoning behind structural decisions.

  7. CategoryComplexity

    Managing, reducing, and hiding complexity in software and systems. The distinction between essential and accidental complexity, and the techniques that keep systems understandable as they grow.

  8. CategoryDecision Making

    How people actually judge and choose under uncertainty. Heuristics, cognitive biases, the two modes of thinking, and the bounded, predictable ways judgment departs from rationality.