The Atrophy Risk: What Happens to Developers When AI Goes Dark

The Morning the Tools Went Silent

On June 23, 2026, more than eight thousand users filed Downdetector reports within hours of Anthropic’s Claude platform going offline.¹ It was the tenth significant disruption in fewer than three weeks for Anthropic’s services, which have been running below enterprise-grade availability benchmarks—Anthropic’s own status page records 90-day uptime of 99.12 percent for claude.ai and 99.28 percent for Claude Code, translating to nineteen to twenty-three hours of downtime per service per quarter against the industry-standard expectation of 99.9 percent or better.²

Anthropic acknowledged the pressure candidly. After an earlier wave of outages, the company told Fortune, “Demand for Claude has grown at an unprecedented rate, and our infrastructure has been stretched to meet it, particularly at peak hours.”³ The root cause on June 2 was particularly instructive: a bug in Claude Code’s sub-agent architecture caused parallel processes to multiply exponentially rather than complete their assigned work, generating an infinite loop that consumed platform capacity until the system buckled.⁴

Infrastructure failures are a known business risk, easily addressed with multi-provider routing, circuit breakers, and failover logic. What is harder to address is what those outages revealed about the humans on the other side of the connection. When the tools went dark, a pattern emerged that has nothing to do with uptime SLAs: engineers who had grown dependent on AI assistance found that their own unaided capability was no longer what it had been. The tools failed. So did the instinct to work without them.

That is the problem this article is about.

What the Research Actually Shows

The dependency question is not conjecture. It is now the subject of randomized controlled trials, longitudinal code analysis, and peer-reviewed cognitive science. The findings are consistent enough to constitute a pattern.

Signal Anthropic’s own researchers found that developers who fully delegated coding tasks to AI scored 17% lower on comprehension tests than those who coded manually—without a statistically significant productivity advantage in exchange.

In early 2026, Anthropic researchers Judy Hanwen Shen and Alex Tamkin published a randomized controlled trial examining how AI assistance affects skill formation in software developers.⁵ Fifty-two junior engineers were split into two groups: one used an AI assistant while learning a new asynchronous Python library; the other coded by hand. Both groups were then tested on debugging, code reading, code writing, and conceptual understanding.

The AI-assisted group scored 17 percent lower—roughly two letter grades—on comprehension assessments.⁶ The productivity advantage of AI use did not reach statistical significance. In other words, the AI group did not finish meaningfully faster, but they understood meaningfully less. The largest gap appeared in debugging—precisely the skill most needed to oversee AI-generated output. The researchers noted that this setup used a relatively constrained AI assistant and concluded: “we expect that the impacts of [fully agentic coding products] on skill development are likely to be more pronounced than the results here.”⁷

A parallel study from Carnegie Mellon and the University of Oxford, published in April 2026, extended the finding beyond coding.⁸ Across a series of randomized controlled trials with 1,222 participants, the authors provided causal evidence for two consequences of AI assistance: reduced persistence and impaired unassisted performance. These effects appeared after as little as ten to fifteen minutes of AI interaction. The mechanism they proposed is direct: AI conditions people to expect immediate answers, which degrades the tolerance for productive struggle that is foundational to skill acquisition. The paper’s framing is striking—they describe current AI systems as “fundamentally short-sighted collaborators: optimized for providing instant and complete responses, without ever saying no.”⁹

The METR organization contributed a third data point with a large-scale RCT conducted between February and June 2025 with experienced open-source developers—people with an average of five years on their own codebases.¹⁰ When AI tools were allowed, those developers took 19 percent longer to complete tasks. The same developers, asked before the study how much AI would speed them up, predicted a 24 percent gain. After experiencing the slowdown firsthand, they still believed AI had made them 20 percent faster. That 39-percentage-point gap between perception and reality should give pause to any leader relying on developer self-report to measure AI program effectiveness.¹¹

The Cognitive Mechanics of Drift

The phenomenon has a name in the research literature: cognitive offloading. It is the practice of delegating mental work to an external system—notes, calculators, GPS navigation, search engines—to reduce cognitive load. Cognitive offloading is not inherently harmful; it is how humans have extended capability throughout history. The problem arises when offloading becomes habitual and the cognitive aid is withdrawn.

A 2025 study by Michael Gerlich with 666 participants found a significant negative relationship between frequent AI use and critical thinking capability, with cognitive offloading as the mediating factor.¹² The ScienceDirect review of AI-overdependence research published in May 2026 described the progression as a cascade: automation bias (over-trusting AI output) leads to uncritical acceptance, which over time becomes habitual offloading, which progresses to what researchers call AI-overreliance, and ultimately deskilling—the measurable erosion of independent capability.¹³

The aviation parallel is instructive and has been documented since the 1990s. Researchers Linda Skitka, Kathleen Mosier, and Mark Burdick first defined “automation bias” studying pilot behavior in glass-cockpit aircraft: pilots would follow automated system recommendations even when other instruments indicated a different course of action.¹⁴ Subsequent research found that prolonged autopilot reliance degraded manual flying proficiency in ways that only became visible during emergency scenarios requiring manual control.¹⁵ The failure mode was not that the automation was wrong. It was that the human had lost the capacity to catch it when it was.

Software development is not aviation, but the structural dynamic is identical. A developer who has spent six months delegating debugging to an AI agent has not practiced debugging. When the agent produces faulty output—or goes offline—the cognitive muscle required to identify the fault has weakened. The 2025 MDPI study on cognitive atrophy in AI-human interaction described this as “delegation drift”: a slow reallocation of cognitive responsibility from comprehension and synthesis to prompting and verification, with four specific symptoms: automation bias (trusting AI output over personal reasoning), comprehension erosion (relying on summaries over underlying principles), motivational narrowing (reduced intellectual curiosity when effort is consistently mediated by AI), and skill atrophy itself.¹⁶

The core risk Skill atrophy in development is not a career concern for individuals. It is an operational risk for teams—because the same developers who can no longer debug independently are the ones responsible for validating AI-generated code when the AI is wrong.

What Is Happening to the Code

Developer cognition is not the only thing changing. The code itself is changing in ways that create compounding risk.

GitClear’s 2025 AI Copilot Code Quality report analyzed 211 million lines of code changes from repositories owned by major enterprises including Google, Microsoft, and Meta, tracking metrics from 2020 through 2024.¹⁷ Three patterns emerged as AI coding assistance surged:

Refactoring—the discipline of revisiting working code to improve its structure, reduce coupling, and eliminate redundancy—collapsed from 25 percent of changed lines in 2021 to under 10 percent by 2024. Code duplication increased from 8.3 percent of changed lines in 2021 to 12.3 percent by 2024, with a spike to 4x more code cloning and, in some analyses, an eightfold increase in duplicated blocks compared to the pre-AI baseline. Short-term churn—code revised or discarded within two weeks of initial commit—rose from 3.1 percent in 2020 to 5.7 percent in 2024, suggesting that AI-generated code is frequently wrong enough to require rapid correction but accepted into the codebase before that wrongness is caught.¹⁸

The refactoring decline is particularly important for this discussion. Refactoring requires understanding what the code is doing, why it is structured the way it is, and what a better structure would accomplish. AI tools can generate new code efficiently. They cannot reliably perform the architectural reasoning that refactoring demands. When developers stop refactoring—because the AI is filling the productivity metrics and there is no apparent pressure to clean up—they also stop exercising the deep comprehension that refactoring requires. The skill does not just decline; the practice that would sustain it disappears.

A separate analysis by CodeRabbit found that AI-generated code exhibits 2.74 times more security vulnerabilities than human-written code.¹⁹ Stack Overflow’s 2025 Developer Survey—drawing on responses from more than 49,000 developers across 177 countries—found that 46 percent of developers actively distrust AI tool output, that 66 percent cite “almost right but not quite” as their dominant frustration, and that 45 percent report debugging AI-generated code is more time-consuming than writing it themselves.²⁰ Notably, experienced developers registered the lowest trust: only 2.6 percent of senior engineers said they “highly trust” AI output, and 20 percent said they “highly distrust” it.²¹

These numbers suggest that senior engineers have not lost their judgment. They have maintained enough independent capability to recognize when the AI is wrong. The concern is what happens to the cohort coming behind them.

The Counterargument Is Real—and Limited

It would be intellectually dishonest to present the skill atrophy case without acknowledging the counterarguments. They are legitimate.

The 2025 Stack Overflow survey found that 69 percent of developers who use AI agents report increased personal productivity.²² DX’s Q4 2025 AI-Assisted Engineering Impact Report, tracking 435 companies and 85,350 developers, found that daily AI users merged 2.3 pull requests per week versus 1.4 for non-users—a 60 percent throughput advantage.²³ JetBrains’ AI Pulse data found roughly 89 percent of developers saving at least one hour per week, with 20 percent saving eight or more hours.²⁴

The METR team itself updated its findings in February 2026 to note that AI tools available in early 2026 were likely producing speedups that their 2025 data could not fully capture, partly because the most AI-dependent developers had declined to participate in studies that required them to work without AI.²⁵ That selection effect is itself telling, but it does mean the productivity story is not static.

The University of Maribor study, published in Applied Sciences, demonstrated that LLM use for explanations—asking the AI to clarify concepts rather than to generate code—showed no significant negative impact on learning outcomes and in some cases improved them.²⁶ A separate 12-week study with 240 university students found that deliberately reserving higher-order cognitive tasks (analysis, evaluation, reflection) for human engagement while offloading lower-order tasks to AI produced significant critical thinking gains.²⁷

The evidence for AI’s productivity value is real. The evidence for skill atrophy is also real. They are not in contradiction. They describe different things: AI improves throughput on tasks the developer already understands; it impairs the acquisition and maintenance of skills the developer has not yet mastered or has stopped exercising. Managing AI in a development organization requires distinguishing between these two dynamics.

The Vendors Remain Silent

The AI coding tool vendors have read the same research. Their product responses are instructive precisely because of what they reveal about the problem’s severity—and what they leave unresolved.

Anthropic, OpenAI, and others have introduced learning-oriented interaction modes: Claude Code’s Learning and Explanatory mode, ChatGPT’s Study Mode, and similar features designed to scaffold understanding rather than generate solutions outright.²⁸ These modes exist because the vendors’ own researchers documented the skill formation problem. Anthropic published the RCT finding that AI delegation produced 17 percent lower comprehension scores, then noted in the same paper that fully agentic products like Claude Code would likely produce more pronounced effects. The company’s researchers called for “a more expansive view of the impacts of AI on workers” that accounts for long-term expertise sustainability, not just near-term throughput.²⁹

The structural tension Vendors profit from usage volume. Learning modes reduce usage volume. That every major vendor has released a learning mode anyway reflects the seriousness of the skill formation evidence—but those modes are not the default, and they are rarely the ones enterprise teams deploy at scale.

None of the major platforms—GitHub Copilot, Cursor, Amazon Q Developer, Tabnine, or others—has made skill-protective configuration the default deployment posture. Learning modes require explicit opt-in, at the individual or organizational level. Maximum completion mode is what ships out of the box, because it produces the throughput metrics that close procurement conversations. The JetBrains January 2026 survey found awareness of GitHub Copilot at 76 percent and usage at 68 percent, with Claude Code and Cursor each at 18 percent among specialized AI IDE users—a market in which every platform competes on speed and suggestion quality, not on how well developers learn from the interaction.³⁰

The reliability record compounds the concern. Every major AI coding platform has experienced significant service disruptions in 2026. GitHub’s own blog noted nine service degradation incidents in May 2026.³¹ Anthropic logged ten significant outages in fewer than three weeks in June. Thoughtworks observed after one of those incidents that single-vendor dependency on any AI coding provider “is a single point of failure that’s a very real threat to business continuity.”³² That observation applies equally to Anthropic, GitHub, Amazon, and every other provider in the space.

The market has not solved the skill atrophy problem. It has identified it, offered opt-in mitigations, and continued optimizing for the metrics that drive growth. The responsibility for acting on the research falls to the organizations deploying these tools—not to the vendors selling them.

A Sustainable AI Development Practice

The goal is not to restrict AI use. The goal is to structure it so that the humans who use it do not become dependent on it in ways that create hidden operational risk. The following six disciplines apply at the individual, team, and organizational level.

1. Differentiate between delegation and augmentation—and enforce the boundary. AI assistance that replaces reasoning is delegation. AI assistance that extends reasoning is augmentation. A developer who uses AI to generate a function she does not understand has delegated. A developer who uses AI to explore the trade-offs between two approaches she has already thought through has augmented. The organizational question is whether the workflow design makes this distinction visible. It rarely does.

2. Mandate AI-off intervals with structured accountability. Deliberate practice requires working without the aid. High-performing organizations allocate 4–6 hours per engineer per sprint for deliberate skill work.³³ For development teams, this means periodic sprints, code review sessions, or individual assignments where AI tools are explicitly disallowed—and where the output is reviewed for the same quality standards applied to AI-assisted work. The purpose is not punishment; it is calibration. Teams need to know what their unaided capability actually is.

3. Use AI for inquiry before generation. The research is consistent: using AI to ask questions and build conceptual understanding does not impair learning, and may support it.³⁴ Using AI to generate code before understanding what the code needs to do does impair it. The discipline is sequence: problem framing, architecture reasoning, and design decisions happen before AI engagement; AI engagement happens within a frame the developer already owns.

4. Require human-written debugging, review, and refactoring on AI-generated output. GitClear’s data shows that refactoring has collapsed.³⁵ Reverting this requires making it a workflow requirement, not a discretionary practice. Every pull request that includes substantial AI-generated code should require a human-authored explanation of what the code does, why it is structured as it is, and what the reviewer looked for. This is not about process overhead. It is about ensuring that the engineer responsible for the code can actually read it.

5. Measure skill, not just throughput. Development velocity and pull request volume measure AI-assisted output. They do not measure whether engineers can function without AI. Organizations that have no way to answer the question “what would our team’s velocity look like if AI tools were unavailable for forty-eight hours?” are operating with an unmeasured dependency. Internal technical assessments, code review quality audits, and incident response drills that restrict AI access provide the signal that throughput metrics cannot.

6. Configure AI tools to scaffold learning, not shortcut it. Major platforms have released learning-oriented interaction modes specifically because the skill formation evidence demanded it. Those modes are not the default. For teams with junior developers or engineers learning new stacks, deploying AI in explanatory or inquiry mode—rather than maximum completion mode—is a configuration decision with measurable long-term consequences on team capability. It requires someone with organizational authority to make it explicitly, because the default setting optimizes for the vendor’s growth metrics, not the developer’s.

The Competence You Defer Is the Competence You Lose

Every senior engineer reading this knows the experience of working through a problem the hard way—no Stack Overflow, no AI, no colleague available, just the problem and the code and the necessity of reasoning it through. That experience is not pleasant. It is the mechanism by which skill is built and maintained. It is what creates the intuition that catches errors before they reach production, the architectural judgment that AI tools cannot replicate, and the debugging instinct that functions when the tools do not.

The research on AI assistance and skill formation is not an argument against AI tools. It is an argument for using them with intention. The developer who uses AI to move faster on problems she already understands is using a productivity tool appropriately. The developer who uses AI to avoid encountering problems she does not yet understand is using a productivity tool to defer a cost that will eventually be paid—with interest, and possibly at the worst possible moment.

Anthropic’s own researchers concluded their skill formation study with a line that deserves to be posted in every engineering manager’s office: “AI-enhanced productivity is not a shortcut to competence.”³⁶ The tools are powerful. The humans using them still need to be.

References

1. “Claude Outage Tops 8,000 Reports,” TechTimes, June 23, 2026.
2. “Claude Outage Tops 8,000 Reports,” TechTimes, June 23, 2026; Anthropic status page data cited therein.
3. “Claude Outage: Tenth Disruption in 12 Days,” TechTimes, June 16, 2026.
4. “Is Claude Down? 2026 Anthropic Outage and Expert Failover Tips,” Deployflow, June 2026.
5. Judy Hanwen Shen and Alex Tamkin, “How AI Impacts Skill Formation,” arXiv:2601.20245, February 3, 2026.
6. Shen and Tamkin, “How AI Impacts Skill Formation,” 2026; see also “Anthropic Study: AI Coding Assistance Reduces Developer Skill Mastery by 17%,” InfoQ, February 23, 2026.
7. Shen and Tamkin, “How AI Impacts Skill Formation,” 2026.
8. Grace Liu, Brian Christian, Tsvetomira Dumbalska, Michiel A. Bakker, and Rachit Dubey, “AI Assistance Reduces Persistence and Hurts Independent Performance,” arXiv:2604.04721, April 6, 2026.
9. Liu et al., “AI Assistance Reduces Persistence,” 2026.
10. Joel Becker, Nate Rush, Beth Barnes, and David Rein, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” METR, arXiv:2507.09089, July 2025.
11. Becker et al., “Measuring the Impact,” METR, 2025; see also “The AI Productivity Paradox: Why Developers Are 19% Slower,” DEV Community, December 2025.
12. Michael Gerlich, “AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking,” 2025; cited in “AI Empathy Erodes Cognitive Autonomy in Younger Users,” arXiv:2603.29886.
13. “AI-Overdependence and Human Cognitive Decline: Hazards, Evidence, and Mitigation Strategies,” ScienceDirect, May 12, 2026.
14. Kathleen L. Mosier, Linda J. Skitka, S. Heers, and M. Burdick, “Automation Bias: Decision Making and Performance in High-Tech Cockpits,” 1997; cited in ResearchGate and “Automation Bias,” Wikipedia, updated January 2026.
15. “What Is Automation Bias and How Does It Affect Compliance?” Regulance, September 2025.
16. “Cognitive Atrophy Paradox of AI–Human Interaction: From Cognitive Growth and Atrophy to Balance,” MDPI Information, 16, no. 11, November 19, 2025.
17. “AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones,” GitClear, 2025.
18. “Report Summary: GitClear AI Code Quality Research 2025,” Jonas.rs, February 2025; “The Evidence Against Vibe Coding,” SoftwareSeni, January 2026.
19. “AI Code Quality in 2026: Guardrails for AI-Generated Code,” TFIR, February 20, 2026.
20. Stack Overflow, “2025 Developer Survey,” published July 29, 2025.
21. “Mind the Gap: Closing the AI Trust Gap for Developers,” Stack Overflow Blog, February 18, 2026.
22. Stack Overflow, “2025 Developer Survey,” 2025.
23. “AI Coding Adoption 2026: 50 Statistics from 7 Surveys,” DigitalApplied, May 2026; citing DX Q4 2025 AI-Assisted Engineering Impact Report.
24. “AI Coding Adoption 2026,” DigitalApplied, May 2026; citing JetBrains AI Pulse.
25. METR, “We Are Changing Our Developer Productivity Experiment Design,” February 24, 2026.
26. Jošt, Taneski, and Karakatič, University of Maribor, study cited in “Anthropic Study: AI Coding Assistance Reduces Developer Skill Mastery by 17%,” InfoQ, February 23, 2026.
27. “Cognitive Offloading to AI: The Peril and the Promise,” Sendfull/Substack, March 26, 2026.
28. Shen and Tamkin, “How AI Impacts Skill Formation,” arXiv:2601.20245, 2026; Anthropic, “How AI Assistance Impacts the Formation of Coding Skills,” anthropic.com.
29. Shen and Tamkin, “How AI Impacts Skill Formation,” 2026.
30. “AI Coding Adoption 2026: 50 Statistics from 7 Surveys,” DigitalApplied, May 2026; citing JetBrains January 2026 AI survey.
31. GitHub Blog, “GitHub Copilot App: The Agent-Native Desktop Experience,” June 2026.
32. “Claude Outage: Tenth Disruption in 12 Days,” TechTimes, June 16, 2026; citing Thoughtworks commentary.
33. “Developer Skills and AI Development Resources for 2025,” Propel, September 2025.
34. Jošt et al., University of Maribor, 2024; cited in InfoQ, February 2026; and “Cognitive Offloading to AI,” Sendfull, March 2026.
35. GitClear, “AI Copilot Code Quality,” 2025.
36. Shen and Tamkin, “How AI Impacts Skill Formation,” 2026; as quoted in “Not a Shortcut to Competence,” IT Pro, February 3, 2026.