Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Algorithm

Pattern

A reusable solution you can apply to your work.

“An algorithm must be seen to be believed.” — Donald Knuth

Context

At the architectural level of software design, every program needs to transform inputs into outputs. Before you can worry about APIs, user interfaces, or deployment, you need a procedure that actually does the work. An algorithm is that procedure: a finite sequence of well-defined steps that takes some input and produces a result.

The concept is older than computers. A recipe is an algorithm. Driving directions are an algorithm. What makes algorithms special in software is that they must be precise enough for a machine to follow without judgment or interpretation. When you ask an AI agent to “sort these records by date” or “find the shortest route,” you’re asking it to select or implement an algorithm.

Problem

You have data and you need a specific result. The gap between the two isn’t trivial. There may be many possible approaches, and the wrong choice can mean the difference between a program that finishes in milliseconds and one that runs for hours, or between one that produces correct results and one that silently gives wrong answers.

Forces

  • Correctness vs. speed: The most obviously correct approach may be too slow, while a faster approach may be harder to verify.
  • Generality vs. specialization: A general-purpose algorithm works on many inputs but may perform poorly on your specific case.
  • Simplicity vs. performance: A simple loop may be easy to understand but scale badly; an optimized algorithm may be fast but hard to maintain.
  • Existing solutions vs. custom work: Reinventing a well-known algorithm is wasteful, but blindly applying one without understanding it is risky.

Solution

Define a clear, finite procedure that transforms your input into the desired output. Start by understanding the problem precisely: what are the inputs, what are the valid outputs, and what constraints apply? Then choose or design a procedure that handles all cases correctly.

In practice, most algorithms you’ll need already exist. Sorting, searching, graph traversal, string matching — these are well-studied problems with known solutions. The skill isn’t in inventing algorithms from scratch but in recognizing which known algorithm fits your problem and understanding its tradeoffs (see Algorithmic Complexity).

When working with AI agents, you rarely write algorithms by hand. Instead, you describe the transformation you need, and the agent selects an appropriate approach. But understanding what an algorithm is, and that different algorithms have different costs and correctness properties, helps you evaluate whether the agent’s choice is sound.

How It Plays Out

A developer asks an agent to “remove duplicate entries from this list.” The agent could use a simple nested loop (check every pair), a sort-then-scan approach, or a hash set. Each is correct, but they differ dramatically in performance on large lists. A developer who understands algorithms can review the agent’s choice and push back if needed.

Tip

When reviewing code an AI agent produces, look at the core algorithm first. Is it doing unnecessary repeated work? Is it using a well-known approach or reinventing one poorly? You don’t need to implement algorithms yourself to evaluate them.

A data pipeline needs to match customer records between two databases. The naive approach, comparing every record in one database against every record in the other, works for a hundred records but collapses at a million. Choosing the right matching algorithm is the single most important architectural decision in the pipeline.

Example Prompt

“The function you wrote uses nested loops to find duplicates, which is O(n squared). Rewrite it using a hash set so it runs in O(n). Keep the same interface and make sure the existing tests still pass.”

Consequences

Choosing the right algorithm means the system produces correct results at acceptable cost. Choosing the wrong one means bugs, slowness, or both, and these problems often don’t surface until the system meets real-world data volumes. Understanding algorithms also creates a shared vocabulary between humans and AI agents: you can say “use a binary search here” and both sides know exactly what that means.

The cost of ignoring algorithms is that you rely entirely on the agent’s judgment about performance-critical code, with no ability to audit it.

  • Enables: Algorithmic Complexity — once you have an algorithm, you need to reason about its cost.
  • Uses: Determinism — most algorithms are expected to be deterministic, producing the same output for the same input.
  • Refined by: Side Effect — algorithms that avoid side effects are easier to reason about and test.

Further Reading

  • Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein — the standard reference, often called “CLRS.”
  • Khan Academy: Algorithms — a free, visual introduction to fundamental algorithms.