George Hotz was right. We are stuck in the Eternal Sloptember, and all your beloved open-source projects are submerged in machine-generated nonsense.
Recently, I have been closing a large number of pull requests at work. It's not that the code is inoperable. It's that it seems as if a specification was thrown into a blender, the "working" code was then tipped out, and no human was meant to ever maintain it.
The Thesis
In May 2026, George Hotz released "The Eternal Sloptember", which is a perfect title. Usenet suffered from the Eternal September — when AOL flooded the network with clueless newcomers faster than the community could socialize them. We have the same situation now, except the newcomers are tireless coding agents that never update from review feedback.
The problem isn't that agent code doesn't compile. It does. The problem is that it compiles confidently while being architecturally braindead.
The Evidence Is Piling Up
Linus Torvalds has threatened to revert AI-generated kernel patches submitted at the wrong time and is taking a harder line on trivial AI-generated fixes. Let that sink in. The Linux kernel — the project with the most battle-hardened review process on Earth — is dealing with bloat from a flood of AI-driven trivial fixes.
While I have immense respect for Andrej Karpathy, and have appended all sorts of gross spaghetti to an execution of TensorAgentCompiler somewhere along the line, I can’t help but note that "gross but productive" is how you get a codebase that’s easy to add to and impossible to change. Technical debt with a turbocharger. 🚀
Why Reviewers Can't Keep Up
Here's the systemic issue nobody wants to talk about:
→ Agents produce code 10-50x faster than humans can meaningfully review it
→ Review fatigue is real — after the 8th AI-generated PR today, you start skimming
→ The slop looks reasonable at a glance, so it passes lazy review
→ Each merged slop-PR raises the baseline complexity for the next reviewer
It's a ratchet. It only goes one way. Each “good enough” merge makes the next review harder, which makes the next lazy approval more probable.
The Uncomfortable Middle Ground
I am not an AI pessimist. I leverage coding robots all the time. They're incredible for boilerplate, tests, and exploratory prototyping.
Certainly, there is a distinction between me utilizing an agent within my editor — in which I analyze every line before it branches — and an independent agent opening PRs against projects as maintainers rest. The first one is a tool. The second one is a pollutant. 😤
The productivity improvements that Karpathy is arguing for exist, in the mind of the person writing the code. They're negative for everybody else downstream. That’s an externality, and we are really bad at pricing externalities in open source.
What Actually Helps
I don't have a silver bullet. But I know what's working in my corner:
→ Mandatory human attestation on every PR — "I read this, I understand this, I own this"
→ Smaller diffs, always — if an agent generates 600 lines, split it or rewrite it
→ Treating agent output as a draft, never as a contribution
→ Review tooling that flags statistical patterns of generated code
The culture shift matters more than the tooling. We should not consider "an agent wrote this in 30 seconds" as a display of skill, but rather as an indication of a problem.
The Real Question
Hotz's diagnosis is correct. The ocean of slop is already here. What I'm more uncertain about is whether we will quickly develop an immune cultural response, or if we will simply acclimate to the decay until every new codebase feels like legacy inherited on day one. 🫠
So here's what I want to know: has your team already hit a wall with agent-generated code quality, or do you think the tooling will catch up before it matters?
