Your Coding Assistant Is Not You

I was scrolling through Twitter (I will always call it Twitter…) the other day and I saw it again. Another developer posting about hitting their rate limit mid-flow. The panic. The frustration. The “no no no, not NOW” reaction. Then a service outage hits and my WhatsApp groups light up. Slack communities go into meltdown. Everywhere I look, developers are talking about that moment when their AI coding assistant goes silent and they realize they don’t know what they are going to do next. Rate limits, outages, degraded performance. Doesn’t matter what causes it. The reaction is the same.

That reaction? It looks a lot like addiction. Maybe not the clinical kind but rather that kind where a tool becomes so embedded in your workflow, that removing it feels impossible. And if you’ve been using AI coding tools for any length of time, you’ve probably seen it in yourself too.

The Numbers Tell a Story

Let’s start with what’s happening at scale. 84-90% of developers are now using AI coding tools. 51% use them daily. Claude Code grew 80x in a single year, far exceeding Anthropic’s planned 10x. Cursor went from zero to $2 billion ARR in three years. Uber burned through its entire 2026 AI budget by April because Claude Code spread across 5,000 engineers faster than anyone anticipated. These are not the adoption curves of a “nice to have” productivity tool. This is deep integration. This is dependency at an organizational level.

When Anthropic doubled usage limits as a “holiday gift” in December and then restored normal limits in January, developers experienced what felt like a 60% capacity reduction. One developer wrote during an outage: “Claude outages hit way harder when you realize you’ve outsourced half your brain to it.” The allure is real. And it’s by design.

AI Coding Tool Vendors Create the Lock-In

Here’s what I find interesting from an engineering perspective. The way these AI coding tool vendors have built their products actively encourages dependency. Credit systems with opaque limits. Rolling resets you can’t predict. That feeling of relief when you actually get that reset. Temporary promotional bonuses that set a new baseline and then get yanked. If you squint, it looks a lot like vendor lock-in patterns we’ve been warning each other about for years. Except this time, the lock-in isn’t in your infrastructure. It’s in your workflow. In your muscle memory. In the way you approach problems.

The UBC CHI 2026 study analyzed 334 developer self-reports and found consistent patterns: escalating usage, failed attempts to reduce, genuine distress when access is limited. The study’s senior author put it bluntly: “Deliberate design decisions by some of the corporations involved are contributing, keeping users online regardless of their health or safety.” Sound familiar? It should. We’ve spent decades talking about dark patterns in UX. This is the same playbook, now applied by AI coding tool vendors to their developer customers.

The Skill Erosion Problem

Here’s where it gets uncomfortable from a technical standpoint. Anthropic’s own randomized controlled trial found that developers using AI scored 17% lower on skill tests. Their own study. Their own tool! Making their own users measurably worse at coding. I’ve written before about the hidden costs of letting AI write your code unchecked. But this goes deeper than tech debt.

The METR trial is even more telling. Developers felt 20% faster. They were actually 19% slower. A 39-percentage-point gap between perceived and actual productivity. Think about what that means in practice. You’re shipping code you think you wrote faster. You didn’t. You’re making architectural decisions with less understanding of the codebase. You’re debugging less, which means you’re learning less about how your systems actually behave.

The de-skilling pipeline looks like this:

1. Delegate a task to the AI
2. The skill you didn’t exercise starts to atrophy
3. Next time, you have to delegate because you can’t do it yourself
4. Repeat until you’re stuck without the tool

It’s a dependency loop. And like any dependency loop in code, once you’re in it, breaking out requires deliberate effort.

And here’s what makes it addictive in the truest sense: the tool degrades the very skills you’d need to stop using it. That’s not just lock-in. That’s a trap.

We’ve Been Here Before (well… sort of)

Some perspective before the panic sets in. Developers worried that IDEs would make them forget command-line compilation. They were afraid that Stack Overflow would make them forget algorithms. They worried that frameworks would make them forget the fundamentals underneath. And honestly? Some of that happened. Plenty of developers can’t write a sorting algorithm from scratch anymore. I sure as hell can’t. But they can still build great software because the skill shifted, not disappeared.

So what’s different this time? The level of abstraction. Previous tools automated the typing. AI coding assistants automate the thinking. A code completion tool saves you keystrokes. An AI agent that writes your implementation, your tests, and your documentation is operating at the cognitive level. That’s a fundamentally different kind of dependency than anything we’ve dealt with before. That’s the part worth paying attention to.

Tools Don’t Define You

Here is the thing I keep coming back to. Your knowledge is yours. Your creativity is yours. Your judgment is yours.

A coding assistant can generate code. It can generate a lot of code, actually. But it cannot replace the thinking that tells you which code to write. Or why. Or whether you should write any code at all. The architecture decisions. The tradeoffs. The “this feels wrong” instinct that comes from years of getting burned by bad abstractions. The ability to look at a system and understand not just what it does, but what it should do. This is the bigger picture of what GenAI is doing to our profession. And it’s worth paying attention to.

That’s still you. That will always be you. A calculator doesn’t make you a mathematician. A GPS doesn’t make you a navigator. And a coding assistant doesn’t make you an engineer. These are tools. Genuinely good tools. But they don’t define who you are or what you’re capable of. The moment you let them replace your thinking instead of augmenting it? You’ve lost the plot.

Awareness Is the Fix

What do you actually do about this? You don’t quit using AI assistants. That’s not realistic and honestly it’s not necessary. The fix isn’t abstinence. It’s intentionality.

Some signals that you might have crossed the line from “using a tool” to “depending on a crutch”:

• You can’t start a task without opening the AI first
• You can’t debug without it. Not “prefer not to” but genuinely can’t
• Rate limits trigger genuine anxiety, not mild annoyance
• You accept AI output without reading it because “it’s probably fine”
• You haven’t written something from scratch in weeks
• You can’t explain the code that’s running in your own project

Any of these sound familiar? Be honest with yourself. The fix is simple in concept, harder in practice. Use the tool for what it’s good at. The boilerplate. The scaffolding. The “I know what I want but typing it out is tedious” stuff. But keep the thinking for yourself. The design decisions. The debugging. The “why does this even exist” questions. Exercise those muscles deliberately, the same way you’d go for a run even though cars exist.

My Challenge To You

Remember those developers I mentioned at the start? The ones panicking over rate limits? That panic is a signal. Not a sign that they need a higher tier plan. A signal that maybe they’ve let the tool become load-bearing in places where they should be load-bearing. And if you’re being honest with yourself, you might recognize a bit of that too.

Next time you hit a limit, or the service goes down, or you just feel that spike of frustration… Close the AI chat. Open a blank file. And write something yourself. Just to prove you still can.

---

I would be very interested to hear your thoughts or comments on this piece, please feel free to ping me on Twitter.