DEV Community

Cover image for The Real Problem With AI for Developers Is Not Capability, It's Overload
Max Mendes
Max Mendes

Posted on • Originally published at maxmendes.dev

The Real Problem With AI for Developers Is Not Capability, It's Overload

AI code overload is not a model-quality problem anymore. It is an ownership problem. The tools are already good enough to flood your repo faster than your team can understand, review, or maintain it.

I see this in my own workflow every week. Tools like OpenClaw, Claude Code, and Copilot are great at getting past the blank page. They turn rough ideas into working code fast. The trap starts right after that. If I let them run too far ahead, I end up with more implementation than understanding. The code exists, tests might even pass, but I no longer have a clean mental model of the system. Margaret-Anne Storey called this cognitive debt, building on MIT Media Lab research from 2025, and Simon Willison amplified the concept by describing his own experience of losing mental models of his AI-assisted projects.

That framing clicked for me more than any technical-debt discussion ever has.

The Output Problem Nobody Warned You About

Most posts about AI coding still focus on whether the model is smart enough. I think that debate is already stale. The real bottleneck moved downstream.

The 2025 DORA report says AI adoption among software professionals hit roughly 90%, with over 80% reporting productivity gains. Sounds great until you look at organizational delivery metrics, which stayed flat. AI boosted individual output (21% more tasks completed, 98% more pull requests merged) but PR review time increased 91% and PR size grew 154%. More code in, same review capacity out.

The Stack Overflow 2025 survey found 84% of developers now use or plan to use AI coding tools. But trust in AI output accuracy dropped to 29%, down from 40% the year before. And 66% of developers cited "almost right, but not quite" as their top frustration.

Here is the number that should worry everyone: the METR randomized controlled trial found that experienced open-source developers were actually 19% slower with AI tools, despite believing they were 20% faster. That is a 39-point perception gap. We feel productive while we are falling behind.

Cognitive Debt Is Worse Than Technical Debt

Technical debt is code that works but is messy. You know it is there and you can plan around it. Cognitive debt is different. It is code that works but nobody on the team actually understands it well enough to modify safely. The second is harder to detect and much harder to fix.

Anthropic's own study of 52 engineers found that developers using AI assistance scored 17% lower on comprehension tests (50% vs 67%), with the biggest drops in debugging. The code shipped, but the understanding did not.

Harvard Business Review reported on what they call "AI brain fry." A BCG study of 1,488 workers found that people managing AI output experience 33% more decision fatigue and 39% more major errors. Productivity peaked at three simultaneous AI tools. Beyond that, performance actually dropped.

A Multitudes study of 500+ developers found a 19.6% rise in out-of-hour commits among AI tool users, with Saturday productive hours up 46%. As LeadDev reported, faster code generation does not automatically create calmer teams. It often just creates longer evenings. Axios recently compared agentic coding tools to slot machines, noting that some developers now need sleep medication to break the late-night coding loop.

What I See in My Own Workflow

I use AI on almost every project. When I built FlowMate, a production SaaS handling email management with AI integrations, every line of AI-assisted code went through manual review. When I built automation workflows to find businesses without websites, AI handled the repetitive parts while I designed the system architecture.

The pattern that works for me: start with the agent, stop it early, read everything, then continue. The pattern that burns me: let the agent run ahead for 20 minutes, then try to catch up with what it built. The second approach feels more productive. It is not. I end up spending twice as long untangling code I should have reviewed incrementally.

This is exactly why I wrote about vibe coding culture a few weeks ago. The core risk is the same: the tools outrun the review. Vibe coding is the cultural norm. Cognitive debt is the technical consequence. They feed each other.

That matters for AI integration work more than people realize. The value is not in generating code faster. The value is in keeping the human ahead of the machine at every step.

The 80% Trap

Addy Osmani described this well: agents generate 80% of the code, but the remaining 20% requires deep architectural knowledge. The trap is that 80% feels like progress. You merge it. Then the 20% arrives and you realize you do not understand the 80% well enough to finish.

The data backs this up. GitClear analyzed 211 million lines of code from 2020 to 2024 and found code duplication grew 8x since AI tools became widely adopted. Healthy refactoring ("moved" code) dropped 39.9%. For the first time in their dataset, developers were pasting code more often than restructuring it.

CodeRabbit's research on 470 pull requests found AI-generated code produces 1.7x more issues overall. Security vulnerabilities were 2.74x higher. Readability problems were 3x more frequent.

This is what borrowed speed looks like. You moved fast for a week and now you are stuck for a month debugging code you never properly understood.

The Counterargument (And Why It Is Partly Right)

The obvious pushback: more code is still better than no code. I agree, up to a point. I would rather start from a rough AI-generated feature than from an empty file. I use AI every day for exactly that reason.

But this only works when the human stays ahead of the abstraction. If the tool is writing code faster than you can explain it, then your throughput is synthetic. You borrowed speed from your future self, and your future self will not be happy about the interest rate.

What Actually Works

I think the winning developers will not be the ones who generate the most code. They will be the ones who keep the shortest path between generated code and human understanding. Here is what that looks like in practice:

Smaller batches. Let the agent generate one function, review it, then continue. Not one feature.

Aggressive review. Read every line before it leaves your machine. If you cannot explain it to a colleague, it is not ready to merge.

Saying no. When the agent is about to create a hundred lines you do not fully need, stop it. Removing code is easier than understanding code you never asked for.

Good notes. Write down why the system works the way it does, not just what it does. Cognitive debt accumulates in the gaps between code and comprehension.

In my case, AI works best when I use it to compress effort, not outsource comprehension. If you are building client systems, the boring parts still matter. From solid web architecture to keeping a clean path to future changes through real project maintenance, the dead internet problem taught us that quality and authenticity still win, whether we are talking about content or code.

The Developers Who Will Win This

Model capability keeps improving. That is not the bottleneck anymore. AI code overload is the bigger risk, because unread code, invisible decisions, and broken mental models are what actually slow you down six months from now.

The Stanford Digital Economy Lab found that employment among software developers aged 22 to 25 fell nearly 20% between 2022 and 2025, while developers over 26 saw stable or growing employment. The "write code from tutorials" job is disappearing. The "understand systems and make decisions" job is not.

I would rather ship less code I still understand than more code I already mentally abandoned. That is not a productivity problem. That is an engineering discipline, and it is the one thing AI cannot do for you.


This article was originally published on maxmendes.dev.

Top comments (0)