Is AI Making You a Worse Developer? Anthropic's Data Says Yes. Here's the Fix

Is AI making developers worse? In the best controlled study I've found, yes. Anthropic had 52 mostly junior engineers learn Trio, a Python async library. The ones who used an AI assistant scored 17 points lower on the follow-up quiz than the ones who wrote the code by hand, and the gap was widest on debugging questions, which is the part of the job you get paged for at 3 a.m.

This week Hacker News had three threads on this going at once: SREs losing incident skills, Cisco handing a 27-year-old unlimited tokens to rewrite legacy code, and a lot of developers admitting they're just tired. Read next to the study, they're the same problem.

SigNoz on SREs losing incident skills

SigNoz's newsletter ran a piece called "AI isn't replacing SREs, it's deskilling them". According to the piece, AI now handles alert grouping, runbook execution, log pattern detection and auto-remediation for the easy failures, like restarting a crashed pod. Humans keep the leftovers: the novel, cascading, nobody-has-seen-this-before outages.

The author asks: "When AI handles 95% of your incident response, do you get worse at handling the 5% that actually matters?"

None of this is new. Lisanne Bainbridge described it in 1983 in "Ironies of Automation": the more you automate, the more the human matters during the rare failure, and the less practice that human has had. The article lists what this looks like on an on-call rotation:

You stop reading raw logs because the AI summarizes them.
You stop forming hypotheses because the AI suggests a root cause.
You stop building a mental model of the architecture because the AI maps dependencies for you.

Each of those is a productivity win on its own. Stack them up and you get an engineer who can't function when the summary is wrong.

The HN thread (601 points, 452 comments) mostly agreed, then argued about whether anyone will pay to fix it. digitallogic: "In the moment, getting the broken thing back up and running is seen as far more important than the learning opportunity." sshine got the whole article down to one line: "Atrophy happens when you trade understanding for productivity."

Cisco gives one engineer unlimited AI tokens to rewrite legacy code

The same week, Fortune reported that Cisco president Jeetu Patel handed Padmanabhan "Paddy" Krishnamurthy, 27, unlimited AI tokens to refactor Cisco's legacy code. Krishnamurthy pitched it as a job for a two-person team and has four weeks to prove the idea. The end goal is 98% of Cisco's legacy code refactored within 24 months.

"I've given him unlimited tokens because he's going to refactor code," Patel said. "So I'm like, you can go, you can go nuts."

I have nothing against the guy. He co-founded a startup Cisco acquired, so he has shipped real things. My problem is the framing. Executives now treat tokens as the scarce resource, and on a rewrite like this they aren't. The scarce resource is people who understand what the old code actually does, including the bugs customers depend on without knowing it.

The HN thread on that one went straight there. cromka: "some of the bugs have become features without users even knowing it." raizer88 had the punchline: "Followup question: did anyone read the automated test suite? Silence. The software rewrite is shelved."

So in one week we got engineers losing the ability to debug their systems, and a company betting it can rewrite its legacy code faster than anyone can read it.

What the research says about AI deskilling

Software isn't the only field with data on this:

| Field | Study | What happened |
|---|---|---|
| Software | Anthropic RCT, Jan 2026, 52 mostly junior engineers learning Trio | AI group ~50% on the quiz vs ~67% hand-coding. Biggest gap on debugging. Time saved: ~2 min, not statistically significant |
| Medicine | Budzyń et al., Lancet Gastroenterology & Hepatology00133-5/abstract), 4 Polish centres | Adenoma detection in non-AI colonoscopies fell from 28.4% to 22.4% after doctors got used to AI assistance |
| Aviation | Behrend & Lafargue, IASS 2019 | Air France eye-tracking study: hand-flying with the flight director on doesn't build the basic skills that flying with it off does, and long-haul pilots are most exposed to skill erosion. The SigNoz piece makes the same comparison with the FAA and manual flying time |

The Anthropic one is worth reading in full. The authors are open about its limits (small sample, quiz taken right after a 35-minute coding task), and they say agentic tools like Claude Code could hit skill development harder than the sidebar chat assistant they tested.

The most useful part is the breakdown by how people used the AI. The groups are tiny (two to seven people each), so treat this as a hint. Participants who delegated everything scored around 39%. The "iterative AI debugging" group, the ones who kept pasting errors back in until something worked, scored about 24% and were also the slowest at roughly 31 minutes. The two people who generated code and then asked follow-up questions to understand it scored about 86%.

The way you use the assistant seems to matter more than whether you use one. The worst pattern in that study, on both speed and learning, was "paste the stack trace, apply the patch, repeat".

Developers are also exhausted

The third thread, "Ask HN: Are you tired too in this AI era?" (144 points, 139 comments), started with the poster describing having to "read enormous amounts of generated text." thunfischtoast: "I feel my brain atrophying. I forget how to do things." Gigachad, on PRs nobody understood: "I just don't have time to review 4000 lines of code."

This worries me more than the study. Tired engineers rubber-stamp, and rubber-stamping builds no mental model. The 3 a.m. outage then lands on someone who has approved a lot of diffs and understood very few of them.

5 ways to keep AI from deskilling you

I'm not giving up the tools. They're too good at the boring 80%. But I've started following a few rules, and they cost almost nothing.

1. Debug by hand for a few hours a week

Pick a block each week (I use Friday afternoons) where any bug you touch gets debugged with no assistant: logs, git bisect, a debugger, strace if it comes to that. On-call teams can copy the SigNoz suggestion of "deliberate inefficiency": send some incidents the AI could resolve to a human as practice. Airlines push pilots to hand-fly for the same reason.

2. Write your hypothesis before you paste the alert

Two lines in the incident channel: what you think broke, and what would prove you wrong. Then ask the model. If it agrees, your model of the system holds up. If it disagrees, you get to find out which of you is wrong, and that's the part where you learn something.

3. Make the agent explain before it fixes

Claude Code has a built-in setting for this:

text

/output-style learning

Learning mode adds Insight blocks explaining its choices and leaves TODO(human) markers for the parts with real design decisions. /output-style explanatory gives you the explanations without the homework. (The Anthropic study authors point to these same two modes.) To make it the default across projects, set it in ~/.claude/settings.json:

json

{
  "outputStyle": "Explanatory"
}

The value is case-sensitive, per the docs. "explanatory" silently falls back to Default. Whatever tool you use, put a rule like this in your project instructions:

markdown

Before proposing any fix for a bug or incident:
1. State the root cause in one paragraph.
2. Name the evidence (log line, metric, trace) that supports it.
3. Say what would make this diagnosis wrong.
Do not edit files until I reply "go".

4. Write the postmortem yourself

No AI drafts. Rebuilding the timeline by hand forces you to understand why the system failed, and that's how the mental model gets built. Use the AI afterwards to check you didn't miss anything.

5. Read the tests on any AI rewrite

If you're on a Cisco-style refactor, that raizer88 comment is your checklist. If nobody has read the test suite, nobody knows what "done" means.

Rusty seniors, juniors who never learn

I don't think AI is coming for most developer jobs this year. What I see happening is slower than that and harder to spot. Juniors are losing the hands-on incidents where people used to build intuition, which the SigNoz piece calls "never-skilling." The seniors are getting rusty at the one part of the job the AI still can't do, which is noticing when the AI's answer is confidently wrong.

So be honest: could you still debug a production outage today without an AI assistant? When did you last try?