Turing laureate Rich Sutton says LLMs can vary but can't truly discover. The thread disagrees

Sutton argues creativity is variation + evaluation + selective retention — and that an LLM's stochastic sampling only delivers the first. His call to arms: share goals with AI so it can evaluate and select. Practitioners say RL already does all three.

In brief

His claim: a model's trajectory is 'either novel or good — based on randomness or based on data — but never both at the same time.'

The rebuttal that stuck: this describes pretraining, not the RL era. Put a model in a loop with tests and feedback and you have evaluation and selection.

Sutton's argument, in his own words

The source is a post by Richard Sutton — Turing Award winner and a founder of reinforcement learning — quoted at length in the thread. His model of discovery has three parts: variation, evaluation, and selective retention. His contention is that today's AI can do the first but not the rest, and the mechanism he names is stochastic sampling:

"When we ask for a fiction or novelty, the AI can give it to us because its processing is in part stochastic. … The trajectory can be random—and thus novel—or it can be based on the training data—and thus 'good' … but never both at the same time." — Sutton, quoted in the thread

From there he issues a call to arms:

"If we want the full power of AI scientists, then we should share the goals with them so they can create, evaluate, discover … Let's fully automate Creativity and Discovery!" — Sutton, quoted here

The practitioners' rebuttal: that's the pretraining era

The most cited objection said Sutton is describing a paradigm the field has already moved past:

"this argument seems to apply only to the original pretraining era (eg GPT 1-4). The post-training and reinforcement learning paradigms are clearly doing variation, evaluation and selective retention no?" — highfrequency

Someone directly contradicted the "never both" claim on technical grounds: "This doesn't seem true? You can be both random and based on training data." And another argued the missing piece isn't intrinsic to AI at all — it's access to the world:

"in science humans can only do 'evaluation' because they have access to the real world. … so it is not some inherent limitation of AI but rather access to physical realm." — simianwords

The tension inside Sutton's own examples

The thread caught what looked like a contradiction in his framing. Sutton cites Claude Code as having "brought true advances in science, mathematics, and programming" — which several readers found hard to square with the claim that such systems can't truly discover:

"He seems to be saying that Claude Code can make discoveries. … 'these systems have found things that are both novel and good.'" — anabis

One reader was harsher: that the juxtaposition "kind of says he doesn't know what he's talking about." A more sympathetic engineer agreed the loop is what counts: a "plain model sampling outputs obviously isn't doing discovery in the AlphaGo sense. But once you put the model in a loop with tests, feedback, tools or even a human picking the good result, it starts to get much closer."

What the disagreement is really about

Strip away the AlphaGo references and the fight is about where to draw the system boundary. Sutton evaluates the model in isolation — sample, and you get variation without grounded selection. His critics evaluate the system — model plus verifier, plus RL, plus a human in the loop — and find evaluation and selective retention already present. Both can be right: a bare LLM isn't a discoverer, and the deployed loops around it increasingly are. The substantive question Sutton actually poses — how to share a goal precise enough that the machine can evaluate against it — is the one the thread mostly skipped, and it's the harder one.

Get breakdowns like this every day

The top Hacker News stories, unpacked — by email, Telegram, or RSS.

Next story · 6 of 22 Read more
🚀Tech

React Compiler is being rewritten in Rust — 10x faster, and it keeps Babel's AST

The React team merged a full Rust port of the compiler: ~3x faster as a Babel plugin, ~10x faster on the transform itself, with all 1,725 fixtures passing. The surprise design choice — it still speaks Babel's AST as its public API.

★ 119 · 💬 115 · github.com · 3 min