The Bitter Lesson
Why Scaling Computation Beats Human Expertise
In 2019, AI researcher Rich Sutton published a short essay that has quietly become one of the most influential pieces of writing in the field. It’s called “The Bitter Lesson,”
This term has come up frequently. It was a topic on the Dwarkesh Podcast that got comments from Andrej Karpathy, Lex Fridman has explored, and some of the world’s best investors routinely cite.
For anyone building a product roadmap, funding an R&D team, or deciding where to place a bet on AI, this isn’t just an academic curiosity, it’s a pattern worth understanding because it keeps repeating.
Who is this guy anyway?
Dr. Richard Sutton is an AI researcher and professor at the University of Alberta in Edmonton Canada. He is Chief Scientific Advisor at the Alberta Machine Intelligence Institute (Amii) and is a recipient of the prestigious Turing Award.
Putting aside all the accolades or citations that are too numerous to mention, he is widely thought of as one of the fathers of a branch of AI call reinforcement learning. He literally wrote the book.
The lesson in plain terms
You can read the original piece here.
The argument is simple yet profound: General methods that leverage ever-increasing computation ultimately outperform approaches that rely on human knowledge, and they do so by a wide margin.
Sutton observes that AI researchers have repeatedly tried to make progress by injecting human understanding into systems. Rules about how chess works, knowledge of language structure, features that describe edges in images, or models of how people think. These efforts often deliver quick wins because they make systems functional with limited resources. They feel intuitive and satisfying to the people building them.
Over time, however, these human-centric approaches plateau. Breakthroughs arrive instead from simpler, more general techniques that scale dramatically with more computation. The reason is Moore’s law and its extensions: the cost of computation keeps falling exponentially. What seems impossibly expensive today becomes routine in a few years.
When researchers (or companies) tie their systems too tightly to current human knowledge, they make it harder for those systems to take full advantage of future hardware and data. Time and resources spent crafting clever rules are resources not spent on methods that improve automatically as compute grows.
Why “bitter”?
Sutton calls this lesson bitter because it delivers a direct blow to human hubris.
We naturally want to believe that human intellect, taste, intuition, and domain knowledge are special. We assume that the secret to building intelligent software is encoding human wisdom into code.
The bitter truth is that human knowledge is often a bottleneck, not a catalyst.
When we hardcode our own strategic assumptions into AI software, we cap the machine’s potential at the limit of human understanding. When we step back and let general search and learning algorithms process massive scale, the AI discovers patterns, strategies, and efficiencies that humans could never have conceived.
There’s a psychological wrinkle here too, and it explains why smart people keep falling into the same trap. Building your own expertise into a system feels productive right away. It gets results in the near term, and it’s satisfying, because you can see your own thinking reflected in the machine.
Betting on raw computing power and letting the system learn on its own doesn’t feel as safe. It’s a bet on factors outside of your control, playing out over a longer timeline than most quarterly budgets, product roadmaps or government research granting cycles. So teams keep choosing the comfortable, expertise-driven path, and keep getting overtaken by whoever chose the harder, computation-driven one.
What this means outside the research lab
You don’t have to be training AI models to have run into a version of this problem. It shows up any time an organization needs to decide: do we build a hand-tuned solution around what our own experts already know, or do we invest in a more general system that improves mainly by throwing more processing power and data at it?
That question comes up constantly. Do you build a customer-service system around a decision tree that your best support agents helped design, or do you invest in an AI model that learns from vast amounts of conversation data without anyone hand-coding the rules? Do you build a forecasting model around your team’s understanding of the business, or a general statistical model trained on far more data than any one person could digest?
This isn’t to say that expertise is worthless. Hand-built, knowledge-driven systems are often exactly right for the problem in front of you today, especially when data or compute is limited, or when a deadline is close. That’s precisely why they win in the short term.
The bitter lesson is about what happens over a longer horizon, once cheaper computing power and larger data sets become available, as they reliably do. This is especially relevant if you are a research lab focused on achieving AGI debating on LLM architectures vs pure RL, etc. The thesis, if you agree with the bitter lesson, is then that the odds tend to favor whoever built something general enough to take advantage of it, and against whoever built in a fixed set of assumptions about how the problem should be solved.
The takeaway for decision-makers
Three things are worth carrying out of Sutton’s essay and into a boardroom.
First, be honest about the timeline. A hand-crafted, expert-built solution will likely outperform a general one in the near term. If your horizon is genuinely short, which is the case for nearly every commercial project, that is probably the right call. But if you’re in the enviable situation of making a multi-year bet, weigh the fact that general, scalable approaches have historically won.
Second, watch for the psychological trap. Teams get attached to solutions that reflect their own expertise. It’s flattering and you can brag about your results. That attachment is a poor guide to where the long-term advantage actually lies.
Third, treat “more computing power and data become available every year” as a fact to plan around, not a hope. It has held for decades across wildly different problems. Whatever roadmap you’re building, ask whether it’s positioned to take advantage of that trend, or whether it’s quietly betting against it.