In September, DHH opened Rails World 2026 by telling the room that 37signals has gone pencils down on writing code by hand. A lot of developers pushed back hard. I get why. I've felt some of it too. But I've seen this movie before, and I wanted to write down my own take.

I've been writing code for over 20 years. I've built companies, managed teams, and lived through more "this changes everything" moments than I can count.

I watched us move from waterfall to Scrum, and I was one of the first Certified ScrumMasters in Western New York. I saw the cloud show up, then containers, then CI/CD. I watched developers go from Notepad to Sublime Text and Notepad++, then to full IDEs, then to cloud development environments. I lived through terminal multiplexers, Vim motions, and language servers that made every editor smart.

Every one of those shifts came with fear. Ops people worried the cloud would take their jobs. Senior devs worried Scrum would turn them into ticket machines. For the most part, those jobs didn't go away. They changed.

AI is the next change in how we work. But I'll be honest: this one hits harder than the others.

Fig. 1Each shift changed the shape of the job

WaterfallScrumCloudContainersCI/CDAI

Shifts I've lived through. Hover a box.

What I'm seeing on my teams

The struggle isn't one thing. Some people are wrestling with identity. They became developers because they loved being in the editor, and now they're being asked to step out of it. Some are worried about their jobs. And a lot of people are just tired, because the expectation to do more showed up the same day AI did.

I'm not the only one seeing this. Annie Vella wrote about the software engineering identity crisis, and it struck a nerve far beyond what she expected. Gergely Orosz wrote openly about his grief at realizing AI will probably write most of the code he ships. And a study of 442 developers found that heavier workloads went with more burnout, and more autonomy went with less.

People are also spending more of their day reviewing code than writing it, and they're on the hook for code they didn't write and only half understand. None of that shows up in our velocity charts.

If you manage developers, talk about this openly. A lot of what people are feeling is grief, and a productivity dashboard won't fix it.

The craft nobody else could see

This next part is hard for me to say, because I love this work.

In a lot of places, people love imperfection. A singer cracking a note at a live show. A knot in the wood of a handmade table. A family recipe that never tastes quite the same twice. The flaws tell you a person made it, and that makes you feel connected to it.

Software doesn't work that way. Nobody loves the character of a bug. A glitch doesn't tell you a human made this. It tells you it's broken. Users never saw our craft. They only saw the result.

We built a whole culture around well-written code. Clean abstractions, clever one-liners, the perfect editor setup. I'm proud of all of it. But that appreciation mostly stayed inside our own community. The people we built for never saw it, so they never valued it.

Les Orchard put it well. Before AI, the people who loved the craft and the people who just wanted it to work "sat next to each other, shipped the same products, looked indistinguishable." Now "there's a fork in the road." That's uncomfortable, but it's honest.

So when it comes to typing code, I think DHH is right. It's pencils down.

Pencils down doesn't mean brains off

We still need to understand code. You still have to read it, judge it, and debug it when it breaks at 2 a.m. That matters more now, because writing the code is no longer the hard part. Understanding what got written is.

What matters most is understanding systems: how the pieces fit, where things fail, and what to ask before anyone writes a line. That's what has separated good engineers from great ones for the 20 years I've been doing this, and it hasn't changed.

People say prompts are the new programming language. Maybe, but there's nothing magic about it. A good prompt is a good spec: what you want, the constraints, and what done looks like. We've been writing those since the waterfall days. Now we hand them to something that works a lot faster.

AI doesn't change how you think about systems. It lets you solve problems faster. If you keep making it about writing code, you're going to have a rough time.

Move up to meet the user

So if the real work is upstream now, where do we go? I think we go to the user.

For most of my career, there were layers between developers and the people using our software: product managers, analysts, support teams. Developers lived in the code, and the user was someone else's job. That made sense when writing code took most of our time.

It doesn't anymore. The time AI gives back should go to the user: understanding their problem, watching them struggle with what we built, and caring whether it actually helps.

I don't see that as a step down from the craft. Users never saw our clever code, but they notice right away when a developer actually understands them.

Fig. 2Where the craft moves

AI writes ittime backTyping codeUnderstandingsystemsMeetingthe user

Hover a box.

What I'm telling my teams

  1. Get closer to your users. Sit in on support calls. Watch someone use what you built. Read the complaints. This is becoming the core of the job.

  2. Think in systems. Know how the pieces connect, where data flows, and where things break. AI can write a function. It can't own the whole design yet.

  3. Write prompts like specs. Say what you want, the constraints, and what done looks like. Fuzzy thinking used to cost you a day. Now it gets you a pile of confident, wrong code in seconds.

  4. Own what you ship. Read and test everything the AI writes. Your name is on it. Anthropic's own research found that mostly junior engineers who leaned on AI while learning a new library scored lower on a quiz about it (50% vs. 67%), and debugging took the biggest hit.

  5. Keep your fundamentals sharp. Some days, solve it yourself. This matters most for juniors, who are losing the grunt work that used to teach them. If you lead people, set aside time for that learning. It won't happen on its own anymore.

  6. Let go of the typing, not the craft. Your value was never the typing. It was solving the problem. Grieve the old way if you need to, then take that skill upstream.

And to other managers: don't use AI as an excuse to pile on more work. Reset expectations, let people have a say in how they use these tools, and check in on how they're actually doing.

Where I land

I've watched this industry reinvent itself over and over. The people who did well were never the ones holding on to the old tools. They were the ones who kept asking who the work was for.

The code was always just a means to an end. Put the pencil down, look up from the editor, and go meet the user.