Ever since AI tools started generating halfway-decent code, the fear was always the same: one day, someone with no technical background would write something with Claude or Copilot and want to ship it. We pictured it as a slow wave, a freelancer cosplaying as a developer, a founder trying to cut costs. We thought we had time.
What nobody anticipated was that it would come from inside the house.
What happened
Someone in my dev circle went through this recently. A manager, armed with Claude and a generous amount of confidence, submitted code to his team with a simple request: ship it. The team refused. The issues were obvious, misconfigured API calls, hardcoded environment variables, the kind of thing you only produce when you have never actually had to deploy anything for real.
The manager pushed back. Multiple times. In meetings. In writing. Until the pressure shifted the question from "do we deploy this" to "do we fix it first or let it go as-is."
That is where it gets interesting.
The babysitter dilemma
You have two options.
Option one: deploy it as-is. It breaks, the proof is in the logs, everyone sees it was a bad idea. Except you just knowingly shipped broken code to production, and you are the one handling the fallout.
Option two: spend your time rewriting, fixing, and testing code you did not write, for a decision you already refused. You are now the babysitter for someone else's bad idea. And the implicit message you are sending is that this is an acceptable way to work.
Both options are bad. Which is exactly why this keeps coming up on Reddit. This thread on r/NoStupidQuestions asked the question directly, and the responses made one thing clear: this is not an isolated case. It is systemic.
Why this breaks something deeper
The problem is not technical. Well, it is, but that is not where it starts.
In a functioning company, everyone has a role tied to their skills and what is expected of them. A developer writing code is normal, it is the job. A manager writing code and pushing it over the objection of the technical team is a governance problem, not a technology one. The fact that the tool used was Claude or any other LLM does not change that.
What this reveals is that some managers have started seeing AI as a way to reduce their dependency on the tech team. The problem is that coding is not just writing lines that execute. It is knowing why they execute, in what context, under what constraints, and what happens when they stop. The localhost:3000 sitting in the environment variables, the API key hardcoded in the config file, the third-party service that requires an undisclosed paid plan: that is exactly what you find in code generated quickly and shipped with conviction.
And what about developer value
Honestly, I do not have a clean answer.
What I know is that what happened to that team is not an AI problem. It is a decision made without the skills to understand its consequences. AI just made that problem more accessible, more frequent, and harder to refuse politely.
The real question it raises: is developer value increasingly becoming the ability to validate, fix, and absorb other people's mistakes, or does it stay rooted in the ability to build something coherent from end to end?
What would you do?