They're not wrong

“We do not need developers anymore.”

I heard that sentence three times last week. Three different rooms, three different people, none of whom knew the others.

I’ll be honest about the first effect, because pretending otherwise would make the rest of this dishonest: it hit. The consulting market is hard right now. I felt the sentence before I could think about it, and the thinking took a few days to catch up.

What follows is the thinking.

Three rooms

The first was a business event. The sentence came up the way things do once they’ve settled — in passing, as an agreed fact, on the way to a different point. Nobody in the conversation pushed back, including me.

The second was a meeting where the CEO of a data company showed what his team had actually built. Not a demo. Not the prototype that never ships. The new face of his business, in production, at scale, built over two years by three people whose job titles have nothing to do with software. Coding agents the whole way. He said the sentence, and he had the receipts.

The third was a conference organised by a political movement, with three speakers, one of whom teaches at a management school. He said the sentence too — and everything he said around it about the current state of AI-assisted coding was accurate, current, and carefully argued. I sat there looking for the mistake and didn’t find one.

That last part is what makes this worth writing about. One of those rooms I could have dismissed. Three, including an expert who had done the reading and a practitioner with two years of production behind him, is not a room problem. It’s a signal.

The answer I wanted to give

The comfortable response, from people like me, is ready-made: call me when it has to survive production. Wait for the demo to meet reality. Wait for the edge case. Wait for the 3am failure.

I believe that answer, and I have evidence for it. Earlier this summer I spent six weeks on a thirty-year-old codebase where the AI-generated code compiled cleanly, passed the entire test suite, and was wrong in five separate places that only one person in the building could catch — the one who knew why the system had been built that way in the first place. Verified is not validated. That finding is real and I stand by it.

But it doesn’t answer this, and I’d rather say so than reach for it anyway.

The CEO isn’t waiting for production; he’s been in production for two years. The professor isn’t uninformed; he’s better informed than most developers I know. Two of the three people who said the sentence are precisely the people the comfortable answer assumes don’t exist — a practitioner with a working system, and an expert who has checked.

When you can’t say they’re wrong, the only question left is what exactly is true in what they said.

Who is actually building

Go back to the CEO’s three people.

They are not “non-technical,” whatever that word still means. They came from the analysis side of the business. They have spent years inside the domain. They know what the data means, which edge case matters, and what a wrong answer costs a client — because they used to be the ones explaining it to the developers.

That’s the detail that reorganises everything. The judgment in that company did not disappear. It was already sitting in those three people, and it had been sitting there the whole time. What disappeared was the layer between them and the software: the developer whose job was to take someone else’s understanding and convert it into code.

For thirty years that conversion was necessary, because writing code required a skill that took years to acquire and that the people holding the domain knowledge mostly didn’t have. So organisations built a translation layer — analysts on one side, developers on the other, specs and tickets in between — and everyone accepted that something got lost in the handover, because the alternative was no software at all.

The professor was right about the state of coding AI. And the state of coding AI is precisely the thing that lets people who already hold the judgment stop needing a translator.

So the sentence is almost correct. It’s off by one word.

We do not need translators anymore.

The boundary, stated precisely

I want to be careful here, because the reframe reads as either too reassuring or too bleak depending on where you stop, and it’s neither.

It does not mean judgment is optional. The six-weeks engagement is the counterexample: the tooling produced plausible, tested, green code that was wrong in ways no compiler and no test could see, and the only thing that caught it was thirty years of knowing why. Somebody still has to hold that. The CEO’s company works because three people hold it. Remove them and the machine will produce confident, well-tested output that quietly solves the wrong problem — at scale, faster than before, with a passing build.

It also does not mean developers are safe as long as they “add value.” That’s the vague version, and vague versions are how people avoid the actual question.

The actual question is which half of the job you were in.

A developer who understands the business — who can be given a problem rather than a spec, who knows which of five plausible implementations is the right one for this company — is worth more than they have ever been, because the part of their job that took the longest just got ten times faster and the part that mattered didn’t change at all.

A developer whose job was converting specifications into working code, faithfully, without needing to understand why, is now competing with the machine on the machine’s home ground. And that job is not being replaced by AI, exactly. It is being replaced by the people who used to write the specifications, who no longer need to hand them to anyone.

What I’d say to a board

If you are running a company and someone tells you that you don’t need developers anymore, the useful reply is not yes or no. It’s two questions.

Who is doing the building? And how close are they to the business?

If the answer is “people who have spent years understanding our customers, our data, and what going wrong costs us” — as it was in that CEO’s company — then the sentence is true for you, and you should act on it.

If the answer is “someone we hired because they know the tools,” then you have rebuilt the translation layer with a different job title and a shorter ramp, and you’re about to rediscover why it was a problem the first time.

And if the answer is “nobody, we’re waiting” — which is most companies I talk to — then the sentence is doing you active damage, because it has turned a question about where judgment lives into a question about whether to spend money on a category of person. Those are not the same question, and only the first one has answers.

The part I didn’t expect

I’ve been saying for years that the gap between the people who understand a problem and the people who build the solution is where products go wrong. It’s the founding line of the studio I run: we don’t separate thinking from building.

What I did not expect was to hear the market agree with me in a form that hurts. “We don’t need developers anymore” is what it sounds like when the separation of thinking from building stops being tolerated — not because someone wrote a manifesto about it, but because a CEO with working software no longer has to tolerate it.

So they’re not wrong. They’ve just stopped needing the half of the industry that was standing between them and the work.

The other half — the part that knows why — has never been in more demand, and has never been harder to tell apart from the first half on a CV. Both halves have the same job titles, the same languages listed, the same years of experience. The difference only shows up when someone hands you a problem instead of a ticket.

That’s the job now. Being obviously the second kind.