Here's a job that no longer exists: the person who turns a spec into working code.
Not the person who decides what to build. Not the person who designs the system. Not the person who checks if it works. The person in the middle. The one who takes a clear requirement and writes the implementation.
That job is gone.
We just haven't updated the job boards yet.
What's left is a strange trinity:
Architects who decide how systems should fit together. They think in boundaries, interfaces, trade-offs. They don't write the code, but they decide what shape the code should take.
Product people who decide what should exist. They talk to users, feel the market, make judgment calls about what's worth building. They don't write the code either, but they decide why the code should exist.
QA who verify that the thing actually works. They poke at edges, think adversarially, catch the things everyone else missed. They definitely don't write the code, but they decide if the code is good enough.
Notice what's missing? The developer. The person who sits between "here's what we need" and "here it is."
That person has been automated.
Joel Spolsky wrote his famous test in 2000. Twelve questions to measure how good a software team was. Source control. One-step builds. Bug databases. The basics.
But buried in that test was an assumption so obvious nobody questioned it: that you needed developers. Plural. A team of people whose primary job was writing code.
The test asked: "Do programmers have quiet working conditions?" It assumed you had programmers. It assumed programming was the bottleneck.
Twenty-five years later, the bottleneck has moved.
AI didn't replace developers the way people expected. It didn't show up one day and write entire applications from scratch. That would have been dramatic. That would have been obvious.
Instead, it made the implementation phase trivially fast.
The thing that used to take a developer three days now takes an afternoon. The thing that used to require deep expertise in a framework now requires knowing how to describe what you want. The thing that used to be the job is now just... a step.
And when a step becomes trivial, you stop hiring people to do it.
For years, architects were mocked. "Ivory tower." "Astronaut architects." "People who draw boxes but can't ship code."
The criticism was fair. An architect who couldn't code was dangerous. They'd design systems that looked beautiful on whiteboards but collapsed under the weight of reality.
But now? The architect who can describe a system clearly is the one who can build it. Not by writing code themselves, but by directing something that writes code for them.
The skill isn't implementation anymore. It's specification. It's knowing what to ask for. It's understanding systems well enough to describe them precisely.
The architects won. They just had to wait for the tools to catch up.
Similarly, product people used to be translators. They'd take user needs and convert them into requirements that developers could understand. Then they'd wait. Sometimes weeks. Sometimes months.
Now they can see their ideas running the same day they have them.
This is terrifying and exhilarating. Terrifying because there's nowhere to hide. If your product instinct is wrong, you'll know immediately. Exhilarating because the feedback loop has collapsed to almost nothing.
The product person who can think clearly about what should exist, and describe it well enough to make it exist, is now the most valuable person in the room.
And QA? They're more important than ever.
When code is generated fast, it's also generated carelessly. The AI doesn't know what matters. It doesn't understand the edge cases that will embarrass you. It doesn't feel the difference between "technically works" and "actually good."
Someone has to be the skeptic. Someone has to ask "but what if?" Someone has to care about quality when the pressure is to ship faster.
QA used to be downstream. Now they're the last defense against chaos.
So where does this leave the person who used to be a developer?
They have three choices:
Move up to architecture. Think in systems. Care about boundaries and interfaces. Stop writing code and start describing it.
Move sideways to product. Care about users. Make judgment calls. Own the "what" and "why" instead of the "how."
Move down to QA. Become the skeptic. Find the holes. Be the person who makes sure the fast thing is also the right thing.
What they can't do is stay in the middle. The middle is automated.
Every industry goes through this. The job that was the core skill becomes a commodity, and the value moves to the edges.
Typesetters became designers. Calculators became analysts. Switchboard operators became... nothing, actually. Some jobs just disappear.
Developer might not disappear entirely. But "person who writes code" is no longer a job description. It's a tool everyone uses.
If Joel were writing his test today, it might look different:
Notice what's missing? Anything about developers. Anything about code. The test is about judgment, not implementation.
Nobody announced the death of the developer. There was no memo. The job titles are still on LinkedIn. The bootcamps are still running.
But the job itself — the thing where you take a requirement and turn it into code — is over.
What remains is harder to name. Part architect, part product person, part QA. Someone who can think about systems, care about users, and verify that things work.
We'll probably keep calling them developers for a while. Old habits die hard.
But the job they're doing? It's something else entirely.