A doorman opens the door. Replace him with an automatic sliding door and the door still opens, plus you save a salary. Then a regular guest stands in the rain, unrecognised, asking nobody in particular for a taxi.
Rory Sutherland calls this the doorman fallacy: reducing a complex role to its most visible, automatable task, and then concluding that the role was the task. Adrian Krebs applies it to AI, with a second illustration that stings more: a product owner and senior developer decide what to build and what to skip, keeping the product coherent. Automate the coding and you can implement every request. The result is Homer Simpson's pink car — every feature someone asked for, assembled into something nobody wants.
Krebs's essay is short, but the pattern it names is the most useful lens I've found for the current wave of automation, because it explains why the failures look like successes right up until they don't.
Why the fallacy is so easy to commit
Three mechanisms make it nearly inevitable.
Job descriptions list tasks. The doorman's job description says "opens door." It does not say "notices the guest who looks unwell," "remembers that room 402 hates the elevator," or "deters the person loitering by the entrance." Those aren't in the document because they were never negotiated — they emerged. When you automate from the document, you automate what was written down, which is never the whole job.
The value of the invisible work is counterfactual. A good doorman produces no incidents. There's no line item for "trouble that didn't happen," no dashboard for "guest who felt safe." The visible output — the door opening — has a clean metric; the rest has no baseline. So the cost is easy to compute and the benefit is easy to ignore.
Artifacts are legible; judgment isn't. Code, doors, and proofs are things you can point at. Deciding not to build something leaves no artifact at all. A senior developer's most valuable contribution is often the feature that never gets written, which is indistinguishable from laziness if you're measuring commits.
The math version is the sharpest
The essay was inspired by a conversation about mathematics in the age of AI, and that's where the fallacy gets uncomfortable. If you define a mathematician as someone who proves theorems, then a system that proves theorems looks like a mathematician. But the job also includes choosing which problems matter, noticing that a technique from another field applies, knowing when a proof is wrong despite checking out, and deciding that a conjecture should be abandoned.
Those are not tasks. They're the function that makes the tasks worth doing. Automating theorem-proving doesn't produce mathematicians any more than automating the door produces hospitality.
What the fallacy looks like from inside
The insidious part is that the metrics improve. Door opens faster. More features shipped. More theorems proved. The dashboard is green, and the thing that used to be measured by the dashboard — whether anyone is being looked after — was never on it.
By the time the absence shows up, it shows up as an incident: a guest who leaves, a product nobody uses, a proof that's formally correct and mathematically irrelevant. And because the incident has no baseline, it's easy to attribute to something else.
What to do about it
Krebs's closing question is the right one: if the door opens itself, what still needs doing? But the question is hard to answer from a position of having already fired the doorman.
Three practical moves, none of them clever:
Shadow the role before you decompose it. Watch what actually happens for a week, including the interruptions. The exceptions are the job.
Ask what breaks if this person disappears for a month. The answers are the invisible work. If nobody can articulate them, that's not evidence the work doesn't exist — it's evidence it's invisible.
Track near-misses, not just incidents. The doorman's value is in the events that didn't escalate. Near-miss logging is unglamorous, and it's the only way to give counterfactual work a number.
And a fourth, for the AI era specifically: when task automation gets cheap, the decomposition error gets cheap too. You can now generate the Homer car in an afternoon. The scarce input isn't the code; it's the judgment about what should exist. That judgment was always the job — it just used to be bundled with the typing.
The door and the doorman
The automatic door is not a bad invention. Neither is a coding agent. The mistake is thinking that because the visible task is gone, the role is gone with it — and then discovering, at the first rainy night, that the door was never the point.
Source: The Doorman Fallacy in the Age of AI — Adrian Krebs.