George Hotz Calls Coding Agents a Costly Mistake. He's Right About Who Pays

• Book: LLM Observability Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

"I'm calling it now, the adoption of AI agents into software development will be one of the most costly mistakes in the field's history." That's George Hotz, opening The Eternal Sloptember on May 24, 2026. Decrypt and The Decoder covered it the next day.

The post is five months old now. The line from it I keep coming back to: "The output is broken, but in a way that's getting harder and harder to detect."

Most replies at the time argued about whether Hotz is right that agents can't program. I think that's the less interesting part. The sharper claim is buried a few paragraphs in, and it's about who catches the breakage.

What Hotz actually said

Hotz didn't write this from the sidelines. He says he spent about six months trying to make agents work, across models, harnesses and prompts. He used them on parts of tinygrad, his deep learning framework, and on reverse-engineering the firmware of a USB-to-PCIe chip. Each time, he writes, he felt he could have done it better and faster by hand.

His description of the pattern will sound familiar if you've run an agent on a real codebase. In his words, "the agent frontloads all the progress." Most of the work appears fast. Then you're pulling a slot machine lever, hoping the last stretch of polish shows up. In his telling, it never quite does.

Strong engineers, he argues, read code carefully and keep correcting it, and that acts as a self-check. "The bottom performers won't have that self check." Those are the people who can now turn out far more code than before, and he expects the average quality at large companies to drop as their volume rises. He also asks: "Do you think macOS will get better or worse in the next 2 years?"

Hotz also says he is now in the "LeCun/Marcus camp" (The Decoder): he thinks real programming agents will need world models, not better language models.

The optimist says the same thing

Andrej Karpathy sits on the other side. He has argued that agents have already changed how software gets written. Five days before Hotz's post, he joined Anthropic's pre-training team (Decrypt).

Here is Karpathy at Sequoia's AI Ascent 2026, in a talk with Stephanie Zhan that The Decoder quoted in its coverage. Looking at what agents write, "sometimes I get a little bit of a heart attack because it's not super amazing code necessarily all the time. And it's very bloaty. And there's a lot of copy-paste. And there's awkward abstractions that are brittle." (transcript)

In the same talk, he says what the human is left holding: "You basically still have to be in charge of the aesthetics, the judgment, the taste, and a little bit of oversight." And he paraphrases a tweet: "you can outsource your thinking, but you can't outsource your understanding."

Put the two quotes side by side. The pessimist says the output is broken in ways that are hard to see. The optimist says the output works but is bloated, copy-pasted and brittle, and that a human with understanding has to stay in charge. They disagree about the trajectory. They describe the same code.

Hotz and Karpathy describe the same defect. What differs is who looks closely enough to see it.

The model isn't the one who pays

The cost Hotz predicts lands at an approval. Somewhere, a person who can't tell brittle code from good code clicks merge on a diff that looks fine. The model produced the bug; the approval is what lets it into production, and the team that runs that code is the one that pays.

Hotz's own framing points there. High performers catch the errors because they know what correct looks like in that codebase. Karpathy says the same in his own words: you can't outsource the understanding. Neither of them says the fix is a better model.

So the knob most teams turn is the wrong one. Agent rollouts get planned by seat count: who gets a license, how many tasks a day, which agents are allowed. None of that says anything about whether the person approving the diff could have written it.

The knob I'd turn instead is autonomy per area of code, tied to how well the reviewer knows that area:

None of this needs new tooling to start. GitHub already lets you route review by path. A CODEOWNERS file in .github/ names who owns what:

# Agent or not, these paths need someone who knows them
/src/billing/     @your-org/payments
/src/auth/        @your-org/identity
/firmware/        @your-org/firmware

Turn on "Require review from Code Owners" in the branch protection rule, and a diff touching billing can't land without an approval from the team that owns billing. The rule doesn't care whether a human or an agent wrote the diff, only whether someone from that team signed off.

Where Hermes fits

I build Hermes IDE, so weigh this section with that in mind. Hermes is a desktop app that runs agents like Claude Code and Codex in their own terminals, each task on its own hermes/<name> branch and worktree.

The part relevant here is review. Hotz's complaint is partly about size: the agent frontloads a lot of change, and a big diff is where breakage hides. Hermes saves every agent turn, so you can diff or restore a single turn, with undo. The Review Desk (⌘G, Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file, with risk flags, and you can send a line comment back to the agent that wrote the line.

The Review Desk (⌘G) in By turn view: two Claude Code turns, turn 1's diff of src/db.ts, the changed files and a commit message drafted from the turns.

Reading turn by turn maps onto the table above. An owner can let the agent take bigger turns and read each one as it lands. Someone newer to the code can keep turns small and push questions back as line comments instead of approving what they don't follow.

Hermes doesn't know whether the code is right. Risk flags point your eyes somewhere; they don't replace knowing the codebase. Hermes is free to download, source-available under BSL 1.1 (GitHub), and runs on macOS, Windows and Linux. It isn't affiliated with Nous Research or its Hermes Agent.

Where I think Hotz goes too far

"Agents cannot program" is a claim about the model. His evidence is about the work: a framework he wrote and knows deeply, and firmware reverse-engineering, which is about as far from boilerplate as code gets. On that work, he was the reviewer best placed to see what the agent got wrong, and he decided he'd rather do it himself. That's a reasonable call for him. It doesn't follow that nobody should use agents anywhere.

Karpathy's position covers the other case: agents are useful, and the human still owns the judgment. Both positions fail in the same way when the human approving the code doesn't have that judgment for the code in front of them.

If Hotz's prediction comes true, it will come true one merge at a time, approved by someone who couldn't have written the diff, on a team that counted its rollout in seats.

How does your team decide who can approve agent work today: by seniority, by code ownership, or not at all? Tell me in the comments.

If this was useful

Hotz's warning is about breakage that gets harder to detect, and detection is a measurement problem as much as a review one. The LLM Observability Pocket Guide covers the tracing and evals tools that tell you what an LLM system actually did, so you're not relying on a diff that merely looks fine. If you want to review agent turns one at a time, Hermes IDE is free on macOS, Windows and Linux.