Senior Engineers Complaining About Juniors Are Missing the Point

Senior engineers love complaining about juniors.

They complain juniors do not understand fundamentals.

They complain juniors use AI too much.

They complain juniors ask basic questions.

They complain juniors cannot debug production systems.

Some of those complaints are true. They are also incomplete.

Because the same industry that complains about junior quality spent years weakening the systems that used to create it.

Teamwork GIF by Dubsado - Find & Share on GIPHY

Discover & share this Teamwork GIF by Dubsado with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Juniors are not supposed to arrive finished

A junior developer is not a discounted senior.

A junior is a developer with potential, fundamentals in progress, limited production context, and a real need for feedback.

That should not be controversial. Many companies still act like it is.

They hire a junior and expect:

independent delivery
production debugging
architectural judgment
stakeholder communication
cloud deployment
test strategy
security intuition
codebase navigation
product sense

Those are learned abilities, not personality traits.

If the company does not teach them, the company should not be shocked when the junior learns from AI, YouTube, old docs, Stack Overflow, Discord, Reddit, and trial-and-error.

The mentorship gap is not mysterious

Good junior development requires slack in the system. Somebody has to have time to teach.

Someone has to:

explain the codebase
review PRs with reasoning
answer questions without making the junior feel stupid
give scoped tasks
connect bugs to system concepts
show how production incidents are handled
explain trade-offs
model debugging
call out risk before it becomes blame

That takes time. Companies cut that time first.

Then they complain the pipeline is weak.

That is not a junior problem. It is a resource allocation problem.

Psychological safety is not office decor

The research on team learning has been clear for a long time.

Amy Edmondson's 1999 paper, Psychological Safety and Learning Behavior in Work Teams, studied 51 work teams and found psychological safety was associated with learning behavior.

Source: Psychological Safety and Learning Behavior in Work Teams.

That matters in engineering because juniors learn by taking small interpersonal risks:

"I do not understand this code."
"I think this bug is deeper than the UI."
"I used AI to understand the error, but I want to verify it."
"I do not know whether this is safe."
"Can you explain why this pattern is preferred?"

If asking those questions gets punished, juniors stop asking.

Then seniors say juniors are quiet, passive, or not curious.

That is the predictable result of a team that punishes learning out loud.

AI fills the space mentorship left open

Stack Overflow's 2025 Developer Survey says 44% of developers used AI-enabled tools to learn coding techniques or a new language. [Stack Overflow AI survey]

GitHub's Octoverse 2025 report says nearly 80% of new developers on GitHub used Copilot within their first week. [GitHub Octoverse 2025]

Sources: Stack Overflow 2025 Developer Survey and GitHub Octoverse 2025.

This is the part senior engineers need to take seriously: AI is not only being used to generate code.

It is being used because juniors need explanations and often cannot get them from people.

AI answers:

What is this error?
What does this SQL join do?
Why is this React state stale?
What is a race condition?
How do I write a test for this?
What should I ask in code review?
What edge cases might I be missing?

That does not make AI a mentor. It makes AI the thing juniors reach for when the actual mentor is unavailable.

The old learning culture had shortcuts too

It is dishonest to act like older developers learned only through deep first-principles study.

Previous generations used:

Stack Overflow answers
snippets from blogs
copied config files
starter templates
WordPress themes
Bootstrap examples
jQuery plugins
internal code copied from older services
tutorials that skipped production concerns

Some developers learned deeply through those shortcuts. Some cargo-culted them.

That same distinction matters with AI.

The question is not:

Did the junior use outside help?

The question is:

Did the junior build understanding?

Review the thinking, not just the diff

A senior who wants better juniors should stop reviewing only the final diff. Review the thinking.

Ask:

Review question	What it teaches
What problem is this solving?	Product framing.
What did you try first?	Debugging process.
What did AI suggest that you rejected?	Judgment.
What edge case worries you?	Risk awareness.
What test proves this behavior?	Verification.
What part of this system do you still not understand?	Learning path.

That is how review becomes mentorship.

Without that, review becomes a gate. Gates do not create seniors. Mentorship does.

AI dependence is a real risk

There is a real danger in AI-assisted learning.

The paper The Widening Gap found that generative AI can help novice programmers, but weaker students may struggle more to ignore incorrect or unhelpful suggestions. [The Widening Gap]

A 2025 systematic review on GenAI and code comprehension found that AI explanations can support comprehension, but can also be inaccurate or difficult for novices to evaluate. [Code comprehension SLR]

That means teams should not tell juniors:

"Just use AI."

They should teach:

how to verify generated output
how to compare against docs
how to write tests
how to reject confident wrong answers
how to disclose meaningful AI assistance
when to ask a human

That is modern mentorship. Not nostalgia. Not tool panic.

The management failure nobody wants to own

Many companies removed the apprenticeship layer and replaced it with vibes.

They have:

no onboarding map
no junior-safe backlog
no mentor capacity
no documentation budget
no pairing culture
no AI policy
no explicit progression rubric
no time for seniors to teach

Then they ask:

"Why are juniors not ready?"

Because nobody built readiness. That is the answer.

What a real junior pipeline looks like

A serious junior pipeline does not need to be fancy. It needs to be intentional.

Timeframe	What should happen
Week 1	Environment setup, product overview, first docs fix, mentor assigned.
Month 1	Small bug fixes, guided PRs, test-writing practice, codebase map.
Month 2	Slightly larger feature work with review checkpoints.
Month 3	Limited ownership of a small surface area.
Month 6	Participation in production support with shadowing.
Month 12	Clear evaluation for mid-level readiness.