The Dark Side of AI Agents – Skill Atrophy, Cognitive Debt, and the Way Back to Control

I have spent many posts in this series describing how well all of this works: why I left vibe coding behind for complex projects (post 11), how planning and implementation agents work together (post 12, post 13), how a test agent closes the loop (post 14), and how I even tried in the end to measure the positive effect (post 18).

This post is the honest counterweight.

Because as convinced as I am of the workflow – there is a flip side I don't want to gloss over. One that is being fiercely debated in the tech community right now, triggered in part by the viral essay „Agentic Coding is a Trap" by Lars Faye, which has formed a veritable "agentic backlash." The core thesis is uncomfortable: the productivity gains from autonomous agents could end up eating themselves – because reviewing and debugging AI code is ultimately more expensive than writing it by hand. More expensive cognitively, more expensive emotionally, more expensive financially.

Two things up front, so the frame is clear:

First: AI isn't going away. This is not a plea against using agents – I use them daily and will keep doing so. It is a plea to keep the risks consciously in view and to think about countermeasures.

Second: much of this could be a temporary problem. The models keep improving – no longer at the pace of a few years ago, but they do. And the tools and agents around them are improving even faster. It is entirely possible that in two years we won't need some of these workarounds at all. But today, at this moment in time, the risk is real. And that is precisely what this is about.

Chapter 1: The Creeping Loss of Competence

The most ironic argument in the whole debate is a chicken-and-egg problem for which Anthropic coined the term "paradox of supervision" in its report „How AI is transforming work at Anthropic". Put bluntly:

Effectively working with Claude requires supervision – and supervising Claude requires exactly the coding skills that can atrophy from overusing AI.

It's worth looking at this loop calmly, because it is so inconspicuous:

To meaningfully review an agent's changes – often spread across thousands of lines – you need the skills of an experienced developer. But if all you do is "pull the lever" and review, you unlearn exactly those skills. A randomized study by Anthropic – „How AI assistance impacts the formation of coding skills" – suggests as much: 52 junior developers were asked to learn a new Python library, once with and once without AI assistance. The group with AI scored markedly worse on the subsequent comprehension test, at 50 %, than the hand-coding group at 67 % – and the biggest gap showed up, of all places, in debugging. Tellingly: those who used the AI for conceptual inquiry scored 65 % and above; those who delegated the raw code generation fell below 40 %.

Junior developers are hit especially hard. Reviewing code is important – but it is, at best, half of the learning process. The other half is the friction: wrestling with the problem, running into dead ends, debugging it yourself. Anyone who only "vibe-checks" generated code from the start never builds the foundation on which good judgment can later grow in the first place.

And – this is the uncomfortable part – seniors aren't immune either. Simon Willison, a developer with nearly 30 years of experience and an outspoken AI enthusiast, reports no longer having a "firm mental model" of his AI-assisted applications, which makes "each additional feature harder to reason about."

"It's different this time"

The usual rebuttal goes: this is nothing new. Programmers have always been skeptical of new abstractions – with FORTRAN, with compilers, with the move from C++ to Java. And a senior who moves into management and gets "rusty" was never a drama either.

The difference: a C++ developer who switched to Python didn't complain about "brain fog." A sysadmin who migrated to AWS didn't lose their understanding of networking. And the rusty senior had previously accumulated decades of friction and experience – a foundation to stand on when their job became more architectural.

What is happening right now is the opposite: developers who have never gone through those decades are lifted straight into the orchestrator role – which demands exactly the skills the senior built up over 30 years. We are skipping the part that produces the competence in the first place.

Chapter 2: Technical Debt vs. Cognitive Debt

In his article „How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt", Simon Willison coined a distinction I consider the most helpful in the entire debate:

Technical debt is a well-known phenomenon. Cognitive debt is the genuinely new thing: the agent produces working code, but the human loses the mental model of the codebase. As long as everything runs, it goes unnoticed. It only surfaces when a critical bug hits production at three in the morning – and nobody understands anymore why the AI built the system this way and not another.

This connects to something Dax (Dax Raad), the creator of the open-source agent OpenCode, said in an interview about Spec Driven Development – and which I sign off on from my own experience:

"When I'm working on something new or something challenging, me typing out code is the process by which I figure out what we should even be doing."

For some of us, writing code isn't mindless drudgery – it's thinking. It forces you to grapple with things at a technical level: security, performance, maintainability, edge cases. Anyone who fully delegates this step to an agent doesn't just save themselves the typing. They also save themselves the thinking – and with it, the understanding.

Chapter 3: Spaghetti in a Tailored Suit

Here comes the problem that is most underestimated in practice, because it looks so harmless. AI-generated code often looks perfect: clean syntax, coherent naming, passes the first unit tests. Addy Osmani calls this the „80% Problem" in his analysis: the AI quickly gets you to 80 % – and the remaining 20 %, where the actual complexity lives, costs disproportionately much.

Others have coined the image "spaghetti code in a tailored suit." The look deceives you about the substance. And the numbers behind it are sobering. An analysis by Stack Overflow as well as a report by CodeRabbit (470 analyzed open-source pull requests) show clear patterns since agents went mainstream:

• More bugs overall: AI code produced roughly 1.7× as many defects as human code – and 1.3× to 1.7× more critical or major issues.
• Security flaws are introduced by AI code at a 1.5× to 2× rate – improper password handling, insecure object references.
• Performance problems from excessive and expensive I/O operations occurred up to 8× more often.
• Uncontrolled dependencies: agents readily install new libraries without checking licenses or known vulnerabilities – and made concurrency and dependency mistakes twice as often.

On top of this comes assumption propagation: if the agent misunderstands a requirement right at the start, it builds a huge, internally consistent mountain of features on top of that false premise. Consistently wrong is harder to spot than obviously broken – and the further down the stack the false assumption sits, the more expensive it gets.

This is exactly the problem I tackled in detail in post 12: instead of letting the AI analyze, plan, and code all at once, I put a specialized business-analyst agent in front of it that first translates vague requirements into precise use cases – with a human-in-the-loop checkpoint at the concept level, before a single line of code exists. A misunderstood requirement costs one minute to correct there; the same false assumption in finished code costs hours. It's the old engineering principle that a defect caught in the requirements phase is orders of magnitude cheaper than in implementation.

But here too, this matters to me: it's a workaround, not a law of nature. I build this structure around it because today's model still fills ambiguity with assumptions (or hallucinations) instead of pausing at the right spot and asking back on its own. If the agents reliably asked their own clarifying questions, this kind of upfront checkpoint wouldn't be needed in this form anymore. Until then, I'd rather catch the false assumption early than surgically remove it from a thousand lines later.

The Human as the Bottleneck

This is exactly where – with the human as the bottleneck – a dangerous loop closes with the marketing. The promise from OpenAI and Anthropic roughly goes: every developer becomes a 10x or even 100x developer. Boris Cherny, the person behind Claude Code, put it even more pointedly in an interview: "Coding is largely solved" – programming is a solved problem, he says, because Claude can do it. He himself hasn't hand-edited a single line since November 2025 and ships dozens of fully Claude-written pull requests every day.

This message is powerful – and that's precisely where its danger lies. Because it suggests you can rely on the generated code being correct. Cherny does add an important qualifier ("at least for the kind of programming that I do"), but it gets lost in the catchy slogan. What sticks is the headline: coding is done. Agents already tend to write a lot of code – and when the expectation then is that the result is correct anyway and you just need to become many times faster, the human comes under pressure to look less carefully.

Because to understand and review everything properly, we would be the bottleneck. The honest review process simply doesn't scale with generation speed. The consequence is predictable: according to the State of Code Developer Survey 2026 by Sonar, only 48 % of developers always review AI-generated code before committing it – even though 38 % admit that reviewing AI logic is more strenuous than reviewing human code. At the same time, 96 % don't fully trust the AI code, while it already makes up 42 % of committed code: a classic verification bottleneck.

Chapter 4: When the Credit Card Glows

The last and at the same time most sober block of risk: money. The cost of a human developer is fixed and known – salary, IDE license. Token costs are a moving target.

An agent that gets caught in an infinite loop – because it's searching for a file that doesn't exist, or trying to circumvent a linter rule – can make the token costs of a sprint explode from 200 to 2,000 € in a few days. You know what your employees cost; you don't know what your tokens will cost next month.

On top of that comes a pattern familiar to anyone who has lived through a few model releases: high benchmarks, hype, then reality – and shortly after, the complaints that the model has been "nerfed" and now burns 2× to 3× as many tokens for the same task. The models stand on shifting ground.

And there is a second, subtler cost side: vendor lock-in. During the major Claude outage in June 2026 – affecting Claude.ai, the API, and Claude Code – entire engineering teams came to a standstill: their workflows, in part their own skills, were already so dependent on a single vendor that a task once solvable with a keyboard and text editor suddenly required a subscription to a model provider. What was once your own skill thus turns into a service you rent monthly – one whose availability, price, and quality you no longer control yourself.

At the organizational level, this reaches all the way into the balance sheet: Gartner predicts that by the end of 2027 over 40 % of agentic AI initiatives will be canceled – due to escalating costs, unclear business value, or inadequate risk controls, because they fail to make the leap from prototype to reliable, scalable production.

The Other Side: Maybe Agentic Coding Isn't the Trap

So much for the prosecution. For a balanced picture, the rebuttal belongs here too – and it is strong.

The most prominent counter – the article „Agentic Coding isn't the trap – supervising from your head is" – goes: agentic working isn't the trap – supervising inside your own head is. Anyone who tries to validate AI code purely by reading over it loses – that's review fatigue by design. The solution is not less AI, but better guardrails: policy as code, strict compiler types, incorruptible linters, automated runtime hooks, a hard CI pipeline. Or, as the article puts it: "the compiler does not get tired at 4pm." The CI server becomes the agent's "conscience" – a deterministic system catches what a tired human glance overlooks.

The decisive trick: the checks belong inside the agent loop, not behind the pull request. If the code fails the compiler, linter, or test, the agent corrects itself in a closed loop – and the human ends up reviewing checked, working code instead of raw output (Guardrails for Agentic Coding, 2026). And this isn't just gut feeling – research backs it: the ArXiv paper „ClayBuddy" (2026) systematically categorizes typical agent failures and argues for building guardrails directly into the agent harness rather than monitoring for failures after the fact.

These guardrails are not an abstract ideal for me – they match precisely the workflow I've described throughout this series. That is exactly the difference between "I'll keep an eye on it" and control that holds even when I'm tired. How I concretely put them in place in my projects, I'll come to further down in the section "My Approach".

The second counterargument is the one about a new abstraction layer – most prominently framed by Andrej Karpathy as „Software 3.0", in which natural language becomes the programming interface ("the hottest new programming language is English"): people once wrote assembly; today we leave machine code to the compiler – and no one mourns. The developer of the future, the argument goes, no longer writes lines but precise specifications and architecture. The real work, so the argument, was never the typing anyway, but understanding architecture, dependencies, and business logic.

This argument has a weakness worth knowing about – one Lars Faye points out pointedly in his essay: a compiler is deterministic. The same input yields the same output, every time. An LLM is a probabilistic next-token predictor. More ambiguity is not the same as a higher level of abstraction. You can write the most perfect, unambiguous prompt – and the model still hallucinates a method, because it is, fundamentally, not a compiler: it doesn't know whether a method exists, it merely estimates that one should exist at that spot. And this is exactly where the loop closes: because the core is probabilistic, the outer shell – CI, compiler, types, tests – has to be all the more deterministic. With the right guardrails around it, the probabilistic core can be tamed.

Why It May Only Be a Temporary Problem

For all the justified concern, I think it's important not to think of this statically. Today's risk landscape is a snapshot – and almost all the factors are moving.

The models are becoming more reliable, even if the leaps have gotten smaller. Above all, though, the tooling layer around them is improving rapidly: agents are gaining better built-in self-correction, tools are integrating policy-as-code and automatic verification out of the box, cost controls and token budgets are becoming standard. Much of what we laboriously assemble as workarounds today – hard CI gates, review discipline, manual cost caps – could simply be part of the tool in two years.

It is entirely possible that the skill-atrophy debate will look, in hindsight, just like the fear of the compiler: a real concern during a transitional phase that eased once the technology matured. The emphasis is on could and transitional phase. Today we are in the middle of that phase – and that is precisely why it pays to consciously counter-steer now, instead of betting that the problem will resolve itself.

My Approach: Control Through Structure, Not Hand-Coding

And here I have to clearly distinguish my own path from a widespread piece of advice. The obvious reaction to all these risks is: generate less, type more yourself again, demote the AI to a secondary tool. That's a legitimate path – but it is explicitly not mine.

I delegate the implementation largely to agents. Depending on the task, I often write only between 10 and 20 % myself by hand. In the context of this post that sounds contradictory at first – but it isn't. Because my answer to the risks is not less AI, but more structure. That is the common thread of my entire series: it isn't delegation that's the problem, but unstructured delegation.

How I stay in control without writing the code myself:

• I don't review a thousand lines of code, I review decisions. My human-in-the-loop checkpoints sit at the concept level, not the code level (post 12): I review the use case, the solution concept, and the implementation plan – before a single line exists. Correcting a false assumption there costs a minute; in finished code it costs hours.
• I break the work into tiny, validated steps. The developer agent doesn't get the whole plan, but one step (post 13). After each step: look at the change, build and typecheck green, continue. The review bite stays small enough to actually understand – not because I generate less, but because I portion it.
• I rely on deterministic guardrails instead of my own glance. Project rules in copilot-instructions.md/AGENTS.md (post 10), types, linters, build – and a dedicated E2E test agent that translates every use case into an executable test (post 14). The conscience lies in the pipeline, not in my daily form.
• I measure instead of believe. Whether the setup is really better than a direct prompt, I answer not with gut feeling but with metrics (post 18).

The decisive point is the level at which I stay human. Not at the typing – that I largely leave to the agents. But at the understanding and deciding: what should be built, in what architecture, in what order – and does the result in the end match the original requirement? In post 15 I showed, in a concrete run, that I intervened at four of five checkpoints – each intervention took two to ten minutes. It was never about finding technical bugs, but about holding direction while corrections still cost nothing.

And yes – vibe coding, i.e. generating without this structure, I deliberately left behind for complex projects (post 11). Not because agents are bad, but because unstructured delegation runs straight into the quality traps this post describes: nicely wrapped bugs, security flaws, assumption propagation. Against those, the checkpoints and guardrails help reliably.

The honest limit: none of this helps against atrophy

But here I have to draw a clean distinction, otherwise I'm selling you a fallacy. All four points above secure the quality of the generated code – that the right thing gets built, that it works, that it fits the architecture. Against the loss of your own skills, they do nothing. On the contrary: whoever delegates the implementation and reviews only at the concept level inevitably writes less themselves – and it is precisely that writing-it-yourself that keeps the skill alive. My workflow keeps me in the process at the right points – but it does not automatically keep my coding muscles trained. To hold off the atrophy, I have to deliberately work through tasks myself that I could also solve without agents – take the painful route and now and then write, debug, and optimize by hand. There are recurring moments where I implement a feature by hand on purpose, just to keep my own skills alive. It's a conscious trade-off between speed and competence.

This atrophy, in itself, is nothing new. It is the normal course of a career: anyone who grows from developer to architect and on into management writes less code over time and gets rusty on the syntax. That was always the case – and never a drama, because those people had previously accumulated years of friction and experience to build on.

What's new – and what worries me – are two things. First, the speed: what used to happen slowly over years now happens in months. Even experienced developers, architects, and I myself unlearn parts faster than the natural arc of a career ever demanded. Second, and more serious, the juniors: a senior who gets rusty already has their foundation. A junior who, from the very start, only reviews instead of wrestling with it themselves never builds that foundation. You can't lose a skill you never acquired – but you can prevent it from forming in the first place. And this is exactly where the paradox of supervision from chapter 1 becomes a complete dead end for juniors: effective supervision of the AI demands precisely the skills a junior was never allowed to build. How is someone supposed to judge whether the generated code is correct when they lack the experience that makes that judgment possible in the first place? With a senior, a skill that once existed atrophies – with a junior, the very basis for supervision is missing from the start.

I don't have a clean solution for this – certainly not one an agent workflow could deliver. For the next generation it means above all: not letting juniors merely nod code through, but letting them go through the same friction I needed in order to learn. That isn't a technical guardrail. It's a conscious decision against convenience.

Conclusion

Let's be honest: I am faster with agents – and the quality that comes out of it is acceptably good. That's not a nice side effect; it's the very reason I go this way. But I go it consciously, with open eyes for the risks I've described in this post.

And I feel them myself. It is genuinely uncomfortable when I deliberately decide to write a feature completely by hand – and that small discomfort is, for me, an honest indicator that convenience is already working on me. I try to counter the cognitive debt through the documentation of use cases and solution concepts: they keep my mental model awake at the level of the what and the why. But I don't want to gloss over it – it only helps to a limited extent. I often don't look into the technical depth, and accordingly, for some features I couldn't tell you off the top of my head how exactly they work.

For me, the positive aspects still clearly outweigh the rest – and I'm optimistic that much of what worries us today will shrink over time.

Maybe all of this will be a solved problem in two years, because the tools have caught up. Maybe not. Until then, what fits best for me is what Jeremy Howard (founder of fast.ai) and Chris Lattner describe in „Build to Last": a fork in the road. Those who use AI the wrong way will get "worse and worse"; those who use it the right way will outpace the normal speed of their own growth. Or, in Lattner's words: delegating knowledge to an AI "and just reviewing the code without thinking about what you want to achieve" is "very, very concerning."

On exactly that fork, I try to stay on the right side: to be fast without ceasing to understand. The tools are meant to make me better – not redundant. The difference is not decided by the model. I decide it.