I know this is an unpopular take in certain circles. I know there are studies. I know the benchmarks show velocity improvements. I've read the ones that say AI coding assistants make developers 50% faster, 70% more productive, whatever number makes the slide deck look good.
I'm not interested in defending the studies that say otherwise, and I'm not going to cite research to back up my gut feeling. What I have is eighteen months of watching engineers at multiple companies go from competent to dependent, and it's happening in plain sight while the industry celebrates productivity metrics that measure output without measuring cost.
When you measure "developer productivity," you're usually measuring lines of code, PRs merged, features shipped. These are output metrics. They tell you what got done, not what it cost to get it done, and they tell you nothing about what happened to the engineer who did it.
Here's what the metrics don't capture:
An engineer who shipped three features last month with AI assistance, but who now takes twice as long to debug a problem without AI assistance, has a net negative productivity change. Their output went up. Their capability went down. You measured the wrong thing.
An engineer who can write a solid authentication flow in an hour with AI assistance, but who would take three days to do it from scratch, is not a 3x productivity improvement. They're a dependency on a tool that may not always be available, affordable, or appropriate for the task.
An engineer who uses AI to generate code they don't understand, and who can't debug it when it breaks, has shipped technical debt that will take multiples of the original velocity gain to pay back.
I've seen this pattern repeat enough times that I think it's worth naming.
An engineer starts using an AI coding assistant. They find it genuinely helpful for boilerplate, for documentation, for translating their intent into syntax. They ship more features. Their team lead notices and celebrates. Everyone's happy.
Then the engineer starts using it for things they should know how to do themselves. Not because they can't figure it out — because it's faster. They tell themselves they're being efficient. They ship more features. Everyone's still happy.
Then one day the AI tool is unavailable, or the task is too unusual for the AI to handle well, or the generated code has a subtle bug that needs real understanding to find. And the engineer who was competent eighteen months ago, who could have figured this out without assistance, now stares at the problem like it's written in a foreign language.
This is the hidden cost. Not just reduced capability over time — accelerated capability decay. The engineer isn't maintaining their skills because the AI handles the tasks that would have maintained them.
Here's my actual complaint: the industry has decided that shipping features is the goal and that anything that helps is good. This is the wrong optimization target, and it's creating a generation of engineers who are increasingly dependent on tools they don't understand.
The engineers I'm worried about aren't junior developers using AI to bridge gaps in their knowledge. That's fine. Learning involves using tools, and AI tools can accelerate learning if used correctly.
The engineers I'm worried about are mid-level engineers who used to be solid, who are using AI to avoid practicing the skills that made them solid, and who are shipping code they don't fully understand at rates that look impressive in velocity metrics but that will cost them and their teams when the AI tool isn't available or when the codebase gets complex enough that AI-generated code starts failing in subtle ways.
Here's the thing I believe that makes people angry: AI coding assistants, as currently used by most engineers, are a net negative for engineering capability development.
Not for productivity. Not for shipping features. For the development of engineering capability as a craft.
If you're a company that wants to ship as many features as possible in the next two years and you don't care what happens to your engineering team's capabilities in five years, use AI coding assistants aggressively and optimize for velocity.
If you're a company that wants engineers who can think through hard problems, who understand their systems deeply, who can debug complex issues without AI assistance — you need to be thoughtful about how you introduce AI tools, and you need to accept that some productivity sacrifice in the short term might be worth capability preservation in the long term.
Most companies won't make this trade. That's their choice. But at least make it consciously, knowing what you're trading away.
*I know this take will generate disagreement. That's fine. The discussion about AI tools in engineering shouldn't be dominated by productivity metrics that measure output without measuring cost to capability. Have the conversation. Disagree with me. But notice if the people disagreeing most strongly are the ones selling AI tools.*