If AI Makes Experienced Developers 19% Slower, What's It Doing to Our Junior Engineers?

[vp_eng_keisha]

Spinning off from the measurement discussion, because this deserves its own thread.

The METR study showed that experienced developers (5+ years on their own repos) were 19% slower with AI tools. But here’s what terrifies me:

What happens when you give these tools to junior engineers who don’t have those 5 years of foundation?

What I’m Seeing on My Teams

I manage 80+ engineers across different experience levels, and the AI usage patterns are dramatically different:

Senior Engineers (5+ years):

• Use AI selectively and strategically
• Quick to spot when AI suggestions are wrong
• Treat AI as a “smart autocomplete” not a “thinking partner”
• Can explain every line of their AI-assisted code

Mid-Level Engineers (2-5 years):

• Use AI frequently but with some skepticism
• Sometimes struggle to identify subtle bugs in AI code
• Building judgment about when to trust vs verify
• Usually can explain their code after some thought

Junior Engineers (0-2 years):

• Use AI constantly—it’s how they learned to code
• Trust AI suggestions with minimal verification
• Often can’t explain WHY their code works, only WHAT it does
• Struggle when debugging production issues without AI help

The Mastery Problem

The Anthropic research on AI assistance and coding skills found 17% lower mastery scores for developers using AI assistance.

That’s not theoretical. I’m watching it happen in real-time.

Last month, one of our junior engineers (8 months tenure, bootcamp grad, bright and motivated) completely stalled on a production debugging session. The issue was a subtle race condition in async code—something an experienced dev could spot in 15 minutes.

They spent 3 hours asking Claude and ChatGPT variations of the same question, getting plausible-sounding but wrong explanations. They couldn’t:

• Read the stack trace effectively
• Understand the execution flow
• Form hypotheses about what might be wrong
• Use a debugger to validate their theories

Because they’d never needed to learn those skills. AI had always done that thinking for them.

The Long-Term Organizational Risk

Here’s what keeps me up at night:

In 3-5 years, we’ll have a cohort of “senior” engineers (by tenure) who:

• Can generate code incredibly fast
• Have weak debugging fundamentals
• Don’t understand system architecture deeply
• Can’t function when AI tools are unavailable (outages, compliance restrictions, network issues)

That’s an organizational capability crisis.

And it’s invisible on productivity dashboards. These engineers will show high commit counts, decent velocity on feature work, good test coverage. The weakness only appears under pressure—production incidents, complex refactors, novel architectural challenges.

The Uncomfortable Proposal

Should we restrict AI tool usage for junior engineers during their first 12-18 months?

I know how elitist that sounds. “Back in my day, we debugged with printf statements uphill both ways!” But hear me out:

Learning to code is fundamentally about building mental models.

You need to:

• Struggle with syntax errors until you internalize the language
• Fight with cryptic error messages until you learn to decode them
• Spend hours debugging until you understand system behavior
• Write boilerplate until you recognize patterns

That friction is where learning happens. If AI shortcuts all of it, juniors never build the mental models they need to grow into mid-level and senior engineers.

Proposed AI Usage Policy by Experience Level

What if we implemented tiered access:

Juniors (0-18 months):

• Prohibited for production code implementation
• Allowed for learning exercises (with mentor review)
• Can use for documentation and test generation (under review)
• Goal: Build fundamentals without AI dependency

Mid-Level (18 months - 4 years):

• Full tool access for implementation
• Mandatory explanation in PR descriptions for AI-heavy code
• Required to pass “understanding check” in code review
• Goal: Use AI as productivity tool while maintaining deep understanding

Senior (4+ years):

• Unrestricted access with professional judgment
• Trusted to know when AI helps vs hurts
• Goal: Maximum productivity with risk awareness

The Business Pressure Problem

But here’s my dilemma:

My CFO wants me to deliver more with fewer engineers. AI tools look like the answer—if one junior can generate 2× the code, we can hire half as many, right?

Except:

1. Code generation ≠ value delivery. More code isn’t better if it needs extensive review and rework.
2. Quality matters. AI-assisted code has 1.7× more issues—that’s real cost.
3. Capability debt compounds. Juniors who never learn fundamentals can’t grow into the seniors we’ll need in 3 years.

I’m caught between short-term productivity pressure and long-term organizational health.

What I Need From This Group

Has anyone:

• Implemented AI-specific onboarding policies for junior engineers?
• Measured skill development trajectories with/without AI assistance?
• Found ways to balance productivity pressure with capability building?
• Tracked whether AI-trained juniors hit mid-level promotion milestones slower/faster?

Because we’re making massive bets on tool adoption without understanding the talent development implications.

And by the time we realize we’ve eroded our engineering capability… it might be too late to fix.

---

What are you seeing with junior developers and AI tools? Am I overreacting, or is this a real problem?

[eng_director_luis]

Keisha, you’re not overreacting. This is exactly the right concern.

I’m implementing something similar to your tiered approach, though I hadn’t formalized it until reading this. Here’s what’s working (and not working) for us:

Our Current Approach

New Hires (First 3 Months):

• No AI tool access for coding tasks
• Must complete onboarding projects “vanilla”—no Copilot, no Claude
• Can use AI for learning/research with mentor present
• Rationale: Need to see baseline capability and establish fundamentals

Junior Engineers (3-18 Months):

• Limited AI access: Documentation, tests, boilerplate only
• Production code must be written without AI assistance
• Code review includes “Can you explain this line-by-line?” check
• Rationale: Building mental models while productivity matters less

Mid-Level+ (18+ Months):

• Full AI tool access with professional judgment
• Expected to identify when AI suggestions are wrong
• Accountable for all code they ship, AI-assisted or not

What’s Working

The “no AI for first 3 months” rule is surprisingly popular with new hires. Several have told me they were worried about becoming dependent on tools they didn’t understand.

One junior engineer said: “At my last company, I was using Copilot from day one. I felt productive but I was secretly terrified that I didn’t actually know how to code without it.”

That’s the fear Keisha is describing—and it’s real.

What’s Not Working

The mentorship burden is real. Senior engineers are spending 30-40% more time with juniors because they can’t “just ask Claude” when stuck.

That’s actually probably good for skill development, but it’s a real cost. We need to account for it in velocity planning.

Peer pressure from other companies. Juniors see friends at other companies shipping features fast with AI tools and wonder if we’re handicapping them. We have to constantly reinforce that we’re building long-term capability.

The Code Review Test

Keisha’s “understanding check” is critical. My informal version:

1. “Walk me through this function.” If they can’t explain the logic without reading line-by-line from the code, they don’t understand it.

2. “What would break if we changed X?” Tests whether they understand dependencies and side effects.

3. “How would you test this edge case?” Reveals whether they’re thinking about failure modes or just happy paths.

If an engineer can’t answer these, I ask them to rewrite it without AI. Usually they learn more in that rewrite than they did generating the original code.

The Measurement Challenge

We’re not formally tracking “skill development trajectory” yet, but we should be. I’d love to hear if anyone has metrics for:

• Time-to-promotion: Junior → Mid-level (with vs without heavy AI usage)
• Debugging proficiency scores over time
• Code review quality (how often their PRs need significant revision)
• Incident response capability (can they debug production without AI?)

These seem like leading indicators of whether AI tools are helping or hurting long-term capability.

The Business Case for Restrictions

When the CFO pushes back on “slower junior onboarding,” here’s my argument:

The cost of a bad hire is 30% of first-year salary (US Dept of Labor data). The cost of a junior who can’t grow into mid-level? Probably similar—you either fire them at 18 months or keep them stuck at junior level indefinitely.

If AI tool restrictions improve our junior → mid-level conversion rate from 60% to 80%, that’s a massive ROI. We need fewer hiring cycles, less turnover, stronger capability.

But we need data to prove it.

[product_david]

The business side of this is fascinating and terrifying.

Keisha, when you said “CFO wants more with fewer engineers,” that’s exactly the conversation happening at every board meeting right now. And AI tools are being positioned as the answer.

The False Math

Here’s the pitch I keep hearing:

Traditional Model:

• 10 junior engineers × K = M/year
• Output: X features per quarter

AI-Augmented Model:

• 5 junior engineers with AI tools × K = K/year
• AI tool costs: K/year
• Total: K for same output X

“Savings”: K/year CFO loves this!

Why the Math Is Wrong

But this only works if:

1. Output is actually the same. (Keisha and Luis are showing it’s not—quality drops, review burden increases)

2. You can actually hire competent AI-augmented juniors. (You’re saying we’re creating juniors who can’t function without AI, which is a different skill set)

3. Those juniors grow into mid-level engineers at the same rate. (Anthropic research suggests they won’t—17% lower mastery)

4. You don’t create technical debt that costs more to fix later. (Maya’s point about maintenance burden)

So the “savings” might actually be cost deferral, not cost reduction.

The Capability Debt Analogy

I’m starting to think about this like technical debt, but for talent:

Capability Debt = The gap between the engineering skill level you need and the skill level you’re actually building.

Every quarter you optimize for junior engineer output without building fundamentals, you:

• Ship features faster today
• Reduce your future senior engineer pipeline
• Increase dependency on AI tools
• Create brittleness in your technical organization

And just like technical debt, there’s a tipping point where you can’t ship anymore because you don’t have the capability to handle complexity.

What I’m Proposing to My CFO

I’m going to make a counterintuitive pitch:

Invest MORE in junior development, not less.

• Pair programming requirements (senior with junior)
• Mandatory “no AI” periods for skill building
• Structured debugging training
• Explicit mental model development

Yes, this costs more in the short term (senior engineer time, slower feature delivery).

But the ROI is:

• Higher junior → mid-level conversion rate (less turnover cost)
• Stronger technical capability at scale
• Reduced dependency on specific AI tools (avoid vendor lock-in)
• Better incident response and debugging (fewer customer-facing issues)

The pitch: This is like preventive maintenance. Pay now or pay way more later.

The Question

Has anyone successfully made this business case to a CFO who’s focused on quarterly costs? What metrics convinced them?