For years, David Heinemeier Hansson was one of the software industry’s most recognizable advocates for writing clear, purposeful code. The Ruby on Rails creator built his reputation around programmer happiness, strong conventions, small teams, and the idea that skilled developers could accomplish more by rejecting unnecessary complexity.
That makes his declaration that “we’re done writing code by hand” especially significant. DHH says the development workflow at 37signals has effectively changed from developers manually producing most implementation code to developers directing AI coding agents that can investigate a repository, propose a solution, modify files, run tests, and return work that is often close to merge-ready.
This is not simply faster autocomplete. Nor does it mean 37signals has removed people from software development. DHH’s AI coding approach puts human developers in charge of intent, architecture, constraints, verification, and final judgment while agents handle much of the mechanical implementation. His experience offers a detailed look at agentic coding, but it should not automatically be treated as a universal forecast for every team or codebase.
What DHH Means by “We’re Done Writing Code by Hand”
The statement is deliberately provocative, but it is not a claim that nobody at 37signals will ever touch source code again. Developers still read code, edit it when necessary, review diffs, inspect tests, and decide whether a change belongs in the product. The shift concerns where implementation begins and who—or what—produces the first substantial version.
In a traditional workflow, a developer studies a problem, opens an editor, writes code line by line, runs the test suite, fixes errors, and prepares a pull request. In DHH’s AI-first workflow, the developer describes the desired outcome to an agent, provides relevant constraints, and lets that agent traverse the codebase and attempt the implementation. The human then evaluates the result rather than assuming it is correct.
That distinction matters. DHH AI coding is not about surrendering responsibility to a chatbot. It is about moving the developer’s attention from typing syntax toward directing work. The developer becomes the person who defines the problem, recognizes a weak abstraction, spots dangerous behavior, and determines when generated code meets the standards of a production system.
How the Ruby on Rails Creator’s AI View Changed
DHH was not an unquestioning promoter of every wave of AI programming. Earlier tools could be impressive in isolated demonstrations while remaining frustrating in real repositories. They frequently lost context, invented APIs, repeated failed approaches, or produced code that looked plausible without fitting a project’s established design.
Modern AI coding agents crossed a practical threshold for him because they became capable of completing coherent tasks rather than merely suggesting fragments. According to DHH’s public writing, the important change is experiential: agents began returning useful, integrated work often enough to alter how he approaches programming.
Instead of manually implementing a feature and consulting AI for occasional assistance, he can start by assigning the implementation to an agent. This inversion is central to the DHH 37signals workflow. Hand-coding becomes a fallback, a correction mechanism, or a deliberate choice—not necessarily the default starting point.
Why AI Coding Agents Finally Became Useful Enough
Several improvements converged to make agentic coding substantially more practical. Frontier models became better at reasoning across multiple files, following project-specific instructions, interpreting error messages, and revising their work after a failed test. Larger context windows also made it easier to retain relevant information about an application’s structure.
The surrounding tools improved just as much as the models. Current agents can search a repository, inspect version history, read documentation, execute commands, modify files, run linters, and use test output as feedback. Some can keep working through a sequence of failures instead of stopping after the first response. That tool loop transforms an AI model from a code generator into a limited software worker.
Repository conventions also make a major difference. A mature application with clear patterns, useful tests, understandable naming, and consistent architecture gives an agent examples it can imitate. Rails is particularly relevant because its conventions narrow the number of reasonable solutions. An agent that understands where models, controllers, jobs, mailers, migrations, and tests typically belong has less ambiguity to resolve.
None of this guarantees reliable AI generated code. The threshold DHH describes is economic and practical: the output has become good enough, often enough, that delegating first is more productive than manually typing the first implementation.
Inside an AI-First Coding Workflow
A productive AI coding workflow begins before an agent writes anything. The developer must frame the task precisely. That includes the desired behavior, product constraints, relevant files, compatibility requirements, performance concerns, and a clear definition of success. Vague prompts tend to produce vague implementations.
1. Give the agent a bounded objective
Rather than asking an agent to “improve the application,” an experienced developer defines a testable outcome. The task might involve changing a billing rule, adding a Rails endpoint, simplifying a query, or correcting a race condition. Smaller boundaries reduce the opportunity for irrelevant changes.
2. Let the agent investigate
Capable DHH AI coding agents are expected to inspect the existing system before making changes. They search for related behavior, identify established patterns, and determine which tests describe the current contract. This repository exploration is one reason agents have moved beyond simple autocomplete.
3. Require tests and tool feedback
The agent writes or updates tests, runs the relevant suite, examines failures, and iterates. Static analysis, formatting tools, type checks where applicable, browser tests, and framework diagnostics can provide additional feedback. Tool output is more trustworthy than an agent’s claim that its own work is correct.
4. Review the result as engineering work
A passing test suite is necessary but not sufficient. The developer reviews the diff for readability, security, unnecessary complexity, database implications, hidden coupling, and consistency with the product’s architecture. Human review is where knowledge of customers and long-term maintenance becomes decisive.
5. Merge, redirect, or discard
If the implementation is sound, it can be merged. If the direction is promising but flawed, the developer can give the agent targeted feedback. If the approach is fundamentally wrong, discarding it may be cheaper than repairing it. AI-first development works best when teams avoid becoming emotionally attached to generated output.
Why Ruby on Rails Is Well Suited to AI Agents
Ruby on Rails AI development benefits from the framework’s original philosophy: convention over configuration. Rails applications tend to share recognizable structures and common vocabulary, while the framework encourages developers to express business behavior with relatively little ceremony.
Those qualities help humans, and they also help agents. Predictable locations, established testing practices, expressive Ruby, and well-documented framework behavior reduce the search space. The official Ruby on Rails project also represents a large body of documentation and established patterns from which coding models can draw.
This does not mean every generated Rails solution will be idiomatic. An agent may still create unnecessary service layers, miss a database index, place logic in the wrong object, or imitate an outdated pattern. A developer who understands Rails remains essential for recognizing whether code merely runs or genuinely belongs in a Rails application.
What DHH’s Shift Means for Software Developers
The most immediate implication is that typing speed and syntax recall become less valuable as standalone advantages. Developers still need to understand code, but their leverage increasingly comes from problem definition, system design, debugging, review, and the ability to guide multiple AI coding agents toward useful outcomes.
This could make experienced engineers more productive because they have the judgment to recognize subtle mistakes. They understand when a task should be decomposed, which trade-offs matter, and why a technically valid change may be wrong for the product. AI software development amplifies that context rather than replacing it.
The effect on junior programmers is more complicated. Entry-level developers have traditionally learned by implementing small tasks, receiving review feedback, and gradually building a mental model of production systems. If agents perform all routine work, organizations could remove the very practice that creates senior engineers.
Teams therefore need deliberate learning paths. Junior developers should review AI generated code, predict what it will do, trace failures, write acceptance criteria, and explain design choices. They also need opportunities to implement selected features without delegation. Using an agent without understanding its output can create the appearance of productivity while slowing the development of real expertise.
Software engineering jobs are unlikely to collapse into prompt writing alone. The work includes deciding what to build, negotiating ambiguous requirements, protecting user data, operating systems, responding to incidents, and maintaining coherence over years. Agents can contribute to those activities, but accountability still belongs to people and organizations.
Does AI-First Development End Coding Craftsmanship?
DHH’s position challenges a familiar image of craftsmanship: the programmer personally shaping every method and expression. Yet craftsmanship has never been limited to keystrokes. It also appears in restraint, naming, architecture, product judgment, and the refusal to merge code that adds more complexity than value.
With AI programming, craft may shift from producing every line to curating the entire system. A strong developer can insist that an agent simplify a solution, remove speculative abstractions, improve a test, or follow an existing convention. The resulting code can still reflect human taste even when an AI agent drafted it.
There is a genuine risk, however, that cheap code generation encourages bloated software. When implementation feels nearly free, teams may create more features, dependencies, and abstractions than they can responsibly maintain. AI-first teams need stronger editorial discipline, not weaker standards.
DHH’s Experience Is Evidence, Not a Universal Rule
37signals has characteristics that influence its results: experienced developers, mature products, strong internal conventions, extensive institutional knowledge, and leadership willing to reject unnecessary complexity. A regulated medical platform, embedded safety system, neglected legacy application, or research-heavy product may see a different balance between manual work and agent delegation.
Model behavior can also change, and agents still make confident mistakes. Security boundaries, migrations, concurrency, destructive operations, and subtle business rules require careful scrutiny. Organizations remain responsible for licensing, privacy, access controls, auditability, and the handling of proprietary code.
For that reason, the broader conclusion should not be that all software developers are done hand-coding. The defensible conclusion is narrower: DHH reports that modern agents have become effective enough for his team to make delegation the default, with humans retaining final control.
The Future of Coding Is Direction Plus Judgment
The future of coding described by DHH is less about eliminating programmers than separating software creation from manual code production. Developers specify intent, agents attempt implementation, automated tools expose defects, and humans decide whether the result deserves to ship.
As AI coding agents gain better memory, planning, tool access, and parallel execution, that loop will become faster. The scarce skills will be understanding systems, asking precise questions, validating behavior, and exercising taste. DHH’s transition is notable because it comes from a programmer closely identified with the joy and craft of writing code. His message is not that code no longer matters. It is that producing it by hand is no longer always the highest-value use of a developer’s time.
Frequently Asked Questions
Has DHH completely stopped writing code manually?
No. “We’re done writing code by hand” describes a default workflow, not an absolute prohibition. DHH and other developers can still inspect, edit, debug, or manually implement code. The key change is that AI agents increasingly receive the first attempt.
Which tasks are best suited to DHH AI coding agents?
Well-bounded tasks with clear requirements, representative tests, and established repository patterns are strong candidates. Ambiguous product decisions, sensitive architectural changes, and high-risk operations require more direct human involvement, even when an agent assists.
Will AI coding agents replace Ruby on Rails developers?
They are more likely to change the role than eliminate it. Rails developers still need to understand data modeling, web security, performance, framework conventions, business behavior, and production operations. The difference is that they may direct and review more implementation than they type.
Can junior developers learn effectively with AI generated code?
Yes, if teams treat agents as learning tools rather than substitutes for understanding. Juniors should inspect diffs, explain decisions, diagnose failures, and sometimes work without agent assistance. Otherwise, apparent speed can conceal gaps in foundational knowledge.
What makes AI-produced code merge-ready?
Merge-ready code must fit the existing architecture, satisfy tests, meet security and performance expectations, remain understandable, and solve the intended product problem. An agent can produce the draft and run checks, but a qualified human should make the final judgment.
