DEV Community

Anshul Rajpal
Anshul Rajpal

Posted on Edited on

AI Coding Assistants: Helpful Pair or Crutch? The Numbers Say Something Uncomfortable.

Claude Code

I use AI coding assistants every day. So do you. If you're a developer in 2026, you probably do.

But have you ever wondered: am I becoming faster, or am I becoming dependent? Am I learning more, or am I outsourcing my thinking?

The numbers say something uncomfortable. And it's not what the tech bros want you to believe.

The adoption numbers

Let's look at the data. JetBrains surveyed 15,509 professional developers from May to July 2026. Their findings:

  • 90% of developers use AI coding agents at work at least weekly
  • 68% use them daily
  • Claude Code is the most used: 39% of developers use it at work, up from 18% in January 2026
  • GitHub Copilot is declining: 21%, down from 29% a year ago
  • OpenAI Codex is rapidly catching up: 16%, up from 3% in January 2026
  • OpenCode: 7% adoption with 42% mindshare among developers

The adoption numbers are staggering. Almost every developer you work with is using AI tools. Most of them daily.

But adoption is not the same as effectiveness. And it's not the same as learning.

GitHub Copilot

The METR study: slower but thinks faster

Here's where it gets uncomfortable.

METR ran a study on 16 experienced open-source developers. They were given coding tasks, some with AI assistance, some without. The results:

  • Developers with AI were 19% slower
  • But they believed they were 20% faster
  • They felt productive

The clock disagreed. Their confidence didn't.

This is the Dunning-Kruger effect in action. People think they're doing better when the AI is helping, but the clock says otherwise.

Why are they slower? Because they're reviewing. Every AI suggestion needs verification. Every AI output needs checking. Every assumption needs confirmation.

The Anthropic study: comprehension suffers

This is not a new finding. A similar study by Anthropic in February 2026 found something similar. Fifty-two mostly junior engineers were asked to learn a programming library. Half got an AI assistant on top of search and documentation. The other half got search and documentation only.

Both groups finished in about the same time. But on the comprehension test afterwards, the AI-assisted group scored 17% lower.

They got the job done. They understood less of what they had done.

This is the real danger. Not that AI makes you slower. But that it makes you learn less.

The trust gap

There's another number that should worry you: only 6.6% of developers trust AI-generated code for making important work decisions.

That's it. Less than 7%.

The DX Q2 2026 AI Impact Report shows that more than 9 in 10 engineering organizations use AI in their development work. But only 6.6% trust it with important decisions.

What does this mean? Developers are using AI tools. They're generating code with them. They're even shipping code. But they don't trust it for important work.

They know the AI is making mistakes. They know it's hallucinating. They know they need to review everything.

OpenCode

What the daily workflow actually looks like

For most developers, the day starts with an AI tab open. You describe a task, the agent writes a draft, you review it, you fix the edge cases, you ship it.

That loop is real, and it is fast. The problem is what happens to the parts of the job that used to sit between those steps.

Reading the codebase used to be how you learned it. Now the agent reads it for you. Debugging used to be how you built intuition. Now the agent suggests the fix and you confirm it. Code review used to be how you caught mistakes. Now the agent writes the code and you are the safety net.

Every one of those steps taught you something. When the agent takes them over, you stop practicing them. You still ship. But you are practicing a narrower skill: prompting and reviewing.

That is not nothing. Reviewing well is a real skill, and it matters more than ever. But it is not the same as understanding the system.

The power drill, not the foreman

Here's what I think is happening.

AI coding assistants are tools. They're like power drills. They can help you drill holes faster. They can help you do repetitive work. They can make you more efficient.

But they're not foremen. They don't know what the building should look like. They don't know what the user needs. They don't know the constraints of your codebase.

The METR study found developers were 19% slower. Why? Because they were reviewing the AI's work. They were checking for errors. They were verifying results.

They felt productive because they were moving fast. But the clock said otherwise.

What this means for you

If you're a junior developer, be careful. The AI-assisted group in the Anthropic study scored 17% lower on comprehension. You might finish your tasks faster. But you might understand less.

Learn the fundamentals. Write code from scratch. Debug without AI. Then use AI to accelerate your work.

If you're a senior developer, you already know the fundamentals. Use AI to accelerate your work. Review everything. Trust nothing blindly.

If you're a team lead, set clear expectations. Use AI as a productivity tool, not a replacement. Create a culture of review. Require understanding before shipping.

The honest verdict

AI coding assistants are helpful. They're also potentially harmful.

They save time. They reduce boring work. They help you iterate faster. They're like power drills.

But they can also create dependency. They can create false confidence. They can make you slower than you think.

The question isn't whether AI coding assistants are good or bad. The question is whether you're using them the right way.

Are you using them as a power drill? Or are you using them as a foreman?

OpenAI Codex

Where the market is heading

The adoption data tells a story about where this is going.

Claude Code has more than doubled since January, from 18% to 39%. It's now used twice as often as GitHub Copilot. Copilot, which led the market for years, has declined from 29% to 21%. GitHub is losing ground.

Codex is growing at 5x, from 3% to 16%. That's explosive growth in six months.

OpenCode, the open-source tool, has 7% adoption but 42% mindshare. Developers know it, even without a big company behind it.

The tools are consolidating. The winners are the ones that fit the workflow. And the workflow is shifting from autocomplete to agents that can run commands, edit files, and manage a whole task.

The bottom line

AI coding assistants are not going away. 90% of developers use them. The question is whether you use them deliberately.

Use them for the boring parts. Use them to iterate faster. Use them to explore unfamiliar code.

But keep the understanding yours. Read every line before it ships. And every now and then, turn it off and write something from scratch, just to make sure you still can.

What do you think? Have you noticed your productivity going up or down when using AI assistants? Have you found yourself relying on them too much? Drop a comment. I want to hear your experience.

Top comments (6)

Collapse
 
alexcodebytes profile image
Oleksandr •

The METR study hits way too close to home. It is incredibly easy to fall into the trap of feeling like a genius while the AI generates hundreds of lines of code, only to realize you've spent the last hour acting as a very stressed-out code reviewer.

But the Anthropic study about the 17% comprehension drop is the truly terrifying part. The "struggle" of reading a new codebase, getting frustrated, and debugging without help is exactly what builds those mental models. If juniors outsource the struggle, they might be able to ship features, but they'll never truly understand the architecture. We need to normalize turning the AI off to actually learn.

Collapse
 
unfiltered_anshul profile image
Anshul Rajpal •

Exactly my point I have another blog explaining the exact problem where AI is making junior developers worse. Check that out and I wrote it based on my personal experience. AI era has hurdled ppl who actually understand the system and the fundamentals heavily relying on AI is what the corporate greed wants but this is much worse.

Collapse
 
alexcodebytes profile image
Oleksandr •

Spot on. The "corporate greed" angle is a huge part of this. Companies love the illusion of velocity that AI provides, prioritizing short-term metrics over the long-term depth of their engineering teams. It's a dangerous trade-off. I'd love to read your blog post about junior developers—feel free to drop the link here!

Thread Thread
 
unfiltered_anshul profile image
Anshul Rajpal •

dev.to/unfiltered_anshul/unpopular...

dev.to/unfiltered_anshul/i-think-a...

dont mind the images lol I couldnt find any better ones

Collapse
 
onelifevibe profile image
OneLifeVibe •

The METR finding is the one that stays with me, 19 percent slower while feeling 20 percent faster. That gap between felt speed and measured speed explains a lot of the debate in the comments. The Anthropic comprehension result is the harder problem though. Speed can be measured and fixed, but understanding quietly leaking away shows up months later, when the person who approved the code has to debug it. The power drill analogy lands because a drill never pretends to know the plan. Keeping the understanding yours is the right line to draw.

Collapse
 
unfiltered_anshul profile image
Anshul Rajpal •

True. On point