When AI Quietly Makes You the Programmer

I get in arguments with people about their weekend "coding" projects. A manager will corner me on a video call, eyes wide, sharing their screen to show off an inventory tracking dashboard they spun up on Sunday using an AI coding assistant. "I built this in three hours," they say, clicking around the interface. "I don't even know React."

Getting an idea out of your head and onto a screen in a single afternoon is a neat trick. I have to admit that. The friction between a thought and functional software has practically dropped to zero. You just describe what you want and the machine types it out. This is a massive shift in how things are made, but that speed is exactly the trap.

Because the prototype works. Until Tuesday.

The quiet descent into a second job

On Tuesday, you notice a bug. The inventory dashboard doesn't handle negative stock values when a return is processed before the original order is marked shipped. So you go back to the AI. You write a prompt to fix the negative stock issue. The AI spits out an updated file. You paste it in. It works.

But now the search bar is broken.

So you send it another prompt. The search bar is fixed, but you notice the layout shifts weirdly on mobile. Was that always there or did your recent fix cause it? By Thursday, your team is starting to wonder if you're out on vacation. You are managing state in a React component you don't understand.

You quietly adopted a second job.

I see leaders using AI to quickly prototype apps, completely unaware that they are taking on a full-time development role. The AI removed the mechanical friction of typing code. But it also bypassed the judgment and pushback of a senior engineer.

When you hire an engineer, you aren't paying them for their typing speed. You are paying them to say, "If we do this, it will break that." You are paying them to understand the hidden architecture of the problem space. The AI doesn't do that, especially if you didn't ask it to. It just types really, really fast. And if you tell it to type something stupid, it will happily oblige with the worst possible logic.

It's messy but it works! Until you realize that you are now the sole maintainer of a codebase written by a hallucinating junior developer who quits immediately after every prompt.

We already knew software was mostly maintenance

I do not know where the idea came from that writing the first version of the code is the hard part. It was probably born out of watching movies where hackers type furiously for 30 seconds and say, "I'm in."

But I was reading Fred Brooks a while back, and he pointed out the difference between essential complexity (the actual difficulty of the problem you are solving) and accidental complexity (the difficulty of the tools you are using to solve it). AI drastically reduced the accidental complexity of writing syntax. But the essential complexity remains untouched.

Ward Cunningham's idea of technical debt surfaces exactly the same problem. When you use AI to bash out a prototype, you are taking out a massive loan. The AI is making structural decisions and coupling components in ways you cannot see. You get the immediate payoff of a working app, but you accumulate interest at an alarming rate.

We've always known software is mostly domain knowledge and maintenance. AI expanded the pool of people who can write software but not the pool of those who understand software.

Find the handoff

So where do we go from there? Should we all immediately stop using AI to build things?

No. That's ridiculous. It's so ridiculous especially because prototyping is incredibly valuable. If you can use AI to explore a problem space, to build a disposable prototype that proves out a concept, you absolutely should.

But pay attention to the handoff point on the horizon.

Prototyping is exploration. Maintenance is a job. Once the app moves from a neat demo to something the operations team relies on every day, you have crossed a boundary. The quick win becomes a maintenance trap.

This is the exact moment to re-engage actual engineers. You hand them the prototype and say, "This is the business logic we need. Now build it so it doesn't collapse." You bring them in for their judgment and their ability to say "no."

If you try to maintain it yourself, you will spend your days writing increasingly frantic prompts trying to fix regressions. You will be playing a very slow, very expensive game of whack-a-mole.

The job you never interviewed for

The dashboard you spun up on Sunday afternoon was a brilliant piece of exploration. It proved that the friction of making things is lower than it has ever been. But it came with a quiet, invisible consequence.

You adopted a codebase. You took on the creeping responsibility of keeping it running and fighting its dependencies the second someone else starts relying on it. The machine will happily keep generating patches and workarounds, stacking brittle abstractions on top of each other until it collapses into a mess of unpredictable state.

Every time you go back to the prompt box to fix a broken search bar or untangle a bizarre edge case, you are making a choice. You are stepping away from the work you were actually hired to do, slipping further into a role you never formally interviewed for. The AI wrote a script, and in the process, quietly hired you as a maintenance programmer. And unless you recognize the exact moment to let it go and hand it over to a professional, you are deciding that this is the job you want.