Developer happiness had a good run

Developer happiness had a good run

September 29, 2026


The happiness framework's author changed his mind

Ruby on Rails was built around one unusual design goal: programmer happiness. So it landed with some force when its creator, David Heinemeier Hansson, used his Rails World keynote to tell a room of roughly 1,200 Rails developers that writing source code by hand is no longer economically viable.

Then he announced that HEY, the email service his company runs on Rails, is being rewritten in AI-generated Rust. This is the same person who has spent years calling Rust unkind to the humans who have to write it. His new position is that Rust is excellent as long as no human ever has to look at it.

It is tempting to file that under conference theatre. We think it is mostly right, and worth taking apart skill by skill.

Keyboard martial arts

Not long ago, serious developers spent weekends tuning Neovim configs and memorising hundreds of motions. It genuinely made you faster when you were the one typing.

When an agent makes most of the edits, clearing the inside of a pair of parentheses in three keystrokes becomes a party trick. Editors are not going anywhere, and Hansson still uses Neovim himself. But as an investment in your own output, editor mastery is now the weakest skill on the list.

CLIs, just not for you

One of the more practical points in the keynote: every application should ship a command line interface. Not for people, though. The argument is that agents need a way to operate your software without ever touching the UI, and a good CLI is exactly that.

We agree with this one completely. An app an agent can drive is an app that fits into someone's automated workflow. An app that needs a human clicking through it increasingly does not.

Developer happiness had a good run

Rails, React, Svelte, Angular, Tailwind: most modern frameworks won on how they felt to use. Running rails new in 2008 felt like a magic trick.

That criterion is fading. When the writer is a model, the things that matter are how many tokens a stack costs to produce and maintain, and how well the result performs. By Hansson's account, the Rust version of HEY cut server CPU and memory use by around 95 percent. Treat that as a keynote figure rather than a published benchmark, but the direction is the point: a language that was too painful for humans is cheap for machines, and the machines do not complain.

Push that far enough and you get frameworks and languages converging on whatever is cheapest to generate and fastest to run, whether or not a person enjoys reading it.

The show of hands

The two sharpest claims from the keynote:

  • Hansson says he went from writing around 30,000 lines of Ruby a year to around 150,000 lines a month with agents.

  • Asked who still spends a meaningful part of their week writing code, about five hands went up out of roughly 1,200.

About five hands out of 1,200. Nobody in that room was saying coding is ending. They were saying it already has.

A show of hands at a conference keynote is not a survey, and lines of code is a famously poor measure of anything. But the obvious question is the right one: if writing code is finished, why are companies still hiring developers at six-figure salaries?

What was always the job

Because typing was never the valuable part. The expensive, hard-to-replace work was always defining the problem properly, then designing a system that solves it securely and efficiently. Agents compress the mechanical part. They do not remove the need to know what to build, or to spot when what came back is wrong.

That is also why we read the keynote as optimistic rather than bleak. Hansson's jab was aimed at pessimism, not at people who like writing code. A capable developer with an idea now has more leverage than at any point in the history of the job.

How we see it at Birdhouse

This is close to how we already work. Agents do the writing. Our people spend their time on direction, review and deciding what is worth building at all. The bottleneck has moved, and it is worth being honest about where to:

  • Review is the new constraint. When code is nearly free, the pull request queue becomes the thing that limits delivery. Treat triage and review as first-class work, not the chore after the fun part.

  • Adversarial review beats trust. Code a model wrote confidently still needs someone, or something, actively trying to break it.

  • Pick stacks for the machine and the runtime. Token cost and performance now belong in the framework decision alongside familiarity.

  • Keep the judgement human. Problem definition, architecture and the call on what ships are where people add the most, and where they still carry the accountability.

Writing code by hand is not dead. It is just no longer the job. The job is everything around it, and that part got a lot more interesting.