Pencils Down Since 1954

In 1954, a team at IBM led by John Backus wrote a preliminary report for a system they called the IBM Mathematical Formula Translating System. You know it as FORTRAN. On page 2 they broke down where the money went when you solved a problem on a computer:
out of every dollar spent to solve an average problem on a high speed computer, less than 25 cents is spent for analysis and programming, more than 25 cents is spent for personnel coding and debugging cost, about 25 cents for machine debugging cost, and about 25 cents for machine running cost.
Then came the pitch:
Since FORTRAN should virtually eliminate coding and debugging, it should be possible to solve problems for less than half the cost that would be required without such a system.
Backus later admitted the team had been “hopelessly optimistic.” In 1957, the year FORTRAN shipped, the team’s paper had shrunk the claim to reducing “the coding and debugging task to less than one-fifth of the job it had been.”
The pitch came back this September, in Austin. In his Rails World keynote, David Heinemeier Hansson said 37signals has gone “pencils down on the idea that we were gonna write code by hand.” Writing code by hand there is now “an exceptional state. It is like seeing a bug in Sentry.” He made the economic case as well: it “is no longer an economically productive enterprise for the vast majority of programmers working at the vast majority of companies.”
Seventy-two years apart, both went after the same line item.
The Quarter Nobody Automated¶
Read the 1954 dollar again. Back then “programming” meant working out the procedure, and “coding” meant translating that procedure into something the machine could run. Those were separate jobs, often held by separate people. FORTRAN aimed at the coding quarter, and it worked. We solved coding the moment we invented compilers.
Every tool since has chipped at the same three quarters. Debuggers and frameworks took most of what the compiler left, and agents are taking the typing that remained.
The first quarter, analysis and programming, never got automated, because coding was never about physically writing code. The hard part has always been writing the correct code: understanding the problem well enough to pick the abstractions that fit it, and keeping the result correct when reality changes, which it always does. Somewhere in between you make trade-offs you will have to defend, and find the assumption you did not know you were making.
In 1954 that quarter cost less than 25 cents. It is the only part of the dollar that has not gotten cheaper.
Nobody Files a Correct Ticket¶
The Rails Foundation’s feature-ticket benchmark, the one where the best model ships 53.3% of the time, grades every run against hidden checks. Those hidden checks are the requirements whoever filed the ticket had in mind and never wrote down. Getting from the ticket to what the person meant is the analysis quarter, and no model has closed it.
I work in the supply chain sector. When something goes wrong, the client blames whoever is last in the chain, because that is the only link they can see. The problem usually started further up.
Models give CSS the same treatment. A style breaks, and the useful answer lives upstream: this needs fixing in Bootstrap or Tailwind, or, you know what, this looks like a bug in Chrome. The model goes to the end of the cascade instead, writes !important, and adds a 🎉.
Both are the ticket problem. The symptom shows up at the last link, and the fix belongs wherever the problem started.
David said as much himself, without meaning to: “I could have become a project manager 20 years ago if I didn’t care to write code myself and I just wanted outcomes.” He can direct agents from the outcome end because he spent twenty years learning what the code underneath has to do.
Why David Can Put His Pencil Down¶
37signals makes email, calendars, project management and chat. These are well-understood problem domains. Email has RFCs older than most of the people prompting for it. Every one of those products has decades of prior art: protocols, clients, competitors, bug trackers full of edge cases somebody already hit. For an agent, that prior art is most of the specification, already written and argued over.
My last post argued that ports come with an oracle. For a mature domain, the oracle is the whole field.
David is also an excellent showman and marketer. He can push an idea to its extreme and get the entire industry arguing about it. That is a real skill, and I say it with respect. The argument is part of the product.
The Framework That Takes Options Away¶
This is why Rails is so good, and it is the part of the keynote I agree with. Rails stops giving you options.
If you want an ORM, you get ActiveRecord or you maintain your own. Routing works the same way with Journey. Other frameworks hand you flexibility, and you spend the year wondering whether you should have picked the other library. Plenty of people fall for something like React first. When they finally find Rails, their first question is why nobody told them. Didn’t you have Google?
David made the agent version of this point on stage: conventions save tokens. He is right: one convention leaves the agent nothing to guess.
Then he said something I disagree with completely. He warned against a pitfall for “anyone who knows too much about how computers work,” and said “a bit of a dummy approach to this works even better, because you ask questions and you post prompts at a higher level.”
A dummy approach works when the domain is email. Knowing too much is how you notice the agent took the well-worn path when the problem needed a different one. Experience is knowing every path a person can take, including the ones that end in a wall. A junior who leans on agents never learns where the walls are.
Not Wired For It¶
The 1954 report made one more promise: “after an hour course in FORTRAN notation, the average programmer can fully understand the steps of a procedure stated in FORTRAN language without any additional comments.”
It was right about the notation. Every generation since has made the notation easier to learn, and David now says “English is a better programming language than Ruby.” The report never claimed an hour of anything would teach you to work out the procedure in the first place. Some people are simply not wired for that part, and decades of friendlier notation have not changed it.
The Deal Is Off¶
The comfortable era is ending. For a generation you could learn one stack and sit inside its abstractions while the ecosystem solved the hard problems for you. That deal is off.
If your conclusion from the keynote is that you should put your pencil down too, you are exactly the person the section above describes.
The other three quarters of that 1954 dollar keep getting cheaper. The first quarter is most of what is left, and it was always the job.
🔗Interstellar Communications
No transmissions detected yet.Be the first to establish contact!
Related Posts
The Rust Revolution Proposal Had a 363-Day Fuse
In September 2025 I wrote a satirical proposal to rewrite Rails in Rust, and picked Rust because it was the one language David would never touch. On September 23, 2026 he told Rails World he hates Rust with a passion and is rebuilding HEY's backend in it. The satire got one line wrong, and it stopped one language too early.
The Republic of Slop
A country where no citizen has ever felt a constraint. The dev box has 128GB, the model never says "this is too much," and the cloud bills instead of refusing. Then it ships to a 2GB server. On languages as materials, and the 100x receipt that proves nobody measured anything.
How to Build an OS Without Being a Degenerate
The follow-up to The Framebuffer People. Half the angry comments asked the same question underneath the anger: okay, so what should I build? Here is the long answer. Eleven rules for building an operating system that teaches you something, with your dignity still attached at the end.