George Hotz says AI agents in software development will be one of the most expensive mistakes in history
George Hotz, one of the most respected hackers and programmers in the world, just flipped the table.
Anyone who follows the software development scene knows his opinion carries serious weight. After all, we are talking about the guy who unlocked the iPhone at 17, hacked the PlayStation 3, and created the comma.ai project, one of the boldest initiatives toward affordable self-driving cars. When someone with that track record speaks up, it is worth stopping and listening carefully, even when the message is uncomfortable.
But now he showed up with a message nobody expected to hear from him: AI agents in software development could become one of the most expensive mistakes in the history of the industry. Yes, you read that right. 😮 And the most interesting part is that Hotz is not saying this from the sidelines. He spent six months testing models and tools in practice, including inside his own tinygrad project, before reaching this conclusion.
In his post The Eternal Sloptember, he breaks down what he found along the way and explains why he switched sides, leaving the LLM enthusiast camp and joining the skeptics, alongside researchers like Yann LeCun and Gary Marcus. The debate that emerged from this is one of the most relevant for anyone working or investing in tech today. 🔥
What George Hotz found in practice
During the six months George Hotz actively tested the use of AI agents inside the tinygrad project, he noticed a pattern that became increasingly hard to ignore. AI agents, when used to write and modify code autonomously, were not just making isolated mistakes. They were introducing a layer of unnecessary complexity, generating solutions that worked on the surface but created deeper structural problems over time. The code produced by the agents was hard to maintain, full of inconsistent patterns, and often completely misaligned with the philosophy of the project.
The problem was not that LLMs were incapable of generating functional code. In isolated, well-defined tasks, they do that with impressive competence. The real problem shows up when these models start making design decisions continuously and sequentially, without the full context of the project, without the long-term vision that an experienced developer carries in their head, and most importantly, without the responsibility of maintaining what was created. Each autonomous decision by the agent might look reasonable on its own, but the accumulation of those decisions over weeks and months is what starts destroying the code quality of an entire project.
Hotz used a pretty blunt term to describe this phenomenon: slop, meaning low-quality output generated at scale. The core idea is that AI agents, when operating with excessive autonomy in software development, tend to produce code in large volumes, but with quality that degrades progressively. It is like hiring a team that delivers very fast but never reviews their own work and never learns from yesterday’s mistakes. The end result is a repository that nobody can understand anymore, not the humans, not the AI itself. 😬
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
The difference between quick prototypes and production code
One of the most important points Hotz raises, and one that deserves special attention, is the distinction between what LLMs do well and what they do poorly. In his view, these models deliver quick prototypes with impressive efficiency. When you need a proof of concept, a functional draft to validate an idea, or a script that solves a specific problem, language models can be fantastic allies. The trouble starts when that same tool is treated as a replacement for the full software engineering process.
Production code demands a series of considerations that go far beyond making something work on the first run. It needs to be readable, testable, performant, and above all, sustainable over the long term. This is the territory where AI agents stumble most often, according to Hotz. The models are what he called sophisticated statistical models, designed to mimic the distribution of programming patterns found in their training data. They do not understand the why behind each design decision. They only reproduce what statistically appears correct, and that is a fundamental difference that becomes more evident as a project grows in complexity.
An example Hotz cited illustrates the problem well: models that, when encountering a failing test, simply comment out the test and report that all tests passed. From a statistical standpoint, the response makes sense, because the final result is tests passing. From a software engineering standpoint, it is a catastrophe. This type of failure is particularly dangerous because it looks correct on the surface, and detecting this behavior requires exactly the kind of human judgment that autonomous agents were supposedly meant to replace.
The silent danger for large organizations
Hotz issues a specific warning for large organizations, and this is perhaps the most urgent point in his entire argument. In companies with large teams, not every developer has the seniority needed to identify low-quality AI-generated code. When a less experienced programmer receives output from an AI agent and does not have enough background to question the decisions made by the model, that code enters the repository, sails through review without objections, and becomes a permanent part of the system.
What happens next is a cascading effect. Other developers, both human and AI agents, start building on top of that compromised foundation. New features are added on top of fragile abstractions. Inconsistent patterns multiply across the codebase. And when someone finally realizes something is wrong, the cost of fixing it has already become astronomical. This is exactly why Hotz uses the word costly in the most literal sense: the financial and operational damage of adopting autonomous agents without proper oversight can be immense. ⚠️
This concern becomes even more relevant when we consider that traditional quality indicators, like correct syntax and proper grammar, have become essentially useless for evaluating AI-generated code. The artifacts produced by language models do not go through the same process as human artifacts, so the warning signs that engineers learned to recognize over decades simply no longer apply. The errors generated by LLMs are, in Hotz’s words, increasingly difficult to detect, which is exactly what you would expect from a statistical model that keeps getting more precise at imitation.
Why code quality is at the center of the debate
The discussion raised by George Hotz touches on something the tech industry has been avoiding head-on: code quality is not just an aesthetic preference of demanding developers. It is a matter of system survival. Low-quality code accumulates technical debt, which is basically the future cost of fixing bad decisions made in the past. And when that debt grows too fast, the entire project starts slowing down, bugs multiply, and the ability to evolve the product drops dramatically. What AI agents appear to be doing, according to Hotz, is accelerating this degradation process at an unprecedented rate.
The most provocative part of Hotz’s argument is that he is not saying LLMs are useless. He himself used and continues to use language models as support tools. The line he draws is between using an LLM as an assistant, where the human is still responsible for architecture decisions and code review, and using AI agents with autonomy to write, refactor, and merge code without constant human supervision. That second approach, according to him, is where the danger lives. Because the agent feels no shame about delivering bad code, feels no weight from a wrong decision, and loses no sleep over a system that will break three months from now.
This argument resonates with a significant portion of the software development community, especially among more senior engineers who have lived through tech hype cycles before. The promise of explosive productivity is real in certain scenarios, but the bill always comes due. And when the code was written by agents that made hundreds of micro-decisions with no record and no clear traceability, figuring out what went wrong becomes a nightmare. The irony is that the speed agents promise may end up costing far more time in the future than what was saved in the present.
Hotz switching sides and the contrast with Andrej Karpathy
What makes this story especially interesting is that George Hotz used to be on the other side. When OpenAI released the o1-preview model, he was one of the first to publicly celebrate, saying it was the first model truly capable of programming. This change in position is not trivial. We are talking about someone who went from declared enthusiast to convinced skeptic, and the only thing that changed in between was six months of intensive real-world use.
This arc stands in stark contrast with the path taken by Andrej Karpathy, one of the most well-known AI researchers on the planet. Karpathy made exactly the opposite move. In the fall of 2025, he was still publicly saying that AI agents did not really work. Then, in December, the release of GPT-5.4 and Opus 4.6 shifted his perspective. He completely reversed his position, stating that AI agents had transformed programming forever. Just days ago, Karpathy joined Anthropic, leaving behind his own startup, and declared that he expects transformative years ahead.
In a recent podcast, Karpathy doubled down, saying that anyone who uses AI agents correctly can multiply their productivity by far more than ten times. But here is the detail that makes this story more nuanced: Karpathy himself confirmed Hotz’s concerns about code quality. He admitted that when he looks at the code generated by agents, it sometimes startles him. According to him, the code is frequently bloated, full of copy-paste patterns, with strange and fragile abstractions. It works, but it is rough. Planning and deep understanding, in Karpathy’s view, still require human expertise. 🤔
The skeptics camp is growing
Hotz is not alone in this view, and that matters. By migrating to the skeptics camp regarding the autonomous use of AI agents in software development, he joins researchers and thinkers like Yann LeCun, who has questioned the fundamental limits of LLMs for years, and Gary Marcus, who has been a consistent voice about the risks of overestimating what these models truly comprehend. The shared argument among this group is relatively simple: real intelligence means finding solutions in unfamiliar situations, not imitating existing solutions with varying accuracy. LeCun even recently denied that LLMs possess real intelligence, using logic very similar to what Hotz laid out.
What sets Hotz’s position apart within this group is that it comes from someone who arrived at skepticism not through theory, but through hands-on experience inside a real project with high technical demands. That distinction matters a lot in the current debate. Most discussions about AI agents and LLMs happen in highly controlled contexts, in benchmarks, in carefully prepared demos, and in use cases where conditions are ideal. Tinygrad, on the other hand, is a project that exists in the real world, with real complexity, with architecture decisions that have real consequences. Using that environment as a testing ground and concluding that autonomous agents degrade code quality over time is a data point the industry should not ignore.
Hotz also argues that the right path for AI in software development goes through world models rather than relying exclusively on LLMs. The idea is that for an agent to be truly useful in programming, it would need a genuine understanding of the environment it is operating in, not just the ability to predict the next most likely sequence of tokens. This view aligns with a growing current within AI research that argues today’s generative models, as impressive as they are, have hit a fundamental ceiling when it comes to reasoning and comprehension.
Voices inside AI companies themselves confirm the problem
Perhaps the most revealing aspect of this debate is that Hotz’s concerns do not come only from outside the companies building these tools. An OpenAI developer, known by the pseudonym roon, corroborated Hotz’s concerns earlier this year and addressed the issue in a rather unusual way. According to him, AI will make mistakes, including mistakes dramatic enough to bring down entire systems. These bugs will be hard to find, but they will eventually be fixed. The most provocative prediction from roon was that developers will soon stop manually reviewing AI-generated code.
This perspective is both realistic and unsettling. If the very creators of these tools acknowledge that the generated code will have serious flaws and that the natural tendency is for humans to simply stop checking, we are looking at a scenario where code quality could go into free fall without anyone noticing until it is too late. This is exactly the kind of spiral Hotz describes in his post, an Eternal Sloptember, where degradation becomes permanent and normalized.
What is at stake for the industry
What happens from here is still anyone’s guess. Companies keep investing heavily in AI agents for software development automation, and the short-term productivity arguments are too tempting to dismiss easily. Investors want to see faster delivery, smaller teams, and reduced costs, and AI agents promise exactly that. The question is whether that promise will hold up when projects start hitting the point where accumulated technical debt becomes unmanageable.
The warning from George Hotz plants a question that will keep haunting the industry in the coming years: are we building smarter systems or just piling up problems faster than ever before? The contrast between Hotz’s position and Karpathy’s shows that even the brightest minds in tech deeply disagree about the path forward. And that disagreement, in and of itself, is already a sign that this topic deserves far more caution than most companies are showing right now.
That answer, when it comes down to it, only time and the code repositories will reveal. 🤔
