George Hotz thinks neural networks are one of the most beautiful and expressive tools in all of computer science — and he believes we haven't even scratched the surface of what they can do. In a wide-ranging meme review session, the founder of Comma AI went far beyond rating Reddit jokes, offering sharp takes on machine learning, hiring, testing philosophy, and why your IDE might be holding you back. Here's a breakdown of the best moments.
What Does George Hotz Think About Neural Networks?
When a programming meme poked fun at machine learning — suggesting it could never achieve general intelligence — Hotz pushed back hard. His argument: people who struggle with basic object detection tutorials and conclude AI is overhyped are missing the bigger picture entirely.
04:12
George Hotz reacting to the automation meme and giving it an 8 out of 10
Watch at 04:12 →
"It's the same thing with software 1.0," he said. "You sit there and write Hello World and you're like, how is this thing supposed to fly rockets? And it does."
Hotz is deeply bullish on neural networks — not because of hype, but because of the underlying math. He described neural networks as essentially matrix multiplications interspersed with non-linearities. That structure is both extraordinarily expressive and differentiable, meaning gradient-based optimizers actually work on it reliably. That combination, he argued, is why neural nets aren't going anywhere.
His one major open question: the right loss function. He believes we haven't found it yet, and that it will likely look something like compression. He pointed to reinforcement learning experiments like solving Montezuma's Revenge as glimpses of the surprising power still waiting to be unlocked.
12:45
Hotz explaining the neural network matrix multiplication insight during the interview
Watch at 12:45 →
What Are the Real Limits of Neural Networks in AI?
Hotz acknowledged the tension honestly. The limits of neural networks are real — but they're consistently underestimated. The mistake most newcomers make is judging the ceiling of a technology from its floor. A first-year CS student running a toy model doesn't see what scaled infrastructure and the right training signal can produce.
His view: we're still in early innings. The architectures are mature enough. The compute is scaling. What's missing is the loss function that captures something like genuine world understanding. Once that lands, the jump in capability could be dramatic and fast.
For anyone building in the AI space, that's both a warning and an opportunity — don't dismiss the technology because your first model underperformed, and don't assume current benchmarks represent the ceiling.
18:30
Discussion of process replay testing and Comma AI's CI pipeline approach
Watch at 18:30 →
Is Stack Overflow Making Programmers Worse?
One meme took aim at Stack Overflow's notoriously hostile community, and Hotz had a simple response: he has never once asked a question there. His philosophy is to avoid leaving comments on the internet entirely, noting that any comment found under his name probably doesn't reflect his actual views.
But the deeper question the meme raised — whether outsourcing your knowledge to Stack Overflow is dangerous — got a more nuanced answer. He referenced Eric Raymond's classic essay How to Ask Smart Questions, which is required reading for everyone at Comma AI. The premise: the quality of the answer you get depends almost entirely on how well you phrase the question.
Hotz also noted that when asked to compute the integral of 2 to the x on Instagram, his instinct was simply to look it up. There's no shame in that. The issue isn't using references — it's using them as a crutch that prevents you from building genuine reasoning ability in the first place.
Why Do Programmers Over-Automate Everything?
One of the highest-rated memes of the session hit close to home: "Never spend six minutes doing something by hand when you can spend six hours failing to automate it." Hotz gave it an eight out of ten and admitted he absolutely does this.
His take was surprisingly optimistic about the behavior, though. Yes, you end up putting in far more effort than just doing the thing manually. But the learning that happens during those six hours of failed automation is worth it. The attempt itself builds skills, reveals edge cases, and often produces something reusable down the line.
He drew a direct parallel to his own world: you could spend six minutes driving somewhere manually, or you could spend ten years trying to solve self-driving cars. That's the programming spirit — not laziness, but a stubborn refusal to accept that the manual approach is good enough.
Why Do Developers Hate IDE Autocomplete?
Hotz revealed he still uses Emacs, and his reason was blunt: modern IDE autocomplete is "Clippy on steroids." The constant suggestions, the interruptions, the autocorrect-style interference — it's more annoying than helpful for developers who already know what they want to write.
That said, he's not against machine learning improving the IDE experience. He's actually trained large language models on Python and believes ML-assisted bug detection and code suggestion is a genuinely promising application. The difference is between reactive autocomplete that interrupts your flow and a smarter system that checks your work the way a thoughtful code reviewer would.
He pointed to Gmail's smart compose as an example of a dumb-but-useful baseline — even simple language model integration can add real value when implemented with restraint. The goal should be tools that serve the developer, not tools that perform helpfulness.
What Is Process Replay Testing and Why Does It Matter?
When the conversation turned to testing self-driving software, Hotz described a tool Comma AI built called process replay. The idea sounds almost pointlessly simple: run your processes and check that they give the exact same outputs as before.
Why is that useful? Because it enforces honest refactoring. If you claim a change is purely a refactor — no new behavior, just cleaner code — process replay will verify that claim by comparing outputs deterministically. No surprises, no silent regressions.
Comma has run this test over roughly 60 minutes of real driving data. Combined with integration testing that confirms the system actually runs in CI and doesn't output crazy values, it gives the team enough confidence to ship. Hotz rated unit testing as less critical for their use case than this kind of holistic, end-to-end validation.
How Does Comma AI Actually Hire Engineers?
When asked for the magic formula for a great engineering candidate, Hotz didn't hesitate: intelligence and motivation. He acknowledged that testing for intelligence is relatively straightforward — smart people can play dumb, but the reverse doesn't work. Testing for genuine motivation is much harder.
Comma's solution is a paid two-day micro-internship. Candidates come in and work on something real in the codebase. The filter isn't skill — it's whether the person treats it like a checkbox or actually shows up with fire. Are they curious? Do they ask good questions? Is there something driving them beyond the paycheck?
The best candidates, Hotz noted, tend to have already read the open-source Comma AI codebase before ever applying. Since Openpilot is fully open source, anyone can start contributing without being hired. The people who do that on their own are exactly who the team wants to work with.
He also uses deliberately ambiguous interview questions — not trick questions, but open-ended ones — to see how candidates reason through uncertainty. The language they use, the assumptions they surface, and the familiarity they show with the problem space tell him far more than any technical quiz would.
The Bottom Line
What started as a lighthearted meme review turned into one of the more honest conversations about the real culture of software engineering — the over-automation habit, the Stack Overflow dependency, the IDE frustration, and the open question of where neural networks ultimately hit their ceiling. George Hotz's answers weren't polished or PR-safe. They were exactly the kind of direct, slightly chaotic thinking that tends to produce great software.
