The question going around is will AI replace junior developers. On my team it already answered itself, and not the way either side predicted. Nobody got fired. The juniors are still here, still shipping, and they have Claude too. That’s turning out to be the bigger problem, and it’s the one nobody is measuring.
Somebody finally said the quiet part out loud, and he said it in a research paper.
Seoul National University researchers interviewed 14 software engineers in South Korea, seven seniors and seven students heading into the job market, about what generative AI is doing to the way junior developers get trained. One founder in that study admitted he’d already swapped juniors for an AI subscription, then asked the question flat out: what can a junior engineer do better than a Claude subscription?
He didn’t have an answer.
Every response piece I’ve read since has one, and they’re all the same answer. Juniors are cheap. Juniors grow into seniors. Somebody has to mentor them. All true, and all completely beside the point, because none of it moves that founder an inch. He wasn’t asking about the pipeline. He was asking about this quarter.
I’ve got a real answer for him. It’s just not that one.
What Actually Happened on My Team
Nobody got fired. That’s the part every take misses.
The simple work went to Claude. Basic coding stuff, the small self-contained tickets you hand a new person because they’re hard to break and easy to review. Nobody hands those out anymore. It’s faster to generate them.
But the juniors and the interns are still sitting right there. They’re not on harder things either, and the reason is the part nobody writes about: they have Claude too. The work that used to be the on-ramp is gone, and the same tool that ate the on-ramp is doing the work that should have replaced it.
They’re not blocked. They’re producing. They ship.
They’re just not learning the domain.
You Can See It in a Pull Request
I can tell. That’s the blunt version.
When a PR lands now, I can tell who took the time to understand what Claude handed them and who didn’t. It isn’t about code quality, because the code is usually fine. It’s the domain knowledge underneath it. Ask one follow up question about why the thing works this way in this system and you find out in about four seconds whether there’s anything behind the diff.
Some of them are prompting and accepting. That’s the entire loop. And it’s invisible on a dashboard, because velocity looks fantastic.
This isn’t just my read on a code review, either. Anthropic ran a randomized controlled trial on 52 junior software engineers working in a Python library none of them knew. Half had AI assistance, half didn’t. The AI group finished about two minutes faster, which is nothing, then scored 50% on a comprehension quiz against 67% for the people who wrote it by hand. That’s close to two letter grades. The widest gap of all showed up on the debugging questions, which means the thing that degraded most was knowing when code is wrong and why.
The Seoul National University study gets at the same problem from the money side. The cost of generating code collapsed. The cost of verifying it didn’t. Verification is the expensive skill now, and you only pick it up by breaking things and finding out why, which is exactly the work nobody assigns anymore.
Addy Osmani has a name for what this does to a codebase over time. He calls it comprehension debt, the gap between how much code exists and how much of it anyone actually understands. Tests stay green. Velocity looks strong. Nothing on the dashboard tells you the understanding is gone.
I Ran This Experiment on Myself
I started at a new company recently, and for the first few months I didn’t use Claude at all.
Not on principle. I tried it, and I noticed I wasn’t learning the domain. I was producing work that passed review inside a system I couldn’t have explained to anyone. So I turned it off and did it the slow way.
That’s a genuinely weird move in 2026, with the tool sitting right there and everyone around you using it. Ten years in tech and I chose to be a junior again on purpose. I did it because of the one thing that hasn’t changed no matter how good the tools get.
I’m on the hook for the code I put in a PR. I’m the one responsible for it. So I need to understand it. I need to own it.
How I Actually Use It Now
I use it a lot more these days, with restraint.
The framing that works for me is pairing. Claude is the guy sitting next to me and the team’s researcher, not the guy doing the work while I watch. In practice that means I break the task into small steps before I ask for anything, then we work through them in chunks small enough that I can hold each one in my head. Slower per line, faster per feature, and it’s the same way I use it on my own projects.
That discipline exists because of one specific failure mode.
Claude can write 900 lines in 60 seconds. You can scan 900 lines in about 90 seconds and walk away feeling like you read them. You didn’t. I’ve talked to enough other developers to know this isn’t a me problem. Generation has outrun comprehension, and scanning feels close enough to reading that you never notice the swap happened.
So, Will AI Replace Junior Developers?
Here’s the answer that founder was looking for. Four things a junior does that a subscription structurally cannot.
- Carry accountability. A subscription can’t own a PR, can’t get paged at two in the morning, and can’t stand behind a decision six months later when it turns out to be wrong.
- Accumulate domain knowledge. Claude starts every session from zero. A junior who’s been in your system for eighteen months carries context no prompt reconstructs.
- Ask the dumb question. The one that surfaces the requirement everybody assumed. Claude answers questions. It doesn’t ask the one you never thought of.
- Become someone who can verify. That’s the expensive skill now, and the only way to get it is to be wrong and find out why.
And here’s where that founder is right, because pretending otherwise is how these posts lose the argument. If your juniors are prompting and accepting, they’re doing none of the four. He isn’t wrong about what he’s buying today. He’s wrong about what he’s giving up, and that bill doesn’t come due this quarter.
Try This on Your Next Ticket
Before you accept a single line, break the task into pieces small enough that you could explain each one out loud to another developer. Not summarize it. Explain it. Then actually try, out loud, to an empty room if that’s what it takes.
If you can’t, you didn’t read it. You scanned it.
Do that for one sprint and you’ll find out very quickly which side of the pull request you’re on.