The Doorman Fallacy
The companies selling AI as a replacement for developers are making the same mistake as the supermarkets that replaced till operators with self-checkout. They will claim the cost saving and walk away before the value destruction becomes visible.
Rory Sutherland has a talk about what he calls the Doorman Fallacy. It goes like this. A consultant walks into a hotel and asks what the doorman costs. Low six figures. The consultant defines the doorman’s job as opening the door, replaces him with an automatic mechanism, claims the saving, and leaves. Nobody holds the consultant accountable when the rack rate collapses, when regulars desert, when vagrants sleep in the entrance. The doorman did far more than open the door. He hailed taxis. He recognised guests. He provided security, warmth, status. But those things do not fit on a spreadsheet, and so they were not measured, and so they did not count.
Sutherland’s point is broader than hotels. It is about a pathology in how businesses think. There are two models. In one, a business exists to discover and create value — subjective, human, often unmeasurable. In the other, a business exists to deliver a known thing as cheaply as possible. The second model predominates because it is easier to calculate. And because it is easier to calculate, it produces a specific kind of stupidity: the relentless optimisation of cost at the expense of everything that made the thing worth buying.
I recommend watching his talks. He is one of the most interesting thinkers working today on why rational-seeming decisions produce irrational outcomes. But I want to take his argument somewhere specific, because I am watching the Doorman Fallacy play out in real time in my own industry.
The story being told about AI and software engineering goes like this: language models can write code. Therefore you need fewer developers. Therefore you can reduce headcount. Therefore you save money. The people telling this story — and I will be blunt, the loudest voices are the companies selling the tools — are doing exactly what the consultant did in the hotel. They have defined the developer’s job as writing code. They have proposed a mechanism that writes code. They are claiming the saving.
They will not be in the room when the value destruction arrives.
Because developers do not just write code. A developer worth employing understands the architecture of the system they are working in. They know which decisions are reversible and which are not. They recognise when a requirement contradicts a previous requirement. They push back on product decisions that will create technical debt. They mentor junior engineers. They hold institutional knowledge about why things are the way they are. They exercise judgment — constantly, silently, in ways that never appear on a Jira board.
A language model does none of this. It generates code. It generates plausible, syntactically correct, functionally reasonable code. It does this very quickly and very cheaply. And if you define a developer’s job as generating code, then yes, the model is a replacement. In the same way that an automatic door is a replacement for a doorman, if you define the doorman’s job as opening the door.
I work as a fractional CTO. In my current engagement, I use language models constantly. They are central to how I work. And I have measured the difference: in the same sprint cycles, working on the same codebase with the same quality bar, my output was roughly ten times that of a skilled developer working without these tools. Not a vague impression. Measured in delivered, production-deployed work.
That number sounds like an argument for replacement. It is the opposite.
The company I work with is still hiring developers. The headcount plans have not changed significantly from what they would have been before language models existed. What has changed is the timeline. We expect to deliver more, faster. The model did not replace the team. It amplified what the team can do — but only when the team knows how to use it.
And that is the part that gets lost in the breathless predictions about AI replacing entire engineering departments. The ten times productivity gain did not come from the model. It came from me. From twenty years of building software, from understanding the architecture, from knowing which questions to ask and which outputs to reject. The model accelerated my existing judgment. It did not substitute for it.
When I interview developers — and I have interviewed dozens in recent months — most of them have AI coding tools. Copilot, Cursor, Claude. They use them daily. Their output has not meaningfully changed. They are the hotel with the automatic door. The mechanism is in place. The doorman is gone. And nothing has improved, because the value was never in the mechanism.
The self-checkout analogy is uncomfortably precise. Sutherland tells the story of supermarkets that noticed it was cheaper to have customers scan their own groceries than to employ till operators. So self-checkout went from being an option to an obligation. And then shoplifting exploded. And then they discovered you cannot do a family shop if you have to check everything out yourself. The cost saving was real and measurable. The value destruction was real and unmeasurable. The people who championed the cost saving were not the people who had to deal with the consequences.
This is exactly what will happen if the industry treats AI as a way to reduce engineering headcount. The code will be generated. It will compile. It will pass the tests that were written — though probably not the tests that should have been written. And then, slowly, invisibly, the quality of the system will degrade. The architecture will drift. The institutional knowledge will evaporate. The humans who knew why things were built a certain way will be gone, and the model that replaced them will not know and cannot care.
I think there is a different story to tell, and it is a much better one. Language models make skilled people dramatically more capable. Not by replacing what they do but by accelerating how they do it. Where I would have spent an afternoon searching documentation, I can ask a model and have an answer in seconds. Where I would have written a function from scratch, I can describe what I need and review what comes back. Where I would have maintained one line of investigation, I can run four or five in parallel. The process has not changed. The process is what it always was: absorb information, structure it, apply judgment, produce a solution. The model compresses the time. The judgment remains mine.
This is not the story the tool vendors want to tell. Amplification is a harder sell than replacement. You cannot put “makes your existing staff somewhat better at what they already do” on a pitch deck and raise billions. So instead they talk about science fiction. Humanoid robots. Agents that run your company while you sleep. A world in which human judgment is a quaint relic of a less efficient era.
It is nonsense. And it is the same nonsense that has always accompanied the Doorman Fallacy — the fantasy that you can strip out the human element, keep the measurable output, and suffer no consequences.
The developers who learn to use these tools well will be the most productive engineers in the history of the profession. The companies that treat this technology as an amplifier for human judgment rather than a replacement for it will build better products, faster, with teams that actually understand what they have built. And the companies that chase the headcount reduction will discover, too late, that they replaced the doorman with an automatic door and lost everything that made the hotel worth visiting.
Sutherland ends many of his talks with a line I find myself returning to: sell how you think, not what you do. The real value of a skilled engineer was never the code. It was the thinking that produced the code. Language models do not change that. They make it more valuable than ever.
If you are interested in Rory Sutherland’s work, I recommend his talks and his book Alchemy. He is one of the sharpest thinkers on why businesses make irrational decisions in the pursuit of rational-seeming metrics.
This is a companion piece to my series on LLM-assisted engineering practices. If you are an engineering leader thinking about how AI fits into your team, I would like to hear from you. Find me on LinkedIn or at [email protected].