DHH Says Hand Coding Is Finished. What That Means If You've Never Coded

For twenty-five years, David Heinemeier Hansson has been one of the loudest defenders of programming as a craft. He created Ruby on Rails. He wrote essays about the joy of beautiful code. If anyone was going to hold the line on writing software by hand, it was him.

This month, he opened Rails World 2026 by telling a room of more than a thousand developers that hand-writing code no longer makes economic sense. His team at 37signals has largely stopped routine coding. Their job now is directing agents, judging what comes back, and deciding what ships.

He isn’t speaking hypothetically. DHH says AI agents wrote effectively all of the code in the latest release of Omarchy, his Linux distribution. His own role was to specify problems, choose between solutions, and keep the whole thing coherent.

Developer forums have spent the week arguing about what this means for programmers. That’s a reasonable debate, but it misses the more interesting question:

What does it mean for the millions of people who have app ideas and have never written a line of code?

The gate just moved

For most of software history, there was one gate between an idea and a working product: you had to know how to program, or pay someone who did.

That gate kept out almost everyone. The teacher with a clever classroom tool, the personal trainer with a workout-tracking idea, the shop owner who knows exactly what their customers want from an app. All of them hit the same wall. Learning Swift takes months. Hiring an agency costs tens of thousands of dollars. Most ideas died right there.

If one of the most accomplished programmers alive now spends his days describing what he wants instead of typing it, then the skill that used to be the gate is no longer the gate.

That doesn’t mean building software is effortless. It means the hard part has moved.

What DHH actually does all day now

Coverage of the talk focused on the headline, but his described workflow is the more useful part. As he’s laid it out, it looks roughly like this:

1. Plan. One strong model drafts a plan for the task.
2. Build. A faster, cheaper model carries out the plan.
3. Review. A second agent checks the finished work.
4. Decide. He makes the final call on whether it ships.

Look at what’s left for the human: deciding what to build, recognizing when something is wrong, and choosing what’s good enough to release.

None of those steps require knowing how to write a for loop. They require knowing what you want, why you want it, and what “right” looks like.

That’s product judgment, and plenty of people who have never programmed have more of it than many engineers do.

The part of the story that got less attention

There’s an important caveat in DHH’s own experience, and it’s worth taking seriously.

At 37signals, designers used agents to build features directly during development of the next version of Basecamp. Each individual change looked reasonable on its own. Taken together, they started to damage the product’s architecture, and human programmers had to clean things up.

Omarchy went smoothly. Basecamp, a mature commercial product with years of architectural decisions baked in, did not.

The lesson isn’t that agents fail. It’s that agents are at their best on new projects with a clear structure, and they struggle when every change has to respect a large, messy history nobody fully wrote down.

For someone starting their first app, that’s good news. A brand-new app with a well-defined purpose is exactly where agents are strongest. You aren’t retrofitting a ten-year-old codebase. You’re starting clean.

It also points to the risk: if you keep bolting random features on without a coherent plan, you can end up with the same drift Basecamp did. Clear intent matters more than ever.

The skills that matter now

If code isn’t the bottleneck, what is? Here’s where we’d put your energy.

1. Knowing exactly what you’re building

“An app for gym people” is not a product. “A workout log for powerlifters that remembers your last set and suggests the next weight” is. The more specific your description, the better any agent performs. That’s true for DHH, and it’s true for you.

Before you build anything, write a paragraph about who the app is for, the one job it does, and what the main screen looks like.

2. Taste

Agents can produce a working app. They can’t tell you whether it feels good to use. You’ll need to look at what you’ve built and notice what’s off: a button that’s hard to reach, a flow that takes three taps when it should take one, a screen that looks like every other template.

You don’t need design training for this. You need to use your own app honestly, the way a stranger would.

3. Judgment about what to cut

The most common mistake with AI-built apps isn’t building too little. It’s building too much because each feature is suddenly so cheap to add. Every feature you add is another thing to test, explain, and maintain. The apps that make money usually do one thing very well.

4. Distribution

This is the part AI hasn’t solved, and it’s now the real moat. When anyone can build an app in an afternoon, thousands of people do. RevenueCat’s latest industry report counted more than 14,000 new subscription apps launching every month, most of them on iOS.

Building is the easy part now. Getting people to find, download, and pay for your app is where the work is. We wrote a whole guide on growing your iOS app for that reason.

5. Knowing how you’ll make money

A great app with no business model is a hobby. Decide early whether you’ll charge a subscription, a one-time price, or something else, and design your paywall into the app from the start instead of bolting it on later. Our guide to adding subscriptions without coding walks through it.

“Isn’t this just vibe coding?”

Sort of, but the difference matters.

Vibe coding usually means describing something loosely, accepting whatever comes back, and hoping it works. That’s fine for a weekend experiment. It isn’t fine for something you want strangers to pay for.

What DHH describes is closer to directing: a clear plan, automated review, and a human who makes the final call. That’s the model worth copying whether you’re an engineer or not.

In practice, that means:

• Describing your app precisely, not vaguely.
• Looking at the real result on a real (or simulated) iPhone, not just trusting that it works.
• Changing one thing at a time so you can tell what broke.
• Testing the unhappy paths: no internet, empty lists, a user who taps the wrong thing.

Where Cabano fits

We built Cabano around this shift.

You describe the app you want in plain English. Before building, Cabano proposes design directions so you can pick a look that matches your vision instead of a generic template. Then it writes a real native iOS app in Swift and SwiftUI, the same technology Apple’s own apps use, and runs it live in an iPhone simulator in your browser so you can see and tap through what was built.

When something’s off, you say so and it gets fixed. When you’re ready, you can add subscriptions, test on your own phone through TestFlight, and submit to the App Store.

In other words, you get to work the way DHH now works: decide what to build, judge the result, and make the call. The typing is handled.

If you want to see what that looks like end to end, start with our guide on how to build an iOS app without coding.

The real takeaway

The argument this week has mostly been about whether programmers are obsolete. They aren’t. Someone still has to design systems, keep large codebases healthy, and catch the problems agents create. DHH’s Basecamp experience makes that clear.

But something real did change. The skill that kept most people from building software, writing code by hand, just stopped being the requirement. What’s left is judgment, taste, focus, and the willingness to put your work in front of people.

Those were never things you needed a computer science degree for.

If you’ve been sitting on an app idea because you “can’t code,” that excuse is gone. The question now is whether you know what you want to build.