The Bitter Lesson: How We Build and What We Build Is About to Change
TL;DR
Rich Sutton's Bitter Lesson says general methods that leverage computation win by a large margin. What that means for how we build software and what we build.
Last updated: May 24, 2026
Official Sources#
| Resource | Link |
|---|---|
| The Bitter Lesson (Original Essay) | incompleteideas.net/IncIdeas/BitterLesson.html |
| Rich Sutton's Homepage | incompleteideas.net |
| Reinforcement Learning: An Introduction (Sutton & Barto) | incompleteideas.net/book/the-book.html |
| Deep Blue vs Kasparov (IBM) | research.ibm.com/deepblue |
| AlphaGo (DeepMind) | deepmind.google/technologies/alphago |
| Scaling Laws for Neural Language Models (OpenAI) | arxiv.org/abs/2001.08361 |
The Core Principle#
General methods that leverage computation are ultimately the most effective - and by a large margin.
For the design side of the same problem, read AI Design Slop: 15 Patterns That Out Your App as Vibe-Coded with Create Beautiful UI with Claude Code: The Style Guide Method; they show how agent-generated interfaces fail and how to give coding agents better visual constraints.
This is the essence of Rich Sutton's "The Bitter Lesson," published seven years ago but increasingly relevant as we enter 2026. The lesson is bitter because it directly contradicts our instinct to encode human knowledge into systems. We want to impart our expertise, design elegant architectures, and create frameworks that reflect how we think. But history shows this approach loses in the end.
What History Teaches Us#
In 1997, Deep Blue defeated Kasparov through brute force search. In 2016, AlphaGo beat the world's best Go player through self-play and scale. The critical insight: once these systems reached human-level performance, they didn't stop. They kept improving, quickly surpassing any human capability in their domain.
The same pattern is emerging in software development. We've moved from GitHub Copilot's line-by-line completions in 2021, through multi-file editing tools like Cursor, to today's agent harnesses - Claude Code, Cody, Devin, and others. These systems can now run autonomously for hours, equipped with tools, memory, and iteration loops.
The trajectory is clear. What feels like cutting-edge today will look like autocomplete in 2026.
Why Encoded Knowledge Fails#
Encoding knowledge feels smart. You design a system that takes actions as you would take them. You impart your expertise through careful prompting, detailed instructions, and rigid frameworks. The system runs autonomously, and it feels like you've successfully automated your own thinking.
But this approach optimizes for what you already know. It constrains the system to your current understanding rather than letting it discover better solutions.
The alternative? Give agents general capabilities. Provide access to a computer, tools, and the ability to learn from data. Let them research, experiment, and build their own tooling. Just as AI agents can discover and integrate open-source libraries faster than any human, they can discover and create solutions we haven't considered.
Think of it like a self-driving car. You input the destination - get to the airport - and let the system figure out the route. Don't encode turn-by-turn directions. The agent with general methods and sufficient compute will find better paths than you could program.
The Two Paths of 2026#
Software development is splitting into two simultaneous transformations: how we build and what we build.
How We Build#
The fastest-growing companies in tech are now in code generation. Cursor, Claude Code, Devin, Lovable, Bolt - these agentic systems are becoming the primary interface for development work. The pattern is consistent across platforms: heavy file operations, web search, code execution, and autonomous iteration.
The shift is from human-driven, top-down development to agent-centric workflows. Instead of designing architectures and steering agents through execution, developers are increasingly setting goals and letting agents determine implementation.
What We Build#
The bigger change is in the nature of software itself. We're moving from no-code builders to agents writing bespoke software at the moment it's needed.
Consider an accounting system. Rather than building a monolithic application with predetermined workflows, you define the goals and outcomes. The agent determines the steps, validates its work, and constructs tools on demand. If it needs a specific calculation module or data transformation, it writes it. If it needs an API, it builds it.
This isn't speculative. The models released 12-18 months after the Claude 3.5 Sonnet era are already capable of reliable code generation and extended autonomous operation. The next era will feature agents writing tools for themselves and other agents.
The Inevitable Conclusion#
This isn't preference or laziness. It's mathematics. In any domain where data exists, general methods at scale beat encoded knowledge every time.
The 2026 shift flips the script on software architecture. Currently, humans design, agents build. We choose frameworks, design architectures, and fix the agent's approach along the way. The emerging model is agent-driven: agents decide they need a web application, build APIs as infrastructure, and provision resources dynamically.
Architecture will emerge from need rather than predetermined structure. Agents will become the infrastructure. The boundary between application and infrastructure will blur because the agent can generate both on demand.
Adaptation and Leverage#
Change this rapid creates anxiety. But the developers who internalize these lessons - who shift from encoding knowledge to leveraging computation, from rigid frameworks to flexible agent capabilities - will have disproportionate leverage in what gets built over the coming years.
The bitter lesson isn't just about AI research. It's about how we work. Computation at scale wins. Agents that generate their own tools beat systems constrained by human foresight. And we're only at the beginning of what's possible.
Frequently Asked Questions#
What is the Bitter Lesson in AI?#
The Bitter Lesson is an essay by AI researcher Rich Sutton, published in 2019, arguing that general methods leveraging computation consistently outperform approaches that encode human knowledge. The lesson is "bitter" because researchers repeatedly discover that hand-crafted features, domain expertise, and elegant architectures lose to simpler methods scaled with more compute and data. This pattern has held across chess, Go, speech recognition, computer vision, and now code generation.
Why is the Bitter Lesson relevant to software development?#
The Bitter Lesson explains why AI coding tools are rapidly improving and why that trajectory will continue. Just as Deep Blue beat Kasparov through search and AlphaGo beat humans through self-play at scale, AI agents like Claude Code and Cursor are improving through general capabilities rather than encoded programming knowledge. Developers who understand this pattern can better anticipate how their workflow will change and what skills will remain valuable.
How does the Bitter Lesson apply to AI agents?#
AI agents demonstrate the Bitter Lesson when they succeed by leveraging general capabilities - tool use, web search, code execution, and iteration - rather than relying on domain-specific rules programmed by developers. An agent with access to computation, tools, and the ability to learn discovers solutions that hand-crafted prompts and rigid frameworks cannot achieve. The best agent architectures give models room to explore rather than constraining them to predefined workflows.
What does the Bitter Lesson mean for developers in 2026?#
For developers, the Bitter Lesson means shifting from encoding knowledge into systems toward providing agents with general capabilities and letting them find solutions. Instead of designing rigid architectures, you define goals and outcomes. Instead of writing detailed prompts, you give agents tools and memory. The developers with disproportionate leverage will be those who embrace agent-centric workflows rather than fighting the transition.
What is the difference between encoding knowledge and leveraging computation?#
Encoding knowledge means building systems that take actions as a human expert would - detailed prompts, rigid frameworks, domain-specific rules. Leveraging computation means giving systems general capabilities (search, learning, tool use) and sufficient compute to discover solutions. History shows that leveraging computation wins: chess engines beat grandmasters through search, language models beat grammar rules through scale. The same pattern is emerging in software development.
Related apps#
- Overnight Agents - Spec out AI agents, run them overnight, wake up to a verified GitHub repo.
- Agent Hub - One control panel for Claude Code, Codex, Gemini, Cursor, and 10+ AI coding harnesses. Desktop app for Mac.
Related#
- Subscribe to DevDigest on YouTube for hands-on walkthroughs
Continue Reading#
Get the next deep dive like this in your inbox
One email a week on AI and the rest of the AI dev stack. Free.
Read next
State of AI Coding: April 2026
State of AI coding in April 2026: with 90% of developers using AI tools, here is which tools are winning, what is shifting and which one fits your work.
10 min readThe Agentic Development Tech Stack for 2026
Coding changed more in the past two years than in the previous decade. We moved from manual typing to autocomplete, then to multi-file edits.
12 min readAI Agents Explained: A TypeScript Developer's Guide
AI agents use LLMs to complete multi-step tasks autonomously. Here is how they work and how to build them in TypeScript.
6 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.
