Now anyone can code, but where's the taste?

At Rails World in September 2026, David Heinemeier Hansson (known as DHH), the creator of Ruby on Rails and co-founder of 37signals, told a room full of developers that he has retired from writing code by hand. After twenty-five years as a professional programmer, he said he looks back on the era of writing code by hand "not with regret, but with joy". His company has gone "pencils down" on hand-written code, and he argued that by the end of this year, typing code by hand won't make economic sense in almost any domain.

He dates his turning point to November 2025, and his last day as a professional programmer to around March this year. When someone who shaped how a generation of developers built for the web moves that far, that quickly, it's worth paying attention.

On this, I agree with him. But I think the most important part of his keynote wasn't the headline.

The Swiss cheese moment

Tucked into the talk was a story about Basecamp 5. In the spring, while finishing the release, 37signals let designers vibe-code the final features with AI. Each change looked reasonable on its own, but taken together DHH said they left the architecture looking like "Swiss cheese". The team concluded the tools weren't ready and went back to having programmers review everything by hand.

DHH now calls that the wrong conclusion, and thinks the newer models that arrived weeks later would probably have made it work. He may be right about the models. But I don't think the models were the whole problem.

The code did what it was asked to do. Nobody in the loop knew what to ask for underneath: how the pieces should fit together, what would break at scale, what would be a nightmare to change six months later. The output looked finished, but it wasn't.

That gap is about to become the defining gap in software.

The Brownie made everyone a photographer

DHH compared this moment to the Kodak Brownie, the cheap camera that put photography into everyone's hands. It's a good comparison, and it cuts both ways. The Brownie made everyone a photographer. It didn't make everyone a good one. Once anyone could operate a camera, what became valuable was knowing where to point it.

The same thing is now happening to software. When anyone can describe an app and have working code back by the afternoon, the ability to produce code stops being scarce. What stays scarce is judgement: knowing what to build, what to leave out, and why one version will land with the people who use it while another quietly fails.

That judgement is taste, and in software it has two halves.

Under the hood, and in people's hands

The first half is knowing how it works. Not typing every line, but understanding what's happening underneath well enough to sense when something is wrong. When an AI agent hands you a thousand lines of code that pass every test, someone still has to know whether the data model will survive the next feature, whether the security assumptions hold, and whether you're looking at a foundation or a facade. You only get that from years of building things and watching them break.

The second half is knowing why it works. Software doesn't succeed because it runs. It succeeds when it gets into people's hands and fits the way they work, which is rarely the way the specification assumed. You learn that by shipping products, sitting with customers, and owning the outcome when adoption stalls.

Many careers are built in one half: engineering that understands the machine, or product that understands the customer. The people who will matter most over the next few years have both, usually because they started in one and grew into the other.

Where I sit

That's my path. I started in 1999 as a programmer at Coventry Building Society, working on core systems for lending and payments. At Next, I moved from the engineering team rebuilding next.co.uk into owning its customer experience, and learned how a change to a product page shows up in conversion and basket value. From there I went on to lead product and technology at McDonald's, Avon, Osprey and Believ.

The McDonald's self-order kiosk is the clearest example of both halves working together. Under the hood, it had to keep taking orders when a restaurant's connection dropped, so the architecture cached menus and prices locally and queued orders until the link came back. In people's hands, it had to make ordering easier while helping customers build a bigger basket, which lifted average order value by up to around 30%. Neither half on its own would have taken a European pilot to $5.5bn in annual kiosk channel revenue by the time I left.

I'm not nostalgic about hand-written code. At Believ I brought AI coding agents into our engineering team, with the permissions, guardrails and review gates that stop speed turning into Swiss cheese. I still run multi-agent workflows myself, including the ones that build this website. But what I bring to a client was never the typing. It's the judgement about what is worth building, and whether what has been built will stand up once real people start using it.

What this means if you run a business

If DHH is right, and on this topic I think he is, the cost of producing software is heading towards zero. That's a gift, but it moves the risk rather than removing it. The danger is no longer that you can't afford to build something. It's that you build the wrong thing quickly, or the right thing on foundations that won't survive contact with your customers.

So the questions worth asking have changed. Not "who can build this for us?", but:

• Who is deciding what gets built, and why?
• Who can look at what the AI produced and tell you whether it's sound?
• Who has seen enough products succeed and fail to spot the difference early?

DHH said in the keynote that no one yet has the blueprint for how software should be structured in this new world. In my view, that makes experience matter more now, not less.

AI has made building fast. It hasn't made building right. I've spent more than twenty years learning how to build lean teams that deliver products, features and capabilities that add real value. Now I help companies do that with AI, moving faster without losing the judgement that makes the result worth having. If you'd rather not end up with Swiss cheese, let's talk.