Blog: The Bitterest Lesson

TL;DR TypeSafe's 2026-09-10 post extends Sutton's bitter lesson: "doing the right task > data > compute > algorithms." The worked example is InstructGPT — a GPT-2-sized model trained on the right task beat GPT-3 — and the implied conclusion for TypeSafe is that picking a new task (calibrated decisions for software) matters more than scaling on the old one.

Facts

The argument

Start from Sutton. "Rich Sutton's bitter lesson states that compute beats algorithms. Researchers want to encode their clever ideas about intelligence into machines. Yet over and over, the approaches that win are the general ones which leverage more computation. Search beat hand-built chess knowledge. Neural networks beat hand-built vision features. The lesson is bitter because researchers love algorithms, yet cleverness matters less than scale."

Then extend it. "My experience is that Sutton's bitter lesson is the tip of an iceberg of bitterer lessons: beyond compute and algorithms, there's data and even picking the right task to do ML on. The bitterest lesson in ML is that doing the right task > data > compute > algorithms."

Why games mislead. Sutton's lesson "is easiest to see in games because there are two major differences to the real world: the right task is obvious (follow the rules to win or maximize score), and [data] can be endlessly generated through self-play (through compute)." (The captured text is garbled at this point; the bracketed word is what the sentence structure requires — inferred.) With task and data free, compute is what is left to matter.

Who picks the objective. "At the end of the day, machine learning makes reward go up or loss go down. Someone still has to decide the objective to optimize though. Getting this right requires understanding the external system in which the model will operate. Without the right task, everything can work perfectly, with the most beautiful loss and scaling curves, but the model may still be useless!"

Why the field gets the order backwards. "Researchers love inventing algorithms. More recently, we have learned to love scaling curves. Meanwhile, data is messy. Choosing the right task often requires leaving the ML problem entirely to study users, products, organizations, or whatever part of the world is supposed to benefit."

Not an anti-scaling argument. "This is not an argument against scale. Once the task and data are right, scale is incredible. It is an argument against treating scale as the be-all and end-all."

The InstructGPT evidence

"We learned this lesson at OpenAI when making InstructGPT/RLHF: GPT-3 was an incredible model trained to predict the next token on internet text, but people wanted something that followed instructions more than they wanted a super-powered autocomplete. GPT-2-sized models (>100x smaller than GPT-3) trained on the right task, even with the dumbest algorithm and barely any compute, destroyed GPT-3."

The post annotates "figure 31 from the InstructGPT paper" and adds the extrapolation: "Scaling pre-training would need to reach roughly GPT-7 level to beat even that baseline, and GPT-9 to beat InstructGPT built on GPT-3." Three footnote markers hang off "the right task", "the dumbest algorithm", and that extrapolation; the footnote bodies are not in the capture.

Closing line: "You get what you optimize for and the bitterest lesson in ML is that the most important part of it isn't ML at all."

Why it matters for building with Jev

The post never mentions Jev or RLCD. Read as company positioning, it is the research-direction argument behind them: if the task ("produce text a human prefers") is wrong for software, a bigger model trained on that task does not fix it — you change the task. That is what RLCD claims to do, optimizing "epistemically honest probabilities" instead of preference; see Blog: Introducing System One Models & Jev (2026-09-15) and AI primer: why calibrated decision models. The practical echo in the docs is the advice to decompose a judgment into atomic questions: choosing what to ask is most of the work (How to build software with System One).

Related

• Manifesto: Composable AI — Build Prod, Not God — the same argument at company scale
• Blog: Lies, Damned Lies, and Benchmarks — companion post on measurement
• AI primer: why calibrated decision models — RLHF vs RLVR vs RLCD
• Blog: Introducing System One Models & Jev (2026-09-15) — the product this thinking produced
• TypeSafe AI (company) — the company

Sources

• raw/site/blog-bitterest-lesson.txt (https://typesafe.ai/blog/bitterest-lesson)