The honest answer is no, but with a condition attached that matters more than the answer. AI is not a threat to developers who adapt and keep control of what they ship. It is a real threat to developers who hand it their judgement. The technology is the same in both cases. The difference is entirely in how the developer uses it, and that is the part worth talking about, because "is AI a threat" is the wrong question. "What kind of developer does AI make obsolete" is the right one.
AI raises the floor, which moves the value
What AI actually does is raise the floor on technical execution. Writing a function, scaffolding a component, producing boilerplate, wiring up a standard pattern: all of that is faster and more accessible than it was. The work that used to take skill to type out now takes a prompt.
When the floor rises, the value moves up with it. The thing that is scarce is no longer the typing. It is the judgement: knowing what to build, what to reject, what is correct, what will cause problems later, what the AI confidently got wrong. Those are the things that did not get automated, and as the mechanical parts get cheaper, the judgement is worth proportionally more. A developer who has that judgement is not threatened by a tool that handles the mechanical parts. They are amplified by it. They get to spend their scarce attention on the decisions and let the tool handle the execution underneath those decisions.
So for a developer who is genuinely good, AI is not a competitor. It is leverage.
The condition: keep control of what you ship
Here is where the condition bites, and it is the whole thing. The leverage only works if you stay in control of what you are shipping. The moment you let the AI make the decisions instead of executing yours, you have inverted the relationship, and now you are the one being led by a tool that has no judgement, no stake in the outcome, and no understanding of the project beyond the prompt in front of it.
This is the same point I make about knowing what you are shipping. You are accountable for what goes live, and you cannot be accountable for something you did not actually decide. A developer who accepts AI output without understanding it is not faster. They are shipping things they cannot stand behind, accumulating code they cannot reason about, and slowly losing the ability to tell good output from confident nonsense. That developer is genuinely threatened, not by AI replacing them, but by their own judgement atrophying until there is nothing left that the tool cannot do, because they stopped exercising the thing that made them valuable.
The defence is unglamorous and old-fashioned: keep reading the documentation. Keep understanding the things you use rather than letting the AI be your only source of explanation. The developers who stay sharp are the ones who treat AI as a faster way to execute decisions they understand, not as a replacement for understanding. They direct it. They check it. They keep reading the actual docs so they can tell when it is wrong. That habit is what keeps the relationship the right way round.
The real divide
So I do not think the question is whether AI threatens developers. It threatens a specific kind of developer: the one who uses it to avoid thinking rather than to think faster. For that person, every month makes them more replaceable, because they are training themselves to do less of the only thing that was ever hard to replace.
For the developer who adapts while keeping control, the same tool does the opposite. It removes the drudgery and leaves them more time for the judgement, the architecture, and the decisions that AI cannot make. The technology does not decide which of those two you become. You do, with every choice about whether to understand what you just shipped or to wave it through. Adapt, use the leverage, and keep your hands on the wheel. The threat was never the tool. The threat is letting the tool think for you.
