I'm going to say something unpopular and I want you to argue with me in the comments. AI coding agents are making junior developers worse. Not at shipping. At understanding. And understanding is the only thing that actually matters in the long run.
I'm not talking about seniors who use agents as a force multiplier. I'm talking about the developer who graduated six months ago, installed Cursor on day one, and has never written a function by hand. The one who can ship a feature in an afternoon but can't explain why the code works. The one who, when you ask them to debug a production issue, stares at the stack trace like it's written in a foreign language, because it is. They've never had to read one before. The agent fixed everything before they got the chance.
If you're that developer, I'm not blaming you. I'm blaming the industry for pretending this is fine.
The skill that agents are eating
When I learned to code, I spent hours reading other people's code. Not because I wanted to, but because I had to. I needed to understand how a framework worked, how a library handled edge cases, how a codebase was structured. That reading was slow, frustrating, and essential. It built a mental model of how software actually works. Not how to write it, but how to think about it.
AI agents are eating that process. Why read the codebase when the agent can summarize it? Why trace the execution path when the agent can explain it? Why understand the error when the agent can fix it? Every shortcut the agent provides is a shortcut past the learning that used to happen naturally.
The result is a generation of developers who can ship but can't debug. Who can generate but can't review. Who can prompt but can't read. And the scary part is that nobody notices until something breaks, because the agent handles the happy path beautifully. It's the unhappy path where the missing understanding shows up.
The audit problem
There's a concept I keep coming back to: you're not writing code anymore, you're auditing it. And auditing is exhausting in a different way.
When you write code, you have a mental model of what it does. You know the invariants, the edge cases, the assumptions. When you audit code someone else wrote, or that an agent generated, you're reverse-engineering that mental model from the output. That's harder. It takes longer. And it's the part most developers skip.
I've watched junior developers accept agent-generated code without reading it. Not because they're lazy, but because the code looks right. It compiles, it passes tests, it handles the obvious cases. The problem is the subtle ones. The race condition the agent didn't think about. The edge case that only triggers under load. The security implication of passing user input to a shell command. These are the things you catch by reading, and you can't read what you don't understand.
The counterargument I keep hearing
The pushback I get on this is always the same: "But I learn faster with an agent. I can explore more code, try more approaches, ship more features." And that's true. Agents are incredible for exploration. The problem isn't exploration, it's dependency.
There's a difference between using an agent to learn and using an agent to avoid learning. The first looks like: "I asked the agent to explain this pattern, then I rewrote it myself, then I asked the agent to review my version." The second looks like: "I asked the agent to write it, it works, next task." The first builds understanding. The second builds dependency.
Most developers I've worked with are doing the second one. Not because they want to, but because the agent makes it so easy. The path of least resistance is to accept the output and move on. And every time you do, you skip a learning opportunity that you won't get back.
The debugging gap
Here's where it shows up most clearly. Ask a junior developer who uses agents heavily to debug a production issue. Not a syntax error, not a failing test, but a real production issue: intermittent failures under load, a race condition, a memory leak, a corrupted state that only happens in certain conditions.
They struggle. Not because they're not smart, but because they haven't developed the debugging instincts that come from having broken things yourself. Debugging is a skill you build by breaking code, reading stack traces, adding print statements, forming hypotheses, and testing them. It's slow, painful, and irreplaceable.
Agents can debug. They're actually quite good at it when you give them the right context. But when the agent can't figure it out, the developer is stuck, because they never learned the process themselves. They outsourced the skill, and now the skill doesn't exist.
What I think we should do
I'm not arguing that agents should be banned. That's absurd. They're too useful and too embedded. I'm arguing that we should be honest about the trade-off.
If you're a junior developer: use the agent, but also read the code it generates. Not every line, but enough to understand the structure. When something breaks, try to fix it yourself before asking the agent. When you don't understand an error, read the stack trace before pasting it into the chat. Build the habit of understanding, even when the agent makes it optional.
If you're a senior developer: stop pretending the onboarding process hasn't changed. The new developer on your team has never written a function without an agent. They need different mentoring than you did. Teach them to read code, not just to prompt. Teach them to debug, not just to delegate. The agent will handle the writing. You need to handle the understanding.
If you're a manager: stop measuring output in features shipped. Measure it in understanding retained. The developer who ships ten features but can't debug any of them is a liability, not an asset.
The part where I'm probably wrong
I might be wrong about this. Maybe the next generation of developers will be better because they have agents. Maybe understanding code will matter less when agents can understand it for you. Maybe the skill that matters in 2030 isn't reading code but directing agents.
I don't think so. I think understanding is the foundation everything else sits on, and agents are building on a foundation that's getting thinner. But I've been wrong before, and I'd rather be wrong in public than right in silence.
So: change my mind. Tell me in the comments why I'm wrong. Or tell me I'm right and share what you've seen. Either way, I want to hear it.
The debugging gap shows up in interviews too. I have started asking candidates to walk through how they would debug a specific production issue. The ones who use agents heavily often describe a process that starts with "I would paste the error into the chat." That is not wrong, but it is not debugging either. It is delegation. And when the agent gives a wrong answer, which it does, they have no framework for evaluating whether the answer is right. They cannot distinguish between "the agent fixed it" and "the agent made it worse in a way that will not show up until next week."
What's your take? Are AI coding agents making junior developers better or worse?
Top comments (0)