This is the first post in „Developing with AI Through the Cognitive Lens,” a series exploring how AI coding tools affect the way programmers learn, work, and build expertise. Drawing on cognitive psychology research—particularly Felienne Hermans' work in The Programmer’s Brain—this series examines what happens to our skills when we delegate cognitive work to AI. The goal isn’t to reject AI, but to use it deliberately, making conscious choices about when it helps and when it hinders.
Every AI coding tool promises the same thing: unprecedented speed, effortless productivity, freedom from tedious work. The pitch is compelling. But what if feeling more productive and being more capable aren’t the same thing? Research shows that automation makes us feel more productive while eroding our skills. Let’s examine this tension through the lens of cognitive psychology.
The promise of productivity
The marketing messages from AI coding tool providers are notably uniform. GitHub Copilot aims to make developers „10x more productive.” Claude Code claims to reduce tasks that usually take a developer 45 minutes to „a single pass.” The language across these pitches reveals a consistent framing: coding consists of tedious versus creative work. AI tools handle the routine, repetitive, and boring tasks, while developers have more time for higher-level thinking and the fun parts.
According to their marketing, these tools optimise for time-to-completion and code output volume, and as a bonus, reduced frustration by mechanical tasks.
Do the tools live up to their marketing claims? Maybe. The 2025 DORA State of AI-Assisted Development report shows a correlation between AI adoption and throughput: teams that have adopted AI tools report higher throughput than those who haven’t. While the report indicates a link between the two variables, we cannot treat it as evidence for a causal relationship. High-performing organisations may simply adopt AI faster than others. Also, the method used by DORA relies on surveys, i.e. self-reported data, not on observational studies.
How we learn
There is a problem with dismissing routine coding tasks as mere drudgery. Repeatedly writing that boring boilerplate code is precisely where learning happens. In The Programmer’s Brain, Felienne Hermans explains that one of the reasons why expert programmers succeed is because they have formed extensive schemata—organized knowledge structures—in long-term memory over the years.
These schemata allow experts to mentally automate writing common code patterns like loops, and to recognise patterns quickly when reading code. Pattern recognition, in turn, enables more efficient chunking, the ability to group related pieces of information into meaningful units when processing code. By chunking information more effectively, experts can hold more in working memory at once, reducing their cognitive load. This effect was first examined with expert and amateur chess players and has since been reproduced in many different contexts, including programming.
A recent eye-tracking study at UC Berkeley (as reported in the 2025 DORA State of AI-Assisted Development report) revealed something interesting about how developers actually use AI tools. Student developers readily used AI for mechanical tasks like writing boilerplate and installing packages, giving it nearly 19% of their visual attention. But when deeper understanding was needed—interpreting complex code, building mental models of system behaviour—they mostly ignored AI suggestions, devoting less than 1% of their attention to the tool.
If pattern recognition develops through repetition, shouldn’t students avoid AI even for mechanical tasks? Not necessarily. Depending on the context, deliberate use of AI for boilerplate tasks may have proven beneficial. The students in this study may have already developed enough foundational patterns that using AI for boilerplate didn’t interfere with their learning. Or they may have been optimising for task completion—finishing the assignment efficiently—rather than for long-term skill development. We don’t know whether their pattern of AI usage supported or hindered their learning over time. What we do know is that their instinct to avoid AI during interpretive work was sound.
The deeper insight is about cognitive load itself. There are two fundamentally different paths to reducing it. Hermans' approach is about building mental models through practice, learning syntax through spaced repetition, and recognising patterns through experience—reducing cognitive load by developing expertise.
The dominant approach marketed by AI tool providers is about offloading the boring work, reducing cognitive load through tool automation rather than developing cognitive automaticity, where practiced skills execute automatically without conscious effort. The UC Berkeley study shows why this distinction matters: AI tools can actually increase cognitive load during interpretive tasks, disrupting the very work where understanding develops.
The evidence across domains
But here’s the tension: if expertise develops through repetition and practice, what happens when we optimise for speed instead? The concern about AI tools eroding skills isn’t mere speculation. It has been documented across multiple professional domains.
Skill atrophy through automation
A study published in The Lancet examined the performance of doctors performing colonoscopies. It found that after three months of using AI assistance, physicians' diagnostic performance had declined significantly, by 20% from their baseline. The automation didn’t just create a dependency, it actively eroded their diagnostic abilities. The skills they had built through years of practice declined when the AI handled pattern recognition for them. This phenomenon is known as skill atrophy.
Research from Microsoft and Carnegie Mellon University showed similar degradation in analytical work. When participants used AI assistance for decision-making tasks, their critical thinking suffered. They became less likely to question outputs and showed reduced critical evaluation. Not only did the presence of AI assistance not help their judgement, it actually made it worse.
The 2025 DORA State of AI-Assisted Development report reveals this playing out at the team or organisational level. While AI adoption does improve software delivery throughput, this increase was accompanied by a decrease in delivery stability. As the report notes, „underlying systems have not yet evolved to safely manage AI-accelerated development.” The DORA findings mirror the central tension: speed versus skill.
The perception gap
What makes this skill atrophy dangerous is that individuals fail to notice it happening to themselves. A recent study by Model Evaluation & Threat Research (METR) found that developers using AI tools were 19% slower though participants were learning to use unfamiliar AI tools. More striking was the perception gap. These developers believed they were 20% faster than without those tools. So we see a 39 percentage point gap between perception and reality.
The Microsoft/CMU study shows the same pattern. Participants' decision quality suffered while they felt more confident in their conclusions. We feel faster, more productive, or more competent, even though objective measures show we are slower, less skilled, or making worse decisions.
The self-serving bias
This perception gap stems from well-documented cognitive biases first identified by [1]: Heider, 1958. What we see with AI tools is called the self-serving bias: We systematically attribute positive outcomes to our own abilities while attributing negative outcomes to external factors. A popular example: When winning at poker, we tend to attribute this to our great poker skill. When losing, it is almost certainly because of the cards we have been dealt.
This bias likely evolved because it serves useful psychological functions. It protects our self-esteem, maintains motivation after setbacks, and gives us a sense of control over outcomes. These tendencies may have been adaptive in our evolutionary past, but they become problematic when dealing with tools that create invisible skill degradation.
So when we generate working code fast using AI tools, we tend to credit our productivity and skill. When bugs appear, we blame the AI for giving us bad suggestions. This asymmetric attribution protects our ego but prevents us from recognising skill degradation. When we succeed, we see the tool as an augmentation of our self. We feel more competent and take credit for AI-assisted successes. On the other hand, we mentally distance ourselves from AI-assisted failures.
The pattern is consistent across medicine, software development, and decision-making. Automation tools create both skill atrophy and a perception gap that prevents us from noticing it. Our subjective experience can mislead us.
The bias blind spot
But it gets worse. Even if you know about the self-serving bias, this knowledge does not protect you from it. Psychologists call this the „bias blind spot”. While it’s relatively easy to recognise biases in others, we tend to remain blind to our own biases, even if we understand how they work.
This is why we need objective metrics. The 2025 DORA report found that developers reported positive impacts across all dimensions of the SPACE framework, i.e. satisfaction, performance, activity, communication, and efficiency. Objective metrics, however, showed delivery instability increasing. Remember, the METR study documented a 39 percentage point gap between perceived and actual performance. Often, our feelings of productivity or efficiency don’t align with reality.
You cannot rely on introspection alone, or on your gut feeling. You need external validation systems like cycle times, bug rates, incident frequency, or code review feedback patterns. Without objective measures, the self-serving bias will consistently tell you that everything is fine even if your capabilities quietly erode.
The expertise problem across the spectrum
The impact of AI-assisted development isn’t uniform. Its effect depends on the experience level of the respective developer.
Junior developers: Learning is hindered
For developers early in their careers, AI tools can prevent the formation of foundational schemata. If juniors consistently use AI for boring tasks they will miss the practice that builds expertise. They never develop the fluency that comes from writing loops, handling errors, and exploring APIs dozens of times. The patterns that should become automatic through repetition remain external, delegated to the tool. Without these patterns, they remain stuck with high cognitive load when reading code, whether their own, AI-generated, or written by others. They will probably never develop the reduced cognitive load that comes with expertise and relies on efficient chunking.
Mid-level developers: Arrested development
For developers with some experience, AI tools can strengthen the tendency to stay in one’s comfort zone. Why should you struggle through an unfamiliar framework when AI can generate the boilerplate? Why should you debug a problem when you can ask your AI tool to fix it?
This is the path of least resistance, and it prevents you from growing. Instead, mid-level developers should be stretching into unfamiliar territory, building breadth and depth across different domains. But AI makes it easier to remain in familiar territory, letting the tool handle anything beyond current expertise.
Senior developers: Expertise erosion
Matt Beane, Associate Professor at UC Santa Barbara has studied intelligent automation across 31 occupations. He documented a consistent pattern that now appears in the 2025 DORA report: „Experts can self-serve, so they do.”
When senior developers solve problems quickly with AI assistance rather than involving juniors, they create participation barriers for the next generation. It’s highly efficient in the short-term, but it disrupts the mentoring model that has traditionally transferred knowledge and brought the juniors' fresh perspectives to seniors.
Moreover, expertise requires maintenance. Procedural memory degrades without use. This does not only apply to experienced doctors, but also to senior developers.
Industry impact
The consequences compound across the profession. Beane observes in the 2025 DORA report:
Default use of intelligent automation changes traditional apprenticeship models.
Matt BeaneAssociate Professor at UC Santa Barbara
Juniors have a harder time getting valuable experience if seniors self-serve with AI. Mid-level developers plateau because AI removes the friction that forces growth. Seniors lose skills through disuse while blocking opportunities for juniors to learn. As Beane notes, „Few juniors manage to learn despite this participation barrier, but most struggle.”
The result is a missing generation of future senior developers and organisational fragility that increases over time. Knowledge transfer breaks down. Teams become dependent on a shrinking pool of experienced developers whose expertise is itself eroding.
The measurement problem
The evidence reveals that optimising for immediate productivity often undermines skill development or even skill retention. We need to recognise that there is a conflict between immediate efficiency gains and skill development.
Yet as Matt Beane notes in the 2025 DORA report, sustainable productivity requires organisations that don’t neglect skill development and continuous learning. The conflict isn’t between productivity and skill—it’s between short-term output (speed) and long-term capability (skill).
The problem is that we have a gap in what we measure. As Beane observes, „We track adoption rates, lines of code generated, pull requests merged. Not metrics indicative of skill development like linguistic or stylistic diversity over time.”
We can only optimise for what we measure. We measure sprint velocity, story points completed, or features shipped, so that’s what we optimise for. Skill development remains invisible in these measurements. A developer becoming more dependent on AI tools looks identical in sprint metrics to one building genuine expertise.
The 2025 DORA report supports this: teams gain throughput but lose stability. Instability is the cost when organisations optimise for speed without maintaining the skills that enable sustainable quality. Sustainable, long-term productivity comes from jointly optimising for both output and skill development.
Practical guidelines
Given the evidence of skill atrophy and the self-serving bias, how can developers and teams use AI tools responsibly?
Adapt practices to experience level
Different experience levels require different approaches to AI use.
- For junior developers: Default to manual work for learning. Use AI only for specific learning purposes like explanations or exploring alternative approaches. Recognise that you may not yet have the intuition for when AI helps versus hinders. Build pattern recognition through spaced repetition. Write loops dozens of times, handle errors in various contexts, explore APIs manually rather than having AI generate the exploration code.
- For mid-level developers: Deliberately practice outside your comfort zone. In familiar domains, you can use AI assistance while maintaining understanding. But you still need practice without AI regularly to maintain those skills. In areas where you’re building new skills, default to manual work to develop strong mental models. Make an explicit distinction between learning mode (building understanding through struggle) and shipping mode (optimising for speed with AI assistance where appropriate).
- For senior developers: Maintain expertise through regular manual practice. Involve juniors in problem-solving even when working alone would be faster. Mentor explicitly about when and how to use AI tools.
Make mode switching explicit
The UC Berkeley study showed that students intuitively distinguished between mechanical and interpretive work. Make this conscious in your own practice. Before starting a task, ask: „Am I optimising for speed or skill right now?”
In shipping mode, AI assistance is acceptable. In learning mode, work deliberately without AI. Sometimes, like a senior founder with limited resources and time-to-market has the top priority, shipping mode may dominate. As long as you understand that you are trading skill maintenance for present speed and make a conscious choice, this can be perfectly okay.
However, as founder Josh Anderson describes in detail, after three months of using Claude Code exclusively to build a product, he could no longer confidently modify his own code. Twenty-five years of experience couldn’t protect him from three months of complete delegation. He distinguishes between augmentation (where AI helps you work better while you maintain understanding) and abdication (where AI does the work and you lose ownership). Even conscious choices about trading skill for speed can slide from augmentation to abdication faster than expected.
Create AI-free zones
Students in a recent study by Schmidt et al. (2025) reported using AI when they wanted to „turn off their brain”—a concerning pattern if it becomes habitual. Designate regular practice time without AI. Identify certain task types that should always be manual to maintain core skills.
Counter attribution bias
Because the self-serving bias makes you credit successes to yourself while blaming AI for failures, you need explicit counter-measures. Force evaluation by asking, „Did I actually understand this code?” Practice pair review: find out if you can explain AI-generated code to a colleague. Do you notice any gaps in your understanding? Return to the code after a delay and see if you can still explain it. Measure comprehension, not just completion.
Practice deliberate tool use
You need to practice your judgement about when AI helps versus hinders. Like the Berkeley students who gave AI 19% attention during mechanical tasks but less than 1% during interpretive work, you need to recognise which cognitive mode a task requires. This is a skill that improves with practice, and with conscious reflection on when your choices served you well or poorly.
Organisational nudging
Individual developers can implement these guidelines, but organisational context determines whether they succeed. If everything is measured by sprint velocity, developers will optimise for speed over learning regardless of their intentions. Organisations must create both permission and incentive for the contemplative work that builds and maintains expertise.
Conclusion
The evidence is clear and consistent: automation creates both skill erosion and a perception gap that prevents us from noticing. The pattern holds across medicine, software development, and decision-making. We feel productive while capabilities quietly erode.
The self-serving bias compounds the problem. We credit AI-assisted successes to ourselves and blame failures on the tool. We need objective measures to reveal what’s actually happening to our skills.
Two paths lie ahead. Unconscious adoption delivers immediate throughput gains, but at the cost of stability and expertise. Conscious practice maintains and builds skills and enables sustainable productivity over time.
The developers who will thrive aren’t those who adopt AI fastest or go all-in. Instead, they are those who use AI consciously rather than automatically, who distinguish mechanical work from interpretive work, and who recognise that speed and skill aren’t in opposition when approached deliberately. They work in organisations that optimise for sustainable productivity and skill development.
References
-
Heider, F. (1958). The Psychology of Interpersonal Relations. New York: John Wiley & Sons. ↩