Geohot on LLMs: Real productivity, real limits, and why he bets against the doom narrative

Most AI productivity takes come from people with something to sell. The optimists are selling tools, the pessimists are selling anxiety. George Hotz is in neither camp: he runs comma.ai and tinygrad, builds with open-weight models daily, and has been publicly skeptical of AI hype since before it was fashionable.

His latest essay is worth reading carefully because it separates three things most coverage conflates: whether LLMs are useful now, whether the productivity gains are as large as vendors claim, and whether any of this implies a path to superintelligence. His answer is yes, no, and no.

What happened

The essay, published June 21, 2026, partly walks back his earlier post, The Eternal Sloptember, where he was harder on models' ability to program. His revised position: he was probably too harsh, programming itself is changing, and using agents is a skill he is actively getting better at.

He describes setting up a local Linux environment running opencode against GLM-5.2 hosted on Hugging Face. A natural-language command to install and configure tmux worked without any manual steps. His verdict, phrased as a joke: "the Year of the Linux Desktop is finally here."

The second half attacks two patterns he thinks are doing damage. First, the claim that developers are "falling hopelessly behind" and will form a "perpetual underclass," which he reads as fear marketing. Second, the leap from "models are useful" to "superintelligence is near," which he treats as a valuation argument disguised as a technical prediction.

[ Free report ]

The Agentic SDLC

How teams like Stripe, Ramp, and Uber move from solo coding agents to a coordinated, team-level system.

Download the guide

Key features

The essay's claims, roughly in order of practical relevance:

• Local agents work now: opencode plus an open-weight model handled real system administration without a cloud API. The workflow is reproducible by anyone with a capable machine.
• Gains are real but bounded: Hotz says he gets "some boost from the models." He references a discussion of Linus Torvald's skepticism on productivity claims as context for where the community is landing on this, without endorsing any specific multiplier.
• Using agents is a skill: He says he is "pretty confident I'm getting better at using them" after sustained experimentation. Slow results early are expected, not a verdict on the tools.
• Watch the fatigue cost: He links to a piece on cognitive fatigue as a real counter-weight to raw speed gains. Faster code generation does not mean faster shipping if review load climbs proportionally.
• Vibe-coded output is still slop: His test for whether AI productivity claims are real: where is the flood of magical new software those gains should have produced? He does not think the output matches the claimed input gains.
• AI progress tracks Moore's Law: he attributes it to general computing advances rather than to any single lab's research breakthroughs.

Why it matters

Hotz's valuation argument is the part I'd flag for teams making tooling decisions. He has argued since 2025 that AI will create enormous value, but frontier labs will not capture it, because open-source commodification is the natural end state. Betting workflows on hosted frontier APIs carry lock-in risk that open-weight options do not.

The fatigue point deserves more attention than it usually gets in coverage of agent productivity. Review load, context-switching, and the cognitive cost of validating AI-generated code are real costs that do not appear in token counts or completion speed benchmarks. If Hotz is right that gains are "some boost" rather than 10x, those hidden costs shrink the net gain considerably.

Example use case

The one Hotz ran himself: a Linux box, opencode as the agent frontend, GLM-5.2 served locally from open weights. He issued a natural-language instruction to install and configure tmux, and the agent handled it. No cloud dependency, no per-token billing, no code leaving the machine.

For teams evaluating local agent setups, this workflow is reproducible today. Start with system configuration or environment setup tasks where mistakes are cheap, and the ground truth is easy to verify. You do not need a frontier model to handle standard Linux tooling, and starting there gives you an honest read on what the local setup can actually do before you push it to harder tasks.

Competitive context

The essay's implicit comparison is between two mental models for AI tooling. One treats agents as a harbinger of superintelligence, a framing that frontier labs benefit from because it justifies their valuations. The other treats agents like regexes, Stack Overflow, or compilers: tools that accelerate specific tasks, carry known failure modes, and improve with practice.

Hotz's position on open versus closed models is direct. He thinks anti-open-source arguments from labs are fundamentally about protecting margins from commodification, sometimes dressed up in safety or geopolitical framing. Whether that reading is correct or not, the practical implication is the same: open-weight models like GLM-5.2, paired with open agents like opencode, are already capable enough for real workflows, and that capability will not decrease.

My take

What I find useful in the Hotz framing is the calibration it offers between two genuinely unhelpful positions: "AI will replace all programmers immediately" and "AI is useless hype." He lands somewhere more boring and more accurate: it is a learnable tool with real but bounded returns, and the doom narrative is mostly doing work for lab valuations rather than for developers.

The part I am less sure about is how universal his local-agent results are. Running opencode against GLM-5.2 on a self-built Linux box, configured by someone who built tinygrad, is not the same experiment as a mid-level developer running on a Mac. The gap between his experience and the median developer's setup matters for how far you generalize the "local agents work now" claim.