DEV Community

Cover image for Is Claude taking control of my development skills? I went looking for proof.
Rudratosh Shastri
Rudratosh Shastri

Posted on

Is Claude taking control of my development skills? I went looking for proof.

Last Tuesday I hit a bug. A React component was rendering stale data. Two years ago, I'd have known the problem on sight.

This time, my hand moved before my brain did. I selected the code, hit my Claude shortcut, and typed "fix this."

useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1);   // always 0 + 1. classic stale closure.
  }, 1000);
  return () => clearInterval(id);
}, []);   // empty deps = count is frozen at its first value
Enter fullscreen mode Exit fullscreen mode

Claude fixed it in four seconds. Used the functional update, setCount(c => c + 1). I hit accept and moved on.

Then I stopped, because something felt off. I hadn't solved anything. I'd pattern-matched "bug" → "ask Claude" and skipped the part in the middle, the part where I used to actually understand what was broken. That's a bug I'd explained to junior devs a dozen times. And I'd just outsourced it without a thought.

So I asked myself the honest question: is Claude quietly taking my skills? And instead of answering with a gut feeling, I went and read the actual research. Here's what I found, including a study from Anthropic itself, and the one habit that fixed it for me.


It's not man vs machine. It's a quieter thing.

"Taking control" sounds dramatic. The truth is boring and worse: it's cognitive offloading. When you hand a mental task to a tool, your brain does less of the work. And the work is the skill.

You already know this from real life:

  • GPS. A 2017 Nature study put people through virtual London streets. The ones following turn-by-turn directions showed measurably less activity in the hippocampus, the brain's map-maker, than people navigating on their own. Offload the navigating, and the navigating muscle goes quiet.
  • The gym. A forklift moves the weight faster than you ever could. That's not the point. Lifting it yourself is the point.

Claude is a forklift for code. Incredible leverage. And if I let it lift everything, I stop being able to lift anything.

The question is whether coding this way does to my debugging what GPS does to your sense of direction. Turns out, people have measured it.


Proof #1: You feel faster. You're measurably slower.

This is the one that rattled me, because it attacks the thing I trust most, my own read on how a session went.

Developers felt 20% faster with AI but were measured 19% slower

Researchers at METR ran a proper experiment in early 2025. 16 experienced open-source developers. 246 real tasks in repos they already maintained. Half the tasks: AI allowed (Cursor + Claude). Half: AI forbidden. Then they measured the clock.

  • Before starting, the devs guessed AI would make them 24% faster.
  • After finishing, they felt it had made them about 20% faster.
  • The stopwatch said they were 19% slower with AI.

Sit with that. They were slower, and they couldn't feel it. A ~39-point gap between how fast they felt and how fast they were.

That's the dangerous part. A skill you're losing while feeling more productive is a skill you'll never catch yourself losing.

(Honest caveat: small sample, and METR says it doesn't generalize to all work. But the perception gap is the scary bit, and it matches everything below.)


Proof #2: Anthropic studied its own tool. The result is brutal and fair.

This is the study that actually changed how I work. And it's remarkable because it comes from the company that makes Claude.

They took 52 developers learning Trio (a Python async library, new to all of them). One group coded with an AI that could hand them correct code on request. The other group hand-coded. Then everyone took a quiz, debugging, reading code, writing code, concepts, on stuff they'd used ten minutes earlier.

AI-assisted developers scored 50% vs 67% on comprehension, worst on debugging

  • Hand-coders averaged 67%.
  • AI-assisted averaged 50%. Seventeen points lower. Nearly two letter grades.
  • The AI group saved about two minutes. Not even a statistically real difference.
  • The biggest gap was on debugging — the exact skill you need the second the AI's code breaks.

So the trade was: two letter grades of understanding, for two meaningless minutes. That's the trade I'd been making on autopilot in my useEffect.

But here's the part that saved me from just rage-quitting Claude: it wasn't the AI that did the damage. It was how they used it.

The devs who bombed the quiz (under 40%) were the ones doing pure delegation, "write this for me," dump the error in, take the fix. The devs who aced it (65%+) were the ones asking Claude to explain — generate, then understand; ask "why this approach"; work through the error themselves.

And the explainers weren't slow. Asking conceptual questions was the second-fastest pattern in the whole study.

You don't have to choose between shipping and learning. You have to choose between delegating and understanding. And in the moment, those two feel almost identical.


The difference is literally how you type the prompt

This is the whole article in one example. Same bug, two prompts.

❌ The prompt that deskills me:

fix this
Enter fullscreen mode Exit fullscreen mode

I paste code, I get a diff, I hit accept. I learned nothing. My brain logged "handled," not "here's why."

✅ The prompt that teaches me:

This useEffect shows stale data. Don't rewrite it yet —
explain WHY the count is frozen, then show me two ways to fix it
and the tradeoff between them.
Enter fullscreen mode Exit fullscreen mode

Now Claude tells me it's a stale closure: the effect captured count at its first value and the empty dependency array froze it there. It shows me setCount(c => c + 1) (functional update) and adding count to the deps (re-subscribes the interval), and explains why the functional update is usually better here.

Same four seconds. Same correct answer. Completely different outcome in my head. One makes Claude my hands. The other makes it my senior engineer who explains while we work.

That's not a philosophy. That's the Anthropic data: the first prompt scored ~38%, the second scored ~70%.


Proof #3: You can see it in the commits

If skills are quietly eroding across the industry, you'd expect it to show up in the code we actually ship. It does.

GitClear studied 211 million changed lines from 2020 to 2024, right across the window AI assistants went mainstream.

Copy-paste up, refactoring down since AI assistants went mainstream

  • 2024 was the first year on record where copy-pasted code beat refactored (moved) code. We're pasting more than we're consolidating.
  • Refactoring fell off a cliff — "moved" lines dropped from ~25% (2021) to under 10% (2024).
  • Duplicated blocks (5+ identical lines) jumped roughly 8x in 2024.

It's correlational, not a smoking gun. But it lines up: AI makes it trivial to insert a block and rarely nudges you to reuse what's already there. The codebase gets fatter. And the understanding of why it's shaped that way lives nowhere, because nobody wrote it, Claude did, and you accepted it.

There's even a name for this now: Knowledge Debt — technical debt's quieter cousin that lives in your head instead of the repo. Every "accept" on code you didn't understand is a withdrawal.


Let me be fair: the other side is real too

I'm not here to tell you to delete Claude. That'd be stupid, and dishonest.

  • These studies are early and small. Anthropic's devs were learning a new library — that's not the same as a senior engineer forgetting what they know.
  • Deskilling is a slope, not a cliff. You don't wake up unable to code. You slowly stop reaching for a skill until it's rusty. Which means you can catch it.
  • The leverage is genuinely incredible. I've shipped entire projects with Claude I'd never have attempted solo. That's not a small thing.

The evidence doesn't say "AI makes you worse." It says "AI makes you worse if you let it do the thinking, and better if you make it do the explaining." That line is the entire game.


My field guide: using Claude without going soft

Here's what I actually changed. Concrete rules, not vibes.

1. The 10-second rule. Before I paste a bug into Claude, I give myself 10 seconds to say out loud what I think is wrong. Even a guess. Then I ask Claude. Half the time I was right and just lazy. The other half, now I'm actually learning instead of skipping.

2. "Explain, don't just fix." My default debugging prompt is now literally:

Explain why this is broken before you fix it.
Enter fullscreen mode Exit fullscreen mode

Five words. Keeps me in the loop. Keeps the senior engineer, loses the vending machine.

3. Read the diff like it's a PR from a junior. Would I approve this in review? If I can't say why it works, I don't accept it, I ask, or I rewrite it.

4. One hard thing a week, cold. Once a week I take a real problem and solve it with Claude closed. It's slower and slightly humbling. That's the gym. The slowness is the whole point.

Here's the split I try to stay on the right side of:

❌ Erodes the skill ✅ Builds the skill
Accept the diff without reading it Read it, then accept
"Write this feature for me" "Explain the approach, then I'll write it"
Paste the error, take the fix Guess first, then compare with Claude
Trust it because it compiles Verify it because you understand it
Let it refactor code you don't grasp Refactor it yourself, ask Claude to review

Every single row is the same choice: delegation vs understanding. The left column cost those developers two letter grades. The right column cost them almost nothing but a little friction.


So, is Claude taking control?

No. And honestly, that's worse.

Claude isn't taking anything. I'm handing it over, one frictionless "accept" at a time, feeling more productive the whole way down, which is exactly how the METR study says it would feel.

The tool just amplifies whatever I bring to it. Bring laziness, and it deskills me with terrifying efficiency. Bring curiosity, make it explain, guess before I ask, verify every diff, and it becomes the best mentor I've ever had, available at 2am, infinitely patient, never annoyed at the dumb question.

The skill I actually have to protect isn't React, or async, or debugging. It's the judgment to know when to let Claude think for me and when to make myself do it. That's the one thing I can't outsource, because the moment I do, there's nobody left to make the call.

I'm keeping Claude. I'm just not closing my eyes anymore.


Sources (all with caveats noted inline above): METR RCT on experienced-developer productivity (16 devs, 246 tasks); Anthropic, "How AI assistance impacts the formation of coding skills" (52 devs, 50% vs 67%, Cohen's d=0.738, p=0.01); GitClear 2025 AI Code Quality report (211M lines); MIT Media Lab, "Your Brain on ChatGPT" (arXiv:2506.08872, not peer-reviewed); Nature Communications (2017) on GPS and hippocampal activity. Several are preprints or correlational.

Quick gut-check before the comments: last time you asked Claude to fix something, did you type "fix this" or "explain why it's broken"? Be honest. That answer is the whole study, run on a sample size of you. 👇

Top comments (1)

Collapse
 
alexcodebytes profile image
Oleksandr •

The METR perception gap (felt 20% faster, actually 19% slower) is the most dangerous finding in the article, because it means the skill loss is invisible from the inside. You can't fix what you can't feel.

The 10-second rule is the practical hack I'd steal. But I'd add a harder version: the "explain to a rubber duck first" rule. Say it out loud to a non-technical listener (or an empty room). If the explanation sounds vague, ask Claude. If it sounds specific, you probably already know the fix and just don't want to type it.

Curious about the GitClear data — the "copy-paste up, refactor down" trend correlates with AI, but it also correlates with the rise of "move fast" startup culture. How do you separate the two effects?