Monday. 9:04 a.m. Manolo has put a keyboard in a glass display case. The label underneath reads: “EXTINCT PROFESSION.”
—Is it broken? I ask.
—I retired it. I watched DHH's keynote yesterday. Pencils down, Jose. Now you talk to agents and software appears.
The Rails World 2026 opening keynote is still paused on his office screen. David Heinemeier Hansson, the creator of Ruby on Rails, explains that at 37signals they have stopped writing code by hand as their normal way of working. He shows what they are building with agents and talks about rebuilding parts of HEY with native apps and a Rust backend.
—What are you going to do with the keyboard? I ask.
—Open my conference with it on Thursday. Sixty customers are coming, plus developers who build on our booking platform. I'm going to announce that I've retired from programming too.
—What did you promise them you'd cover?
Manolo opens the invitation: “Platform updates, upcoming features and roadmap.”
—There's room for all that later, he says. First you have to inspire people.
He rehearses standing up, the keyboard tucked under his arm.
—“Friends, the future is here. We built twelve prototypes in a single weekend. Our new app will be native. The server might run in another language. It's time to leave the old ways behind.”
—What about the platform those sixty customers use?
—It's still there.
—What version comes next? Which API will you maintain? How long will they have to adapt if you change something?
—You are incapable of getting excited.
Lucia arrives. She maintains the integration for a chain of clinics. For three years she has made sure bookings made through Manolo's platform reach the appointment systems at thirty locations.
—I saw the draft of your talk, she says. Are you going to announce that your new product won't use the platform?
—I'm announcing a possibility. We have the freedom to choose the best tool.
—Of course you do. I want that freedom too. What I need to know is what happens to the tool my customers have spent three years building on.
Manolo shows her the twelve prototypes. One lets people book an appointment by talking. Another puts a little drawing of each doctor on the calendar. A third turns the waiting room into a video game. Lucia stops at number five.
—This one opens on my phone, she says.
—See? We're making progress.
—I said it opens. Can it cancel an appointment and notify the clinic? Does it keep the settings for all thirty locations? Who answers the customer when a reminder goes out at the wrong time?
Manolo switches to prototype number six.
—This one has better colors.
The interesting thing about DHH's keynote is that there is something valuable in it. A creator does not have to type every line of code personally. He can change tools, try a different architecture and discover that he can now build things that used to be out of reach. Manolo should hear that part.
He should also hear the question left hanging in the room. The official program described the opening keynote as a talk about what's new in Rails and where the framework is headed. In the discussion afterward, several attendees and users complained that the talk spent more time on his experiments and HEY than on a concrete direction for Rails. Others defended it. There was no single reaction.
—So DHH isn't allowed to rebuild HEY however he likes? Manolo asks.
—He is. And he can talk about it. HEY is his product; Rails is also a tool that many other people use to build theirs. At a Rails conference, those people want to understand both things and how they fit together.
—I'm going to talk about my product too.
—You're going to talk about twelve products you don't have yet. Lucia is asking about the one she already has in front of her.
Manolo looks at the display case. The keyboard resembles a surprisingly recent fossil.
—But if agents do the work faster, why wouldn't I change everything?
—Because “more code” and “a better product” are different claims. The Rails community knows that too. This month, the Rails Foundation published a test of twenty product tasks on a real application: the best agent completed 35% of the runs under its checks. That was a specific test with specific limits; it does not measure DHH's work or predict the future of every agent. It does remind us that a working demo and a finished feature are different things.
Lucia points to the calendar in prototype number five.
—I'd love a tool that could write this integration faster, she says. I have repetitive changes I'd delegate tomorrow. But someone still has to decide what “cancel” means at thirty different clinics. And take responsibility when that decision affects a person with an appointment.
—That's no longer writing code, Manolo says.
—Call it what you like. It's still part of building software.
Manolo reads his first slide again: “PROGRAMMING IS OVER.” Underneath it he has another slide showing how many lines of code his agents generated this week. He deletes it.
—What do I put there instead? he asks.
Lucia picks up a marker and divides the whiteboard into three columns: “What works,” “What we're testing,” and “What we don't know yet.”
—In the first, the platform we actually use. In the second, those prototypes and what you'll measure before promising them. In the third, the architecture decisions you haven't made. I can work with that uncertainty. I can't work with a triumphant speech and no dates.
Manolo opens the display case and takes out the keyboard.
—Should I give it back to Engineering?
—Yes. If they want to write a line by hand, let them. If an agent helps, let it. Your job on Thursday is to explain what other people will be able to build on what you maintain.
He carries the keyboard away and leaves the label on the desk. Someone has written on the back in marker: “FUTURE PENDING CONFIRMATION.”
There is a vast difference between showing what you can do now and announcing that everyone else's craft is obsolete. Especially when those people are sitting in front of you, waiting for news about the product you helped them build on.
Thanks for reading.
We all know a Manolo. Sometimes we are one. A new one every week.