Modern Algorithm Design
Designing algorithms and data structures from reusable primitives
Preface
Most algorithms books feel a little like museums: room after room of named algorithms and data structures, each one something to recognize, remember, and reproduce.
I want to do something different with you.
We are entering a time when machines can generate algorithms, search enormous design spaces, write implementations, and sometimes find solutions humans missed for decades. Memorizing more procedures is becoming less valuable. Knowing what to ask for, what can be combined, what must hold, what can fail, and whether an answer is actually good is becoming more valuable.
This book is built around that change.
My claim is that much of algorithm design can be understood through a relatively small collection of recurring ideas—primitives—and through the ways we compose them. Learn those well enough and you should be able to look at a problem you have never seen before and have somewhere to start.
You will still build things here. You will take them apart, change assumptions, break them, and put them together differently. I want the knowledge in your hands. And sometimes I will ask you to put the AI away and struggle with a problem yourself. If you never have to produce the thought, it becomes hard to know whether the ability is yours or the system’s.
Why learn this when machines are getting so good at it?
This is already happening. In September 2026, an AI system working through roughly ten thousand concurrent agents produced a proposed resolution of the Navier–Stokes Millennium Prize Problem. The search took about 88 hours; formalization and verification in Lean took another 17 [1]. The Clay Mathematics Institute subsequently said the problem had “apparently been settled,” while its evaluation process continues [2]. The same shift is reaching ordinary algorithm design. AlphaEvolve improved a 56-year-old result in matrix multiplication and a scheduling rule used across Google’s computing fleet [3]. Something important has changed. Search over ideas and designs is becoming a machine capability at a scale we have never had before.
There is little point preparing you for a race in which the goal is to search faster than machines.
I want to give you the concepts needed to work where the problem itself is being shaped.
What space are we searching? What counts as better? What must remain true? How will we know that the answer really works? What did we leave out when we asked the question that way?
A representation gives us a space in which possible solutions can be expressed and manipulated. An objective says which direction counts as improvement. A verifier tells us whether a candidate actually satisfies what we required.
Machines will increasingly help invent all three. Good. They may discover representations we would never have chosen, propose objectives, construct tests, and challenge our specifications. The important question is whether we understand enough to know what problem is actually being solved.
A representation can be excellent for machine search and terrible for human understanding. An objective can be optimized perfectly while omitting something we cared about. A verifier can faithfully check the wrong thing.
And the check itself has to survive pressure. Search rewarded for passing a test will exploit whatever the test leaves open. Coding agents have already shown this behavior when tests contradict the intended specification [4].
So throughout this book I will keep asking three things about every primitive:
What does it assume? What does it cost? How does it fail?
Those questions matter whether you are designing something yourself, asking an AI to design it, or working with an AI that is helping you ask better questions.
Nothing gets everything at once
There is another reason I think this knowledge will survive very powerful AI: nothing gets everything at once.
Some requirements cannot be satisfied together. Some resources cannot all be abundant simultaneously. Some computations contain dependency chains that more parallelism cannot remove. Every representation makes some operations cheap and others expensive.
More intelligence gives us more possibilities inside those limits. It does not erase them [5].
So design eventually reaches a frontier: faster but larger, exact but expensive, flexible but harder to verify, lower latency but more replication. And then the question that matters changes.
“Which structure is faster?” may have a factual, boring answer. “Which structure should we use?” requires judgment.
What matters here? What risk will we accept? What are we willing to spend? Which future possibilities are we making easier, and which are we making harder?
You might get what you ask for. So you had better learn to ask precisely.
I want you to become dangerous with these ideas: able to see the assumption underneath an impressive answer, the dimension missing from an objective, and the price hidden inside a design.
Why the vocabulary is the point
There is one more thing I want to give you: words.
Once you have a word like invariant, amortized, index, fingerprint, slack, or dominates, you can hold an idea that previously took a paragraph in a single mental handle. Then you can recognize it somewhere else, combine it with another idea, notice when it is missing, and ask for it.
Vocabulary is compressed thought. In the age of AI, it is also compressed specification.
“Make it faster” leaves almost everything open.
“I need bounded worst-case latency; reads dominate writes fifty to one; the working set will exceed memory” gives another intelligence something much sharper to work with.
I spend much of my own research time taking this idea to an extreme: turning claims about AI systems into statements precise enough that a proof checker can inspect them [6]. It teaches a useful lesson. A flawless proof can still prove the wrong statement.
Precision starts earlier, with deciding what you actually meant to say.
The catalog in this book is provisional. Machines will discover new primitives. Some old ones will matter less. New abstractions will appear above them.
What I want you to keep is the habit underneath the catalog:
see a recurring shape, give it a handle, understand what it buys you, learn where it breaks, and keep it ready for composition.
What I hope stays with you
I do not know what systems you will be working with ten or twenty years from now. I expect today’s systems to look primitive by comparison.
You will write little code yourself, at least not in anything resembling its present form. You may rarely design an entire mechanism by hand. The systems around you may help frame the problem, invent representations, question your objectives, and find trade-offs you did not see—quietly, continuously, almost as part of the environment itself.
The relationship may increasingly be one of cooperation among very different kinds of intelligence.
That makes these ideas more useful, not less.
You are always trying to find a workable place in the world around you: among other people, institutions, machines, constraints, and increasingly capable intelligences. You act on that world, and it acts back. You express what you want, see what happens, revise your understanding, and try again.
Algorithm design is one disciplined way of learning to do that well.
Learn the primitives. Break them. Combine them. Learn what each one buys you, what it costs, and where it fails.
Then use them with people, with machines, and with whatever comes next.
We will see how this ages.