This post is an experiment in a new AI-assisted voice to blog capture mechanism.
Developers aren’t going away. But our job is.
AI can write better code than me. I’m not a great coder, but I write code roughly on par with most folks out there, and for junior engineers, AI is already better.
What’s left is judgment
A friend told me recently that pull request reviews are now all about architecture: the right levels of abstraction, and patterns they’ve been burned by before and don’t want to repeat. Senior engineers can spot that stuff because we’ve lived through it. Junior engineers can’t, at least not yet.
They’ll learn the same skills. They just won’t learn them by writing the code. They’ll learn them by dictating to AI, and I think that becomes the norm.
The environment sets the pace
How fast that learning happens depends on how AI-native your environment is.
In a greenfield, AI-native shop, code doesn’t have to be perfect, because it’s cheap. You ship it, pull it back, refine it, and optimize the pieces that matter. You learn fast. Swamp Club, from Adam Jacob, is a great example, and his talk on it is worth watching.
Most larger orgs aren’t there. They’re stuck in the old loop of PRs, staging, and putting the ones before the twos. Plenty of people want to adopt AI-native workflows but don’t know how yet, because it’s a genuinely new skill. After years of stitching code together, stepping back to think about the product is hard.
It’s still a net positive. When you can focus on the outcome instead of the implementation, people start building their own tools. Every week I see ten people on r/homelab building the same tool. That’s maybe a waste of resources, but it proves the point: if you have the vision, you can build it.
Engineering isn’t the whole machine
The bottleneck used to be people. Now, in theory, it’s tokens.
The AI labs are the proof case. Supposedly they run anywhere from 10 to 500 agents in the background at any given time. This calendar of everything the Claude team shipped in 52 days is mind-blowing. It’s also disjointed: features with little or no documentation and no connected product story. Engineering can sprint now, but the rest of the machine can’t keep up yet.
At Amazon, we handled this with the long horizon. The PR/FAQ, the press release and FAQ we write before building anything, set the North Star, and year one might deliver one item on it. Startups found that frustrating. But enterprises that have been around for 50 or 100 years don’t move fast, and five years in, AWS usually had something really good.
The rest of the machine is changing too. Whole docs teams have been laid off, not because docs stopped mattering, but because AI can write them from the code. Every layer gets absorbed. What’s left is judgment about what to build.
What I don’t know yet
I don’t know what hiring looks like from here, or how much enterprise value software can create when implementation is nearly free.
The real crux is juniors. We don’t have a good way to level them up today. Anyone can type into a prompt. How do we teach them to build well-designed product?
I say “product” deliberately, because I don’t think software matters anymore.
I’m not worried my job is going away. I just don’t know what it looks like in five years.
Developers aren’t going away. But our job is.
Postscript (Oct 9, 2026): This post was edited after publishing. The first version stayed very close to the voice transcript, and it read that way, so I had it tightened up: about 910 words down to 581, and 8 sections down to 4. Here are three representative edits. The original version is still on GitHub.
