AI Coding Assistants Make Developers Worse, Not Better

Let me start with a confession. I used to be the developer who read RFCs for fun. Who would trace through a library's source code on a Saturday afternoon because I wanted to understand how something worked. Who kept a physical copy of Stevens' UNP on my desk not because I needed to look things up constantly, but because the act of reading it made me better at my job.

I don't do that anymore. And I blame AI coding assistants.

Wait — before you write me off as a curmudgeonly Luddite, hear me out. I'm not saying AI coding tools are useless. I'm saying they've created a structural incentive that is actively making developers worse at the things that actually matter. And I think the industry is in complete denial about it.

The Substitution Trap

Here's the thing about coding assistants: they're very good at substitution tasks. Given me the API signature, write the CRUD endpoint. Given me the test case, implement the function. Given me the bug description, generate the fix.

These are all substitution tasks. They involve taking a known specification and translating it into code. It's valuable work. It's also, if we're honest, the mechanical part of programming.

The hard part of programming — the part that takes years to develop and is genuinely valuable — is knowing what to build in the first place. Understanding a domain well enough to model it correctly. Identifying the edge cases that will cause failures in production. Designing APIs that are hard to misuse. Knowing when a simple solution is better than an clever one.

None of these are substitution tasks. They're judgment tasks. And here's my central claim: AI coding assistants are making us worse at judgment tasks while making us faster at substitution tasks. That's a terrible trade.

The Competence Cliff

Let me be specific about what I've observed.

I've watched junior developers — talented, smart, genuinely capable people — reach for AI completion within seconds of encountering any non-trivial problem. They don't struggle with it. They don't try to reason through it. They don't search for similar patterns in the codebase. They Tab through the suggestion and move on.

The problem: they're not building the mental model. When you fight with a hard problem, when you trace through why your first approach didn't work, when you have to actually understand something to make it go — that's when you develop the deep intuition that lets you handle novel situations. AI assistants skip that fight entirely. And the fight is where the learning happens.

I've also watched senior developers — people with 10-15 years of experience — use AI assistants so extensively that they start losing their edge. They stop keeping the full system in their head because they know the assistant can answer questions about it. They stop writing as many tests because the assistant can generate reasonable ones. They stop engaging with the hard parts because the easy parts are now so fast that there's no friction left to create the conditions for growth.

The competence cliff is real. And it's not just juniors. It's everyone.

The Citation Problem

Here's something nobody talks about: when you learn from a mentor, a book, or even Stack Overflow, you're learning from a source that had to be right. A book has technical reviewers. A mentor gets corrected by reality. Stack Overflow answers get downvoted when they're wrong.

AI assistants produce code that looks right. It often works for the simple cases they're trained on. And it routinely fails in subtle, catastrophic ways for edge cases that the training data didn't adequately represent.

The developer who learned the hard way knows where the edge cases are because they hit them. The developer who learned from AI suggestions has no idea what they don't know. This is the Dunning-Kruger problem in a new costume: the AI gives you just enough confidence to be dangerous without the underlying understanding that would let you know when you're out of your depth.

I've seen production incidents caused by AI-generated code that had subtle concurrency bugs, security vulnerabilities, and performance problems. In every case, the developer involved didn't catch it because they didn't have the mental model necessary to recognize the problem. The AI looked confident. The AI looked like it knew what it was doing. And the developer trusted it.

The Measurement Problem

Here's why this isn't going to get fixed: we're optimizing for the wrong thing.

Velocity metrics show AI assistants improving developer output. Lines of code per sprint go up. Features shipped per quarter go up. PR count goes up. These numbers look great in the dashboard. They're also meaningless.

What they're not measuring: the technical debt being accumulated. The architectural decisions being deferred because the AI can "fix it later." The institutional knowledge being lost because nobody has to understand the system deeply anymore. The security vulnerabilities being introduced faster than the team can find them.

I've talked to engineering managers who are genuinely alarmed by what they're seeing. They can't prove it quantitatively because the tooling for measuring software design quality, architectural coherence, and long-term maintainability doesn't exist in a form that feeds into sprint dashboards. So the story AI assistants tell is: more features, faster. And that's the story that wins in the quarterly review.

What We Should Be Doing

I don't think the answer is to ban AI assistants. That ship has sailed and the productivity gains on mechanical tasks are real. The answer is to be intentional about when we use them.

Use AI assistants for: boilerplate, documentation, test generation for code you understand, exploring unfamiliar APIs, refactoring code where you already understand the system.

Don't use AI assistants for: learning a new domain, designing system architecture, debugging hard problems, understanding legacy code, anything where the goal is to develop a mental model of how something works.

The developers who are going to thrive are the ones who use AI as a power tool, not a replacement for thinking. Who treat it like a very fast intern that needs supervision, not a mentor that can be trusted. Who understand what they're signing off on well enough to catch the ways it will be wrong.

The developers who are going to struggle are the ones who let the AI do the thinking for them, who Tab through suggestions without understanding them, who ship AI-generated code to production without understanding why it works.

The gap between those two groups is going to be enormous. And I think the industry's casual embrace of AI coding assistants — without any serious conversation about the tradeoffs — is setting up an entire generation of developers to be fundamentally less capable than the ones who came before.

We can do better. We just have to be honest about what we're trading away.