DHH is right about the pencils, and the bill comes due in verification

David Heinemeier Hansson published three posts in three days in October: one against pessimism as a habit, one saying hand-written code is over, and one arguing that making jobs redundant is what progress has always looked like. Read together they're a single argument, and the middle one is the one with a testable claim in it.

The claim is narrower than the reaction to it suggests, and it's right. What follows is why, and what it does to the part of the job nobody is talking about.

What was actually claimed

We're not going to write the vast majority of code by hand any longer.

That's the sentence, and it's about typing rather than about programmers. The third post makes the shape of it explicit: "This is what progress usually looks like: redundancy", with ninety percent of Americans working in agriculture in the 1800s against one percent now, switchboard operators gone entirely, a million typists displaced by word processing.

The optimistic half of the argument is that cheaper software means more of it. More apps, more services, companies hiring their first programmer rather than their last. Set against that, the posts don't pretend the transition is painless, and say so plainly: what's good for humanity in the long run can be temporarily tragic for the individual in the short run.

This is the third time in two months the same thesis has surfaced, after the Rails World keynote and the Lex Fridman conversation, and the written version is the clearest of the three. What was actually said at the keynote, as against what the internet decided it meant, is separated out in Pencils down: what DHH actually said.

It's a better argument than the one being had about it, mostly because it separates two things people keep merging. Fewer keystrokes is not fewer people, and a trade changing shape is not a trade ending.

The part that moves rather than disappears

Here's what we'd add, and it's a continuation rather than a correction.

When you write code by hand, you form beliefs about it as a side effect. You know the find_each loop batches because you wrote the batch size. You know the callback runs inside the transaction because you put it there. The understanding isn't a separate activity, it's a residue of the typing, and it's free.

Stop typing and that residue is gone. The code still has to be understood, by somebody, before it goes anywhere near a customer. So the understanding stops being free and becomes a thing you have to go and get on purpose.

That's the whole shift, and it's the same one the posts describe for everything else: the work doesn't vanish, it relocates to the part that's still scarce. Here the scarce part is knowing whether the thing in front of you does what it appears to do.

Why that isn't a platitude

Because the plausible answer is wrong at a rate that surprised us.

This site spent October measuring ordinary Rails behaviour and writing it up. Not exotic corners. Things a competent developer would answer confidently from memory. Seven of those answers were wrong, and in each case only running something caught it.

The pattern across them is the uncomfortable one. None of these was a hard question. Every wrong answer was the answer a confident person gives, and several of them were the answer we gave right up until the moment something printed a number that couldn't be true.

The stream one is written up in full in Server-sent events freeze the process they run in, and the benchmark is the clearest of them. A development server reported 16.3 requests a second on an endpoint that sleeps for 100 milliseconds with a single thread, which has a ceiling of 10. The number was impossible, which is the only reason it got a second look, and underneath it the server was serving a 500 in 55 milliseconds and the harness was counting those as successes. Everything downstream of that measurement would have been confidently, publishably wrong.

The ReDoS one is the other shape of the same problem. Three advisories were set aside with a written justification naming this application's Ruby. The conclusion was correct and the stated reason was about the wrong interpreter: development runs 4.0.5, production runs 3.3.9, and the file said 4.0.5. It survived only because both are above the version where the mitigation landed. A justification that happens to be right is not the same thing as a justification that is right.

Which is the argument for the posts, not against them

None of that is a reason to keep typing. It's a reason the posts are describing a shift in what's expensive rather than a reduction in what's needed, which is exactly what the agriculture and switchboard examples describe too. Nobody misses the keystrokes.

The posts themselves are careful about this in a way the reaction usually isn't. They describe agents as new coworkers rather than a replacement, and note that they still occasionally get it wrong. Both halves are correct and the second one has a number attached to it: occasionally, over a month of ordinary work, was seven.

So the practical reading, for anybody running a Rails app rather than arguing on the internet: the thing to get good at is the cheap experiment. A test that runs real code, a control case beside the thing you're testing, a number you can sanity check against a ceiling you know. All of that was always good practice and most of us treated it as optional, because the typing was carrying the understanding quietly.

It isn't now. That's the bill, it's much smaller than the saving, and it's the part worth building a habit around while everyone else is still arguing about whether the saving is real.

What this page doesn't cover

No position on the employment argument. The third post's economics, whether cheaper software really produces enough new work to absorb the displacement, is an empirical question about the next decade and nothing here bears on it.

Nor any claim about agent quality. The seven cases above are human errors found by measurement, not agent errors, and that's deliberate: the point is that the verification gap exists before you add an agent to it, which is why the habit is worth having either way. What an agent does to the rate is a thing to measure rather than to assume, and we haven't.

The posts are at world.hey.com/dhh and are short. Read them rather than this summary of them; the anti-doomerism one in particular makes an argument about psychology that no paraphrase does justice to.