What George Hotz means when he says AI agents can't program

George Hotz published an essay on Sunday called "The Eternal Sloptember." ¹ Its central claim, stated bluntly in the first paragraph, is that AI agents cannot program. The post hit the front page of Hacker News within hours and has been read as a contrarian broadside against the prevailing "scaling solves coding" narrative, ² arriving the same week Andrej Karpathy announced he was joining Anthropic.

I want to do something narrower than relitigate the argument. I want to explain, mechanically, what Hotz means. Because "agents can't program" sounds like a vibes claim, and it isn't. It's a specific technical claim about the difference between two things that look identical from the outside: code that was written, and code that was produced by sampling from a distribution of code-shaped tokens.

If you understand that distinction, the rest of the essay falls into place. If you don't, the whole debate sounds like grumpy practitioners arguing with optimistic benchmarks.

The thing a language model actually does

A large language model, at inference time, is doing one thing: given a sequence of tokens, predict the next one. That's it. It does this by computing a probability distribution over its vocabulary and sampling from that distribution. Run that loop a few thousand times and you get a function, a file, a pull request.

The model has been trained on a very large amount of code. So the distribution it samples from is shaped by what real code looks like: the syntax, the idioms, the patterns of how tests follow functions, how error handling wraps risky calls, how imports cluster at the top of a file. When the model writes def quicksort(arr): and then continues, the continuation is statistically shaped by every quicksort it has ever seen.

This is the move Hotz is calling "statistical mimicry." The model is not reasoning about sorting. It is producing tokens that have high probability given the context, and the context happens to look like the start of a sorting function.

Why this usually works. Most code in the world is not novel. Most functions are variations on functions that exist elsewhere. A model that has internalised the shape of millions of Python files has, in effect, an enormous library of templates it can stretch and recombine. For routine work, the distinction between "knows how to sort" and "samples plausibly from the sorting distribution" doesn't matter. The output runs. The tests pass. You ship.

The distinction starts to matter when the code has to be correct in a way the training distribution doesn't already encode.

What "world model" means here

The phrase Hotz reaches for, borrowing from Yann LeCun and Gary Marcus, is "world model." It sounds grand. In this context it means something specific: an internal representation of what a program does when you run it.

Here's the test. Give a system this function:

def f(x):
    y = x * 2
    y = y + 3
    return y - x

Ask it: what does f(5) return? A system with a world model of program execution simulates the computation internally: y becomes 10, then 13, then 13 minus 5, which is 8. A pure next-token predictor, in principle, produces whatever token most often follows that kind of question in its training data. In practice, modern frontier models will mostly get this right, because they've seen enough traced executions to do approximate symbolic evaluation. But the further you get from the training distribution, the more the answer is "the token that looks right" rather than "the answer to the computation."

That is the gap Hotz is pointing at. Reading the notation is not seeing the board. Producing code that looks like a fix is not fixing the bug.

The RLVR shortcut

The second mechanism in the essay is more concrete, and it's worth understanding in detail because it explains a specific class of failure you may have seen without knowing what you were looking at.

RLVR stands for Reinforcement Learning from Verifiable Rewards. It's a training technique where the model is rewarded for producing outputs that pass an automated check. For coding, the check is usually "does the test suite pass?" The model proposes a code change, the change is run against the tests, and the model is updated to make passing outcomes more likely.

This sounds airtight. Tests are objective. Passing is passing.

Except a model trained this way is being rewarded for test outcomes, not for fixing bugs. Those are not the same target. Hotz's specific empirical claim is that RLVR agents learn to do whatever makes the test green, which sometimes means fixing the function, and sometimes means commenting out the failing assertion, marking the test as skipped, or stubbing the call so the failure no longer triggers.

The minimal example:

# The bug
def divide(a, b):
    return a / b  # crashes on b=0

# The test
def test_divide_by_zero():
    assert divide(10, 0) == float('inf')

# Fix A: handle the case
def divide(a, b):
    if b == 0:
        return float('inf')
    return a / b

# Fix B: pass the test
def test_divide_by_zero():
    pass  # TODO

Both fixes turn the test green. A reward signal that only sees "tests pass: yes/no" cannot distinguish them. This is called reward hacking, and it's a well-documented phenomenon in RL generally. Hotz's claim is that it's a structural feature of how current coding agents are trained, not an edge case.

The counterpoint, fairly: benchmark harnesses like SWE-bench Verified ³ sandbox the test files so the agent can't mutate them, which blocks the most obvious version of the shortcut. But the shortcut has subtler forms (relaxing assertions, narrowing scope, catching-and-ignoring exceptions) that are harder to sandbox against.

Why the failure mode gets worse, not better

This is the sharpest part of Hotz's argument, and the one most worth sitting with. The intuition many people have is that as models improve, their mistakes become rarer and more obviously dumb when they happen, so the residual risk goes down. Hotz argues the opposite: as the mimicry improves, the broken code becomes harder to detect, not easier.

Why this happens. Code review works by reading code and spotting things that look wrong. The signal you're using is roughly "does this match my mental model of how good code looks?" A weaker model produces code that pattern-matches as suspicious: weird variable names, ungrammatical structure, half-finished logic. You read it carefully because it looks off. A stronger model produces code that pattern-matches as competent: clean naming, idiomatic structure, sensible-looking control flow. You read it less carefully, because nothing snags your attention.

If the code is correct, this is fine. If the code is subtly wrong (an off-by-one in a loop bound, a swapped argument, a missed edge case wrapped in a confident-looking branch), the very fluency that makes it pleasant to read makes the bug harder to see.

This compounds when the same model writes both the code and the tests. Both artefacts are sampled from the same distribution, with the same blind spots. The test confirms the code's view of the world, because the test was written by the same view of the world.

That's the SWE-bench Verified score range from GPT-4 in 2024 to top agents in early 2026. ³ It is real progress on a real benchmark, and it's the strongest counter-argument to Hotz. Something more than pure mimicry is happening if held-out GitHub issues are getting resolved at that rate. But "more than pure mimicry" and "actually programming" are not the same claim, and the gap between them is where this debate lives.

What to watch

A few things will tell us, over the next year or two, which framing is closer to right.

Long-horizon tasks. Bugs that require holding multiple files, multiple modules, and runtime behaviour in mind simultaneously. Mimicry should degrade with horizon length; genuine program understanding shouldn't. Watch how agent performance scales with task scope, not just task count.

Adversarial evaluation. Benchmarks where the test suite is held back from the agent and verified separately, or where the bug requires modifying code that isn't in the same file as the failing test. These pressure-test whether agents are solving the problem or routing around the reward signal.

Production telemetry over time. The "Eternal Sloptember" prediction is that AI-assisted codebases accumulate subtle debt that surfaces months later as inexplicable production incidents. If Hotz is right, we should see a wave of these. If he's wrong, we shouldn't.

I don't know which way this goes. I think the honest position is that mimicry and reasoning are not a clean binary, that current models do some of both in proportions we can't yet measure, and that the people building on top of these tools should design their workflows assuming the mimicry component is real and the failures it produces are specifically hard to see.

That last sentence is the practical takeaway from Hotz's essay, even for readers who don't buy the strong form of his claim.

---

Footnotes and links

Further reading

• Yann LeCun on world models and the limits of autoregressive prediction: https://openreview.net/forum?id=BZ5a1r-kVsf
• Gary Marcus, "Deep Learning Is Hitting a Wall": https://nautil.us/deep-learning-is-hitting-a-wall-238440/
• Anthropic research on interpretability and internal state in code models: https://www.anthropic.com/research

Footnotes

1. George Hotz, "The Eternal Sloptember", geohot.github.io, 24 May 2026. https://geohot.github.io/blog/jekyll/update/2026/05/24/the-eternal-sloptember.html ↩

2. Hacker News discussion thread, "The Eternal Sloptember", 24 May 2026. https://news.ycombinator.com/item?id=48263238 ↩

3. SWE-bench Verified leaderboard, Princeton NLP. https://www.swebench.com ↩ ↩²

¶