I recently came across a post that started a chain of thought for me. The claim was that senior developers — people with many years in the industry — gain the most from AI tools, while their junior colleagues have far more to lose than to gain by leaning on them.
I've been thinking about it since.
Disclaimer: I'm by no means a senior in the tech space. I value and understand that knowledge gained through experience and hardship has tremendous value and shouldn't be overlooked. But being on the other side of that line is probably what makes the question worth asking out loud.
Chapter I — Use It or Lose It
Let me start with the obvious part: what we don't use atrophies eventually. This is true across fields and industries and has stood the test of time. Muscles, languages, mental arithmetic, sight-reading music. Why would tech be different?
The version of the argument I keep hearing goes something like this. Experienced developers have seen enough issues and bugs to spot when AI is suggesting something that won't work. A junior raises their first PR and gets thirty comments asking them to fix things they didn't know were problems. That kind of foresight can't be bought or simulated — it's paid for in incidents, bad deploys, and reviews that stung a bit.
So far, so good. But there's a hole in it, and it's the same hole "use it or lose it" always has.
If atrophy is real, it applies to everyone.
The senior's advantage isn't a permanent trait. It's accumulated capital. It was built by reading a lot of code closely, sitting with bugs longer than was comfortable, and being wrong enough to develop taste. If that same person spends the next three years reviewing generated code at speed instead of writing and debugging it themselves, that capital doesn't sit there gathering interest. It depreciates like anything else.
Which changes the question. It's not "who benefits most?" It's "who can afford this, and for how long?"
Chapter II — What Juniors Actually Lose
I don't think the risk for junior developers is that they'll know less. You can look things up. The risk is more specific, and it's worth naming precisely.
What juniors are missing isn't knowledge. It's an evaluation function — the ability to look at a plausible-looking solution and tell whether it's actually right.
That's the whole game with these tools. The output is fluent and confident whether or not it's correct. A senior reads a suggestion and somethings stand out: that error handling is wrong, that query is going to hurt at scale, that's not how this library actually behaves. A junior reads the same suggestion and it looks... fine. It looks like code. It compiles.
And here's the uncomfortable part: the evaluation function gets built by doing exactly the work the tool removes. You learn what bad code feels like by writing bad code and then living with it. You develop a sense for where bugs hide by hunting one badly for two days before finding it.
There's a term for this in learning research — desirable difficulty. Struggle that feels inefficient in the moment is often the thing that makes the learning stick. AI is extremely good at removing precisely that kind of friction.
Chapter III — Replacing the Attempt vs. Reviewing It
I don't want to land on "juniors shouldn't use AI," though, because I don't believe it and it isn't what actually happens.
Juniors were never learning through pure suffering anyway. They were learning through suffering with feedback — a senior on the PR, someone pairing with them, a review that explained the why. The struggle mattered because someone was there afterwards to tell them what the struggle meant.
So the useful line isn't AI vs. no AI. It's:
Does the tool replace my attempt, or respond to it?
Ask it to write the function before you've thought about the problem, and you've outsourced the thinking. Write your version first, then ask what's wrong with it, and you've gained a reviewer with infinite patience. Same tool, opposite outcomes. The order of operations is the whole thing.
This is also where the point I keep coming back to lives. Working with AI genuinely helps when you're rubber-ducking through a problem, or when you want to ask every question you have without worrying that you sound like you don't know what you're doing. That's real, and I don't think people who've never been the most junior person in the room appreciate how real it is.
But it comes with a cost worth naming. A junior's questions are signals. They tell the team where the gaps are, what onboarding missed, who's stuck this week. When all of those questions go to a chat window instead, the team loses that signal — and the junior loses a hundred small chances to build a relationship with someone who could actually mentor them.
Ask the model. Then still ask the person.
Chapter IV — Which Skills Are Safe to Lose?
Every abstraction we've adopted has cost us a skill, and we mostly decided it was worth it. Very few of us write assembly by hand. Most of us couldn't manage memory manually under pressure. Compilers, IDEs, garbage collection, Stack Overflow — each arrived with someone predicting the rot of a generation of programmers.
Sometimes they were right, and it didn't matter.
So maybe the better question isn't whether AI causes skill atrophy. It obviously does; everything does. The question is which skills are load-bearing.
My rough attempt at the line:
Probably safe to outsource — syntax recall, boilerplate, the argument order of a standard library function, the flags for a CLI you touch twice a year.
Not safe to outsource — telling whether code does what you think it does. Holding a system in your head. Debugging something nobody has written a blog post about. Knowing which question to ask.
The first list is lookup. The second is judgment. Tools have always been fine at replacing lookup. This is the first one that convincingly imitates judgment, which is what makes it different, and what makes it worth being deliberate about.
Chapter V — So, Who Benefits Most?
I started this with someone else's claim: seniors gain the most, juniors have the most to lose. Four chapters later I'm not sure it's a question about seniority at all. I think it's a question about what you're spending, and whether you've ever looked at the price.
I don't have an answer for you. I'm not convinced the answer transfers between people anyway. But these are the questions I've ended up asking myself, and I'd rather hand them over than pretend I've resolved them.
If your judgement is capital, when did you last add to it? Not spend it — add to it. Reviewing generated code at speed draws down the reserve. What's been topping it back up?
When you reach for the tool, is it replacing your attempt or responding to it? Be honest about the order of operations. Most of us know which one we did.
Which of the skills you're shedding are lookup, and which are judgement? And would you notice the difference before the moment you actually needed it?
What's the last thing you did the hard way on purpose? If nothing comes to mind quickly, that's information.
And the one sitting underneath all of them: what are you optimising for? Shipping this week, or still being worth something in five years? Both are legitimate. Plenty of people have good reasons to choose the first — deadlines are real, rent is real. But it's a trade, and trades go badly when you don't know you're making one.
So — who benefits most from AI?
My best guess is: whoever knows what it's costing them and has decided the price is worth paying.
Which one is that for you?
Top comments (0)