Why Developers Stop Growing With AI (And How to Start Again)

A developer fourteen months into their first job closes more tickets than the person who held the chair three years ago. Clean pull requests. Nothing sent back twice.

Then someone in a design review asks why they used a queue instead of a cron job, and there's a pause, because the honest answer is that something suggested it and it worked and there was never a moment where it didn't.

That pause is the subject of this article.

The explanation everyone is using

Learning requires productive struggle. AI removed the struggle. Therefore developers who came up with AI never build the mental models struggle produces.

You've read a version of that recently. It's half right, and the wrong half is doing all the work.

Struggle has never been the teacher

Think about people who struggled enormously and stayed where they were. The self-taught developer fighting the same category of bug for three years. Ten years of experience that turned out to be one year repeated ten times.

Effort doesn't teach on its own. It deepens the groove you're already in, including the parts of it that are wrong. What converts effort into skill is a signal at the end that says that part, specifically, was wrong, and here is why.

Struggle only looked like the teacher because struggle and correction always used to arrive together. We credited the wrong one.

Struggle is the ticket price. Correction is the show.

The old job was a correction machine

Ignore the code for a second and look at what a junior's week actually contained.

A reviewer asked why you did it that way. The codebase refused your pattern because six other files had already settled the question. Production disagreed at 2am, in public, in a way you couldn't argue with. A user did something you had assumed nobody would do.

Four separate referees, every week. Each one specific. Each one carrying a cost, which is the part that makes it stick. You don't remember the eleven files you wrote that afternoon. You remember the design you defended badly in front of four people.

What AI actually removed

It removed the struggle. Widely reported.

It also removed the corrections, which is the load-bearing loss and is barely discussed.

When the first draft is decent, there's nothing to reject. The compiler is quiet. Tests pass. Review returns a nit about naming. Nothing in the pipeline says you were wrong about the approach, because you never committed to an approach clearly enough to be wrong about one.

Working code is the most dangerous kind. "It runs" gets promoted to "it's right", and the gap between those two is exactly where corrections used to live.

There's a second-order effect: everyone ships more, so reviewers read more, so review gets shallower per change. The one surviving referee is under-resourced by the same tool that removed the other three.

The model can't correct you, structurally

A model is built to be helpful. Ask a badly framed question, get a good-faith answer to the badly framed question. Push back on a correct answer and it often softens.

It doesn't reject your premise. It accommodates your premise. Arrive with a plan that's competent in its details and quietly wrong at its foundation, and you'll get back a beautifully executed version of the wrong foundation with no indication that this has happened.

A senior engineer's most valuable sentence is "why are you doing this at all?" It's valuable because you didn't ask for it. No prompt reliably produces it, since writing that prompt requires already suspecting the answer.

You cannot be corrected by something that agrees with you.

One gap, five symptoms

Seniors got faster, juniors got stuck. Same tool, opposite outcomes. A senior brings their own reviewer with them, internalised from a decade of being told no. A junior was borrowing that reviewer from the team, and the tool cancelled the loan.

More side projects, same skill level. A solo project has a struggle budget and no correction budget. Nobody in it can tell you your approach was wrong.

The plateau shows up around month twelve. Output improves in week one. Missing corrections cost nothing until you meet a problem the tool can't carry, roughly a year in. The delay is why it's invisible from the inside.

Code review became the most valuable hour of the week. Review didn't change. Everything else got quieter.

More advice doesn't fix it. Advice you were never wrong about first has nothing to attach to.

Key Takeaways

• Growth runs on corrections received, not effort expended.

• AI removed struggle and correction; only the first loss gets discussed.

• Models accommodate premises rather than rejecting them, so they can't supply the correction.

• Seniors are spending corrections they banked years ago; juniors never got to bank any.

• The fix isn't using AI less. It's manufacturing disagreement on purpose.

• A useful weekly metric: how many times did I learn I was specifically wrong?

How to buy your corrections back

1. Answer before you ask. Write your own approach in two lines before you prompt. The gap between yours and the model's is the correction, and it's free. No gap means you were right, which is also information. Forty seconds, highest yield habit here.

2. Ask it to attack, not to assist. "Improve this" gets a polish pass. "What breaks this under concurrency, and what would you have done instead?" gets something closer to an adversary. It won't volunteer disagreement, but it performs the role well when assigned. Assign it every time.

3. Buy cheap referees. Anything that can say no without a human in the loop is worth real money now: tests you didn't write, a staging environment that mirrors production, real users early, strict types and linters, one person who reviews properly.

4. Count corrections, not commits. At week's end, ask how many times you learned you were specifically wrong. Three or four is a good week. Zero for a month is a plateau you can't feel yet.

If you manage or mentor: the problem is invisible because the output looks fine. Review the reasoning, not the diff. "What did you consider and reject?" is now the highest-signal question in a one-on-one. And give people work that can genuinely break in a reversible way, because ownership without consequences is a simulation of ownership.

FAQ

Why do developers stop improving when they use AI?

Because skill comes from corrections, not effort, and AI removes most of the events that used to correct you. The compiler stays quiet, tests pass, and review returns cosmetic comments, so nothing tells you your approach was wrong.

Does using AI make you a worse programmer?

Not directly. It makes you a faster producer while reducing how often you're told you were wrong. Output rises and learning flattens, and the gap only becomes visible around a year in, when you hit a problem the tool can't carry.

Should junior developers avoid AI coding tools?

No. Avoiding them makes you slower without making you better, and nobody sustains it. The better approach is to keep the tools and deliberately add correction: commit to your own answer first, ask the model to attack your plan, and get real review.

Why are senior engineers benefiting from AI more than juniors?

Seniors carry an internalised reviewer built from years of specific corrections, so they can evaluate model output against a real mental model. Juniors were still borrowing that reviewing function from their team, and AI removed the tasks that supplied it.

Is productive struggle necessary for learning to code?

Struggle is the cost of learning, not the mechanism. Effort without a specific signal about what was wrong just entrenches your current approach. Correction is what converts the effort into skill.

How do you keep learning while using AI every day?

Track corrections rather than commits. Write your approach before prompting, ask the model for failure cases instead of improvements, invest in tests and staging that can reject you, and find one human who will review your reasoning honestly.

Related reading

• AI Won't Take Your Coding Job. It Will Change It. — what the job becomes when verification is the work.

• AI Writes Code That Looks Right — why "it runs" is not "it's correct".

• You're Using AI Like a Search Bar — the collaborator shift this piece depends on.

• How to Let AI Think for You Without It Thinking for You — the offloading boundary.

• Start Here — the whole Simply Explained map.

The bottom line

The junior crisis is real, but the mechanism being named isn't the right one. AI didn't remove the hard part and thereby stop the learning. It removed the disagreement, and disagreement was the engine.

That's oddly good news. Effort is expensive; correction is cheap once you know to look for it. You don't need to work harder or use worse tools. You need to arrange, on purpose, for something to tell you no several times a week.

AI didn't take the junior's job. It took the junior's referee. You have to hire a new one.

Adam Jaber is a software engineer who writes Simply Explained: complex topics, made simple. No jargon, no hype.