There's a concept worth understanding before you hand your next project to an AI and call it done.
Imagine a high-end hotel with a doorman. His job description says he opens and closes the door. A manager looks at that, does the math, and fires him. A door stop costs five dollars. Why pay thirty thousand a year for someone to do what a wedge of rubber can do?
Six months later, revenue is down. The manager can't figure out why. Nothing changed - except the door is now propped open and the guy who used to stand there is gone.
That doorman wasn't just opening doors. He was the first impression. He carried bags. He remembered regulars. He made guests feel like they'd arrived somewhere that cared whether they showed up. The manager measured the visible task and missed everything around it. By the time the consequences showed up, the connection between cause and effect was invisible.
This is the Doorman Fallacy. You eliminate something based on what it appears to do, without understanding what it actually does. The bill comes later, and by then no one remembers why.
What This Has to Do With AI and Software
Right now, a version of this is playing out across the tech industry.
The logic goes: developers write code, AI can write code, therefore we need fewer developers. Some companies are acting on that logic today. They're cutting engineering headcount, pointing to AI output as proof that the work is getting done.
The code is being written. That part is true.
What's also true is that writing code was never the hard part.
Before AI existed, experienced developers spent most of their time not writing. They were reading other people's code, understanding systems, finding the part where two things were supposed to connect but didn't. They were arguing about architecture in a meeting. They were drawing boxes on a whiteboard, then erasing them, then drawing different boxes. They were asking: do we build this, or buy it, or find something that already exists? They were reading a pull request and noticing that the approach was going to work fine for six months and then become a problem that would take three weeks to untangle.
The actual writing - fingers on keyboard, characters appearing in an editor - was a small fraction of the job. It was the moment when everything you'd already figured out finally got expressed in a form the computer could understand.
AI can do that part. The expression part. It can take a clear idea and produce code that represents it. That is genuinely useful. It changes how fast certain things get done.
It does not change what the hard problems are.
The Bill Arrives Late
Here's where the fallacy bites: the consequences aren't immediate.
Fire the doorman today, and the hotel still works tomorrow. Guests still get inside. You've saved money. It looks like a good decision for a while.
The same thing happens with software. You can gut a development team, ship code with AI, and things will work. Applications will run. Features will get built. For six months, maybe a year, the decision looks vindicated.
Then the system starts to age. Someone needs to change how two services talk to each other, and the code is structured in a way that makes that change enormously difficult. A new requirement comes in that would have been simple if the architecture had accounted for it, but it didn't, because no one was thinking about the architecture. The codebase accumulates debt - not dramatically, not all at once, just steadily, the way a house accumulates problems when deferred maintenance becomes the policy.
Now you need the people who weren't there. And they weren't there because they looked like they were just writing code.
A Real-World Example
I worked on a project recently where someone handed me two pages built by AI. Promotion page, thank-you page. They looked good. The instruction was simple: put these on the site.
The site was running a specific CMS (you can probably guess), with a specific CSS framework already in place. The AI had generated self-contained pages - inline styles, inline scripts, and the same animated SVG graphic repeated inline eight times in the same file with slight variations. The form on the promotion page had no submission target. It didn't go anywhere. It just looked like a form.
Nothing about what was handed to me was deployable. The visual output was fine. The functional reality was not. Turning those two pages into something that actually worked, that fit the existing environment, that didn't import redundant assets - that was a real job. The eight copies of that graphic went from nearly a megabyte down to under a kilobyte once the redundancy was cleared out and the animation and variation was consolidated into a single script.
The client was surprised by the bill. AI had made the pages, after all. I wrote the working code, but now it lives in limbo - with the bill.
But AI had made a mockup. A convincing one. Someone still had to understand the system those pages were going into, figure out what was wrong, and fix it. That's the doorman's job. It doesn't look like much until it isn't there.
The Efficiency Problem Nobody Talks About
The SVG story points at something that deserves its own examination.
AI optimizes for one thing: output that satisfies the visible criteria. Does it run? Does it look right? Those boxes get checked. Everything beyond them is someone else's problem.
An experienced developer carries cost-awareness that runs in the background constantly. You don't write the same function three times because you already know what that means when someone has to modify it later. You don't inline every style because you know what that does to load time and cache behavior across a site. You don't reach for a verbose solution when a clean one exists, because the verbose version is more to read, more to test, and more to break. These aren't conscious decisions every time - they're instincts built from having dealt with the consequences of their opposites.
AI has none of that. It will repeat itself without noticing. It will generate ten lines where three would do the same work. It will duplicate an asset across a file because each instance satisfied the local requirement, and no one was keeping track of the whole. It produces output that passes every visible test while quietly failing every invisible one.
The eight-SVG problem wasn't a bug. The AI did exactly what it was asked. No one asked it to care about file size, or redundancy, or what the page would cost to load on a mobile connection. No one asked it to think about the system around the file, because AI doesn't think about systems. It thinks about the thing directly in front of it.
That gap - between "this works" and "this is good" - is where efficiency lives. And it's a gap that doesn't show up on a preview. It shows up in PageSpeed scores, in load times, in the developer who opens the file six months later and has to understand what they're looking at before they can change anything. It shows up in the hosting bill when nobody noticed the assets were ten times larger than they needed to be.
Efficiency isn't a finishing touch. It's a discipline that runs through every decision, from architecture down to the size of a single file. It requires someone who understands what "good" looks like and has a reason to care whether the output reaches it.
What Doesn't Get Automated
The skill that makes a senior developer valuable isn't typing speed. It's the ability to look at a system and understand it - to see not just what it does today, but what it will need to do in two years, and whether the current structure supports that or fights it.
That includes knowing when AI output is good enough and when it's going to create a problem. It includes reading generated code and recognizing the patterns that look fine on the surface but carry assumptions that don't fit the context. It includes pushing back on a requirement because the way it's framed will produce a worse outcome than a slightly different version of the same thing.
None of that is writing. All of it is the job.
AI has a real place in that job. Brainstorming works well - you're exploring before anything is defined, and having something to react to is faster than starting from nothing. The final coding step works well too, when you've already thought through what a function needs to do, what goes in and what comes out, and you want something to draft the expression. Both cases share the same condition: the thinking is already done. AI handles the output.
That's a genuine time-saver. It belongs in the toolkit.
What it doesn't do is replace the thinking that has to come before it. And that's where the fallacy takes hold - when the output gets treated as the work, and the work that produced it gets treated as unnecessary.
The companies that are going to regret this aren't the ones using AI. Using AI is fine. The ones that will regret it are the ones treating AI as a replacement for the judgment that makes software worth building in the first place.
The door still opens. That part works great. But something else is missing, and it's going to take a while to figure out what.
