DHH on the Boundaries of AI Coding: Which Scenarios Allow 100% AI-Generated Code

In a deep conversation with Lex Fridman, DHH (David Heinemeier Hansson) — the creator of Ruby on Rails and co-founder of 37signals — shared his latest assessment of AI coding capabilities and their boundaries. As a veteran developer who went from skepticism to being "completely convinced by AI," his observations are particularly noteworthy: AI can already generate 100% of production code in certain domains, yet in other scenarios, it's surprisingly difficult for AI to fully take over.

37signals is an influential "counter-mainstream" company in the tech industry. While Silicon Valley chases venture capital, hypergrowth, and IPOs, 37signals has steadfastly adhered to a philosophy of bootstrapping, small teams, and profitability-first. Its flagship product Basecamp is one of the pioneers in project management, while HEY is a product that attempts to redefine the email experience. DHH himself not only created Ruby on Rails — a framework that powered the early tech stacks of Twitter, GitHub, Shopify, and other tech giants — but is also known for his outspoken technical opinions. He has publicly criticized microservices architecture, opposed TypeScript, questioned the cost-effectiveness of cloud computing, and led 37signals' migration from the cloud back to self-hosted servers. Precisely because DHH has long maintained a cautious, even skeptical attitude toward new tech trends, his shift from "questioning AI" to "being completely convinced by AI" carries that much more weight — this is not someone easily swayed by tech hype.

A World of Difference: AI Coding Capabilities by Domain

DHH first pointed out that the domains programmers work in vary enormously, and AI's maturity level differs just as dramatically across them. He roughly categorized development work into several tiers.

The most common — and the area where AI excels most — is CRUD applications in web development: there's a database, a user-facing interface, and data flowing back and forth between the two. Whether these systems serve one person, a handful of people, or the entire world, AI handles them extremely well.

CRUD stands for Create, Read, Update, and Delete — the four fundamental data operations. The core logic of virtually every web application can be boiled down to combinations of these four operations. From product management on e-commerce platforms to social media post publishing, from enterprise user administration to content management systems, CRUD operations make up the largest share of web development work. Because these applications follow highly standardized patterns — forms collect data, APIs transmit data, databases store data, interfaces display data — there's an enormous corpus of open-source code and tutorials for training data, enabling AI models to understand and generate this type of code with exceptional precision. The Ruby on Rails framework itself was designed to simplify CRUD development, and its "convention over configuration" philosophy makes standard web application development highly pattern-driven — a perfect match for AI's strengths in pattern recognition and reproduction.

"For that domain, you can truly get to 100% of the code written by AI. If you're a good programmer with solid intuition about what's happening behind the scenes, you can completely skip looking at the code."

He emphasized that the key here is whether a developer can intuitively judge if everything is working correctly through "the ripple effects and symptoms of the system." For safety-critical systems — like nuclear power plant controls or self-driving cars — code needs to be reviewed much more carefully.

AI's Superhuman Performance in Security Vulnerability Discovery

When it came to security, DHH offered a counterintuitive observation: AI's ability to discover and fix security vulnerabilities has become staggeringly strong — even surpassing the vast majority of human experts.

He cited a particular model (the "Fable" incident mentioned in the conversation) as an example — its vulnerability discovery capabilities were so powerful that "releasing it directly would be unsafe." The reason is that many critical security vulnerabilities aren't single-point issues but require combining multiple seemingly harmless small vulnerabilities into a "combo chain":

"You find a small vulnerability here — on its own, it might not amount to much. But you combine it with four others, and suddenly it becomes an RCE (Remote Code Execution). Humans who can do that are exceedingly rare."

RCE (Remote Code Execution) is one of the most severe vulnerability types in cybersecurity. An attacker can execute arbitrary code on a remote server without physical access to the target device, thereby gaining complete control of the target system. The "combo chain" DHH mentioned is known in the security field as an "Exploit Chain," a common technique in Advanced Persistent Threat (APT) attacks. A single vulnerability might only be a low-severity information disclosure or privilege escalation, but chaining multiple vulnerabilities together can create a complete attack path from an external network straight to internal core systems. Traditionally, security researchers capable of constructing such exploit chains number no more than a few hundred worldwide, typically working for national-level cybersecurity agencies, elite red teams at top security firms, or the Bug Bounty hunter community. AI's breakthrough in this area means the barrier to vulnerability discovery is being fundamentally reshaped — a boon for defenders, but also a seismic shift in the offense-defense landscape.

He noted that humans with this capability typically operate within state-sponsored organizations or covert operations, and now AI has become "so good at that." This means that in highly specialized intellectual tasks like security vulnerability hunting, AI has reached a level that virtually no human can match.

From Linux Distro to 100% AI-Generated Code in Practice

DHH candidly shared that what completely changed his mind was his own Linux distribution project — Omarchi (the Umachi/Quattro version mentioned in the conversation). Over the past three months of developing the latest Quattro version, the AI agent's "acceleration ratio" was close to 100% almost from the start, and in the last two months it reached a full 100%.

"Not a single line of code shipped in Quattro was written by my hand. I reviewed the overall shape of all the code, reviewed every line of every critical part of the system's model layer. But a large amount of UI code and supporting code — I didn't look at any of it."

This is a remarkable statement. As the author of Rails, DHH has exceptionally high standards for code quality, yet he's now willing — in a system-level project that demands speed and fine-grained control — to let AI handle all the coding while he only does architecture-level review. His approach reveals a new collaboration model: humans handle architecture and critical path review, AI handles all code implementation.

The Unexpected Challenge with Large Web Products: Architecture Gets Destroyed by Vibe Coding

Interestingly, DHH found that what's truly difficult to fully hand off to AI is precisely those seemingly simple, mature web products. 37signals' Basecamp and HEY have large user bases and relatively substantial codebases, and they've proven "surprisingly difficult to fully accelerate with AI agents."

Large legacy codebases are one of the thorniest challenges in software engineering. After years of iteration and dozens or even hundreds of developers having worked on it, a codebase accumulates a wealth of implicit conventions, historical decisions, and technical debt. This information often doesn't exist in any documentation — it's embedded in the code structure, naming conventions, module boundaries, and test cases. The core difficulty AI models face with such codebases is this: they can understand the syntax and local semantics of every line of code, but they struggle to grasp the "architectural intent" of the entire system — why a particular module was designed a certain way, why certain features were deliberately separated, and which seemingly redundant abstraction layers actually carry critical extensibility concerns.

He shared a deeply instructive case study. During a sprint for Basecamp 5, the team once thought they'd found the solution — let designers do the programming directly, since they knew exactly what features they wanted and what form they should take, so "let them vibe code to their hearts' content."

Vibe Coding is a concept coined by Andrej Karpathy — former OpenAI researcher and Tesla AI director — in early 2025. It refers to developers no longer writing code line by line, but instead describing the desired functionality and "feel" to AI in natural language and letting AI generate the complete code implementation. The developer's role shifts from "code writer" to "intent communicator" — you only need to describe what kind of interaction experience or interface effect you want, and AI converts those fuzzy "vibes" into concrete code. This approach dramatically lowers the barrier to programming, enabling designers, product managers, and even people with zero coding experience to rapidly build functional prototypes.

"We ended up with a bunch of PRs that, individually, each made sense at a given moment. But taken together, they destroyed the system's architecture. We had to clean up manually, mop it up by hand, by human hand, to get back to an architecture that felt coherent and consistent."

This is precisely the greatest risk of vibe coding: it optimizes for the local optimum of individual features rather than the global consistency of the entire system. Each independently generated PR may work correctly on its own, but the architectural assumptions they each make may contradict one another, ultimately causing the system's overall architecture to degrade — like haphazardly adding rooms onto a carefully designed building until the entire structure becomes unbalanced.

This leads to a core insight: when doing vibe coding on an existing codebase of any real scale, you must be a programmer yourself — if you want to preserve the architectural elements that got the system to where it is today. DHH also added that this was the situation a few months ago, and the tools have improved significantly since.

AI Generates Garbage Code? So Do Human Programmers

In response to the common criticism that "vibe coders are garbage code generators," DHH pushed back without hesitation. He suggested critics should first look at what average programmers actually produce in real projects.

"If you've looked behind the curtain at the codebases of many great companies — looked at what they become after 3,000 people have had their hands on them — that code is terrible, absolutely terrible."

This observation reminds us that when judging the quality of AI-generated code, we shouldn't measure against an idealized standard but rather compare it to the code that real-world human collaboration actually produces. In that sense, AI-generated code isn't necessarily worse — and in terms of consistency, it may even be better.

The Boundaries of AI Coding Are Shifting Rapidly

DHH's insights paint a realistic picture of where AI coding capabilities stand today:

• CRUD web applications and security vulnerability discovery: AI has nearly reached or already surpassed human capabilities
• Ambitious system-level projects: The collaboration model of humans reviewing architecture while AI implements details is already mature
• Large legacy codebases: Full automation still requires human programmers to maintain architectural consistency

One telling detail: DHH repeatedly emphasized that "this was the situation a few months ago — things are already very different now." The boundaries of AI coding capabilities are shifting at an astonishing pace, and for developers, the truly scarce skill may be transitioning from "writing code" to "judging whether code is correct" and "guarding system architecture."