AI Coding Assistants Are Creating a Generation of Developers Who Can't Read Code

I watched a junior developer ship a 400-line PR in 20 minutes last week. It worked. The tests passed. The CI was green. Then I asked them to walk me through the error handling in the third function.

Silence. A long, painful silence.

They'd tabbed through the whole thing. Copilot suggested, they accepted, they moved on. The code was syntactically correct and semantically opaque. At least to the person who wrote it.

This isn't an outlier. It's the new normal.

And it should terrify you.

Not because AI coding assistants are bad. They're genuinely useful tools that make experienced developers faster. The problem is what happens when you hand a power tool to someone who never learned to use a hand saw. They'll cut something. They might even build something. But they won't know why it stands up, or why it doesn't.

Fast Fingers, Blank Stares

The numbers on AI-assisted development are staggering. GitHub reported that developers using Copilot accept roughly 30% of suggestions and complete tasks 55% faster. Cursor's adoption rate among developers with less than two years of experience is through the roof. The 2025 Stack Overflow Developer Survey showed that over 70% of respondents are now using AI coding tools in some capacity, and that number climbs above 85% for developers under 25.

But here's the number nobody's tracking: how many of those developers can explain what their code does without looking at it again.

I've started asking a simple question in code reviews: "What does this function do?" Not "what is it supposed to do", what does it actually do, line by line. The number of developers who can answer that question without re-reading their own code is shrinking fast. The "tab-tab-enter" workflow produces output. It does not produce understanding.

Speed of output is not speed of understanding. And the industry is optimizing for the wrong metric.

Reading Code Is the Job

Here's the uncomfortable truth: developers spend roughly 70% of their time reading code, not writing it. Google's own research confirmed this years ago. Debugging is reading. You read the error, you read the stack trace, you read the code path that produced it. Code review is reading. Incident response is reading. Onboarding onto a new team is weeks of reading.

AI coding tools optimize for the 30%. They make the writing part faster. But they do almost nothing for the reading part, and in practice, they often make it worse by flooding codebases with code that nobody on the team deeply understands.

Writing code is the easy part. Understanding it is where the real work lives.

The Illusion of Competence

There's a pattern I keep seeing, and it's the most dangerous one: a developer uses AI to write something they couldn't write themselves. It works. They move on. They now believe they understand that code, because it's their code. They approved a suggestion.

This is the Dunning-Kruger effect with a turbocharger. The tool fills in the gaps in your knowledge invisibly. You never see what you don't know, because the AI smoothed right over it.

I talked to a staff engineer at a large fintech company who described the situation like this: "We have developers who can scaffold a new microservice in an afternoon with AI. But when that service starts failing in staging because of a subtle ordering issue with database transactions, they can't debug it. They literally don't know where to start."

The Senior Dev Safety Net Won't Last

Right now, the system kind of works because senior developers exist. They catch the bugs. They flag the architectural issues. But seniors are drowning. Engineering managers I've spoken to report a 2-3x increase in review volume since their teams adopted AI tools. More PRs, more lines of code, more things to check.

The knowledge transfer gap is widening, not shrinking.

In three to five years, today's AI-dependent juniors become mid-level developers. They'll be the ones reviewing PRs. They'll be the ones on call. What happens when the safety net is made of people who learned to code by hitting Tab?

What Actually Works

I'm not saying ban AI tools. I'm saying we need to change how we train and evaluate developers. Here's what I've seen work in practice:

• Code reading before code writing: Stripe's onboarding has engineers read and trace existing code before writing a line. This should be standard.
• "Explain this function" as a daily practice: Before accepting a suggestion, you should be able to describe it. If you can't, you're not using a tool; the tool is using you.
• Pairing AI generation with comprehension checks: If Copilot suggests a function, write a one-line comment describing its behavior before merging.
• Code reading clubs: Sessions where teams read existing code together out loud, line by line. It builds the muscle AI tools atrophy.

The Two Paths

Path 1 is AI as a crutch—developers who can't operate without it and codebases nobody understands. Path 2 is AI as an accelerator for developers who know where they're going. The calculator didn't kill math education because we didn't let students use it until they learned the math underneath.

Use AI to go faster once you know where you're going. Don't use it to skip learning the map.

---