The observation
In 2019 the researcher Rich Sutton wrote down a pattern he had watched repeat for seventy years. Across every corner of artificial intelligence — chess, Go, speech recognition, reading images — researchers would carefully hand-code human expertise into a system: the openings a grandmaster knows, the rules of grammar, the features that make a face a face. And every time, a simpler method that did none of that — one that just threw more computation and more data at the problem and let the machine work it out — eventually overtook the clever one. Usually decisively.
He called it the bitter lesson. Bitter, because the knowledge-rich approach almost always looks better at first, so a generation of researchers pours years into it — and then gets swept aside. And bitter because the field keeps having to learn it again, subfield by subfield, each time convinced this problem will be the exception.
The counterintuitive core
The instinct — a reasonable one — is that to make a machine good at something, you should teach it what you know. The bitter lesson says the opposite has won in practice. Progress came less from teaching machines what we know and more from building machines that can learn and search for themselves, then feeding them scale. The human knowledge felt like the asset; it turned out to be the ceiling.
What it means if you build with AI
This is where the idea stops being history and starts being advice. Boris Cherny, who leads Anthropic's Claude Code, turns the lesson into four rules for anyone building a product on top of an AI model:
- Don't fine-tune when the frontier model will do. Fine-tuning — training a general model on your narrow data to specialise it — creates something the next general model release will usually make obsolete. You are optimising a thing that is about to be replaced.
- Don't over-scaffold. Wrapping a model in a rigid 'do step 1, then step 2, then step 3' harness can buy you 10–20% on today's benchmark. The next model learns to handle those cases itself, and the scaffolding you built becomes dead weight.
- Give the model tools, not instructions. Rather than stuffing everything it might need into the prompt up front, hand it a tool it can reach for. Let the model decide when and how to use it.
- Build for the model six months from now. Accept that the fit is poor today, and design for the more capable general model that is coming. Claude Code was built for a model that did not yet exist when the design was set — and the bet paid off when it arrived.
The through-line: expose general capability, minimise constraint. Every place you encode your own cleverness is a place the next model will erode.
The honest limit
It is a pattern, not a law — and worth holding with both hands. The general approach is often genuinely worse in the short term, so building for six months from now is a bet, not a guarantee. And it does not apply everywhere equally. Fei-Fei Li points out that robotics cannot simply scale the way language did: a language model trains on text and outputs text — perfect alignment — whereas a robot must output physical actions in a 3D world, and the web's video contains no such actions to learn from. The lesson points in the right direction there, but the data to follow it does not yet exist.
Go deeper
The single best source on the builder's version of this idea is Boris Cherny on Lenny's Podcast — watch it here, or read the episode.