The Bitter Lesson: why compute always beats hand-coded knowledge
TL;DR
Richard Sutton argues that after 70 years of AI, general methods that leverage compute (search and learning) beat hand-encoded knowledge. For AI products: don't lock in today's model tricks; invest in data, evals and the ability to swap models.
In 2019, Richard Sutton, one of the founders of reinforcement learning, wrote a roughly one-page essay called "The Bitter Lesson". It became one of the most-cited texts in modern AI, and it explains rather well why LLMs won out. This post summarises the argument and draws out what it means for people building AI products today.
The core argument
Looking back over 70 years of AI research, Sutton argues the biggest lesson is that general methods that leverage computation are ultimately the most effective, and by a large margin. The reason is that the cost of computation keeps falling exponentially (Moore's law). Researchers, by contrast, tend to build human knowledge into their systems; that pays off in the short term and is intellectually satisfying, but in the long run it plateaus and even inhibits progress.
The essay's four examples
| Field | The "human knowledge" approach | What eventually won |
|---|---|---|
| Chess | Encoding understanding of board structure | Massive deep search (Deep Blue, 1997) |
| Go | Exploiting the game's special features | Search combined with learning from self-play |
| Speech recognition | Phonemes, the human vocal tract | Statistical methods, then deep learning |
| Computer vision | Edge detection, hand-designed features | Convolutional neural networks learning from data |
The two methods Sutton says keep scaling with computation: search and learning.
Why "bitter"?
Because it cuts against what researchers want: their painstaking domain knowledge turns out to be worth less than letting the machine learn with more compute. Sutton concludes that we should build "meta-methods" that can discover the world's complexity themselves, rather than building in what we think we know.
Connection to today's LLMs
- LLMs are a clear example: one general architecture, learning from enormous data and compute, beat specialised hand-built NLP systems.
- Scaling laws (Kaplan, Chinchilla) are the quantitative version of the lesson.
- Reasoning models spend compute at inference time: a new form of "search".
What it means for product builders
- Don't build overly rigid scaffolding around the model: elaborate rules and prompts compensating for today's model weaknesses can become redundant, even a hindrance, when a new model arrives.
- Design for easy model swaps: lasting value lies in data, evals, processes and experience, not in tricks for exploiting one specific model.
- Retry ideas that failed: what last year's model couldn't do, this year's might do well.
Caveats when applying it
- Domain knowledge isn't useless: in products, domain understanding still shapes data, evaluation criteria and user experience.
- Compute isn't free for you: the lesson is about the field's long-term trend; your project budget is still finite.
- It's a viewpoint, not a law: there are thoughtful counterarguments about the role of structure and high-quality data.
How to apply it
- Dev: When you find yourself writing complex workarounds for model weaknesses, mark them for removal when you switch models.
- Tech Lead: Invest in evals and real data; those are the assets that survive every model generation.
- PM: Whenever a new model ships, rerun the ideas you shelved because "AI wasn't good enough yet".
Sources & references
- The Bitter Lesson — Rich Sutton