The death of coding by hand is the wrong worry

This week's The Pulse from The Pragmatic Engineer opens with a story that made me stop scrolling: 37signals, the company behind Ruby on Rails, is moving to agents generating nearly all its code. The same issue says Amazon and Meta struggle to hire engineers, and that code reviews will probably also go away.

Of all the companies in the world, 37signals. The people who gave us a framework whose whole pitch was that writing code by hand could be a pleasure.

This one hits close to home. A good part of my career as a developer was Ruby on Rails: at UALA, then at Triboo on fashion e-commerce sites built with Spree. Then as tech lead at Triboo I spent a chunk of every day doing code reviews and mentoring junior developers. So I read the "death of coding by hand" debate less as a question about typing and more as a question about people.

Typing was never the point

Let's be honest: the death of coding by hand, taken literally, doesn't scare me much. Nobody misses writing boilerplate. Rails itself was an early version of the same idea, with generators and conventions doing the boring part so you could focus on the interesting part. If 37signals AI agents now do a much bigger share of the boring part, fine.

What worries me is the second claim, that code reviews will probably also go away. Because in my experience code review was never only a quality gate. It was the classroom.

Code review is where seniors get made

When I did daily reviews at Triboo, catching bugs was maybe half of the value. The other half was the conversation around the diff. Why this query will hurt once the table grows. Why this callback will surprise someone in six months. Why the clever version is worse than the boring one. A junior developer who gets fifty of those comments learns more than from any course.

And it worked in the other direction too. Juniors reading seniors' pull requests, asking why something was done that way, sometimes finding the bug nobody else saw. Review was the place where knowledge moved around the team without anyone scheduling a meeting for it.

My own path went like that. I started at an agency with basic development skills and learned by building, breaking things and being corrected. I'm not saying it was the most efficient way to form an engineer. I'm saying I don't know another one that works at scale.

The ladder with the bottom rungs removed

Here is the part I can't make add up. A few days ago I wrote that an AI software factory still needs someone to say no to what it produces. That someone has to be good. They need to read a diff and feel that something is off before they can explain why. That instinct comes from years of writing code, getting it reviewed, and reviewing others.

If agents write the code and reviews disappear, where do junior developers get those years? The small tickets that used to be their training ground are exactly the ones agents do best. The review comments that taught them are gone. We keep the top of the ladder and saw off the bottom, and then wonder in ten years why nobody can climb it.

The same newsletter says Amazon and Meta struggle to hire engineers. I don't know the details behind that, so I won't build a theory on it. But it is a funny thing to read next to a story about needing fewer people to write code.

37signals can probably afford this. A small, very senior team, people who have been writing Rails since before most of us, can judge what an agent produces because they spent a decade producing it themselves. The problem is not their team today. It is what every other company copies from them tomorrow, without the seniors.

What I would do instead

I'm not running agents in production, so take this as the view of someone who has managed engineering teams, not of someone with a fleet. But on the future of code review I'd bet on changing it, not killing it:

• Let agents do the mechanical checks (style, obvious bugs, missing tests) and keep humans on the design questions.
• Put juniors in the review loop on purpose, reviewing agent output with a senior next to them. Reading a lot of code, and arguing about it, is still how you learn.
• Keep some work hand-written on purpose, the same way pilots still fly manually even if autopilot is better at it most of the time.
• Count mentoring as real work in capacity planning, not as something seniors do in the gaps.

Maybe I'm wrong and someone finds a new way to form engineers that doesn't go through reading and writing a lot of code. I'd honestly love to see it. Until then, I'd keep the classroom open, even if the agents do most of the homework.