AI feels like the ultimate junior engineer—fast at the grunt work, but you still need to check everything. Is that the sweet spot, or are we settling?

General
1

I’ve been using AI pretty heavily for the past 6 months while building out our design system component library. Here’s what I’ve noticed: AI is incredible at the stuff I used to hate doing. Need to scaffold a new component with proper TypeScript types? Done in 30 seconds. Want to generate a comprehensive test suite for accessibility edge cases? Boom, written.

But here’s the thing—I still have to review every single line. And not just skim it. Actually review it, because about 1 in 5 suggestions has some subtle issue. Maybe it’s using the wrong ARIA attribute. Maybe it’s assuming a prop structure that doesn’t match our conventions. Maybe it’s just… slightly off in a way that would break things three components down the chain.

It reminds me of when I worked with junior designers at my old startup. They could crank out mockups fast, but they didn’t understand why we made certain design decisions. They’d copy patterns without grasping the underlying accessibility constraints or brand guidelines. Fast output, but heavy supervision required.

The data backs this up:

Recent studies show AI achieves up to 90% speedups on simple tasks like restructuring code and writing tests. But for complex work—debugging gnarly issues, making architectural decisions, understanding cross-system implications—the gains approach zero. One study even found developers were actually 19% slower on real-world problems when using AI, even though they believed they were 20% faster.

And here’s the kicker: only 33% of developers actually trust AI results. We’re using these tools constantly (82% of us weekly), but we don’t trust them. That’s… kind of telling, right?

So here’s my question: Is AI best understood as a junior engineer that never levels up?

Think about it:

  • Crushes repetitive tasks ✓
  • Needs constant supervision ✓
  • Doesn’t understand context ✓
  • Fast but not necessarily right ✓
  • Makes you more productive… if you’re senior enough to catch the mistakes ✓

The thing that bugs me is this: we’re celebrating the speed improvements on tasks that were already easy. Generating boilerplate was never the hard part. The hard part is understanding which boilerplate to generate, how it fits into the larger system, what edge cases matter, and what trade-offs we’re making.

Maybe that’s actually fine?

Maybe we’re not supposed to be using AI for the complex stuff. Maybe the value proposition isn’t “AI does what seniors do” but rather “AI does what juniors do, freeing seniors to focus on senior-level work.”

But then I think about what product_david said in another thread about individual speed not translating to team velocity. If I’m coding 90% faster but spending 2x as long in code review, did we actually gain anything? Some teams report PR review time increasing by 91% when AI-generated code hits the pipeline.

And there’s a darker question lurking here:

If AI handles all the junior-level work, how do actual junior developers learn to become seniors? A lot of senior expertise comes from having done the grunt work thousands of times. You learn patterns. You develop intuition. You understand why certain approaches work and others don’t.

Employment among developers aged 22-25 dropped nearly 20% between 2022 and 2025. Are we pulling up the ladder behind us?

I don’t have answers here. But I think we need to be honest about what AI is actually good at, versus what we’re trying to make it do. It feels less like a “coding assistant” and more like an “extremely fast junior engineer who never gets tired but also never improves.”

Is that the sweet spot? Or are we settling for “good enough” productivity theater while the real bottlenecks (understanding, design, architecture, integration) remain unchanged?

What’s your experience been?

2

Maya, this analogy resonates deeply from a team management perspective. I’ve been watching this dynamic play out across my 40-person engineering org, and the junior engineer comparison is spot-on—but I think there’s a critical dimension you’re highlighting that we need to talk about more.

The review bottleneck is real, and it’s changing the job.

You mentioned the 91% increase in PR review time. We’re seeing exactly this. When AI-generated code hits our pipeline, the code review process fundamentally changes. It’s no longer “did the developer think through edge cases?” It’s “did the AI hallucinate something plausible-looking but subtly broken?”

These are different cognitive tasks. Reviewing human code means understanding the developer’s intent and checking their reasoning. Reviewing AI code means you can’t assume any intent—you have to verify every assertion, every pattern, every assumption. It’s exhausting in a different way.

This is Amdahl’s Law playing out in real time: we’ve sped up code generation, but if the review process becomes the bottleneck, the overall throughput doesn’t improve proportionally. In some cases, it gets worse.

We’re creating a new role: AI Code Reviewers

The senior engineers who are good at reviewing AI output are becoming a scarce resource. They need to:

  • Understand the codebase context deeply
  • Know common AI failure patterns
  • Spot subtle logic errors that compile fine
  • Verify assumptions that weren’t explicitly stated
  • Check for security issues that look benign

This is senior-level work. You can’t hand this to a junior because they don’t have the pattern recognition yet. But here’s the problem: we’re asking seniors to do more review work and less building work.

One of my staff engineers told me last week: “I feel like I’ve become a full-time code reviewer instead of a coder. I’m spending 60% of my time reviewing AI-generated PRs from the team.”

The senior/junior dynamic is shifting in uncomfortable ways

Your point about AI doing junior work is crucial. In theory, this should free up seniors to focus on architecture, design, complex problem-solving. In practice, it’s creating a supervision tax.

If every piece of AI-generated code needs senior review, and we’re generating code faster, then seniors spend more time reviewing and less time on the strategic work we supposedly freed them up for. We’ve just shifted the bottleneck.

Data from our internal metrics:

  • Senior engineers: 45% of time in code review (up from 25% pre-AI)
  • PRs per week: up 40%
  • Time to merge: up 35%
  • Bugs in production: roughly flat (which means reviews are catching things, but at a cost)

The question that keeps me up at night:

Are we training our seniors to be better reviewers, or better builders? Because right now, the incentive structure favors the former. The engineer who can quickly review 20 AI-generated PRs is more valuable to team velocity than the engineer who spends a week architecting a clean solution.

This worries me from a career development perspective. The skills we’re optimizing for aren’t necessarily the skills that make great technical leaders.

And you’re absolutely right about the junior developer ladder. How do we develop the next generation of seniors if they never build the muscle memory from doing the foundational work? We promoted people because they’d solved hard problems repeatedly. If AI is solving the “training ground” problems, what’s the path forward?

I don’t have good answers either. But I think we need to be much more intentional about:

  1. What kinds of work we’re delegating to AI
  2. How we structure review processes to avoid burning out seniors
  3. How we create learning opportunities for juniors when AI is handling their traditional entry points
  4. Whether our velocity gains are real or just redistributing where the work happens

The junior engineer analogy works—but unlike junior engineers, AI doesn’t learn from feedback and eventually level up. That might be the fundamental problem.

3

This conversation is hitting on something I’ve been struggling with from a product perspective: we’re measuring the wrong outcomes.

Maya, you asked whether we’re settling for “productivity theater” while the real bottlenecks remain unchanged. I think that’s exactly what’s happening, and it’s creating a dangerous gap between individual perception and organizational reality.

The productivity paradox is real

Here’s what the data shows: 82% of developers use AI tools weekly. Adoption is near-universal. Ask any individual developer, and they’ll tell you they’re more productive. The surveys back this up—developers feel faster.

But when you zoom out to the organizational level, productivity gains have barely moved. We’re stuck at around 10% improvement in aggregate metrics. That’s a massive gap between individual experience and team outcomes.

This isn’t unique to engineering. We’re seeing the same pattern across knowledge work. High individual tool usage, strong individual satisfaction scores, but minimal movement on the metrics that actually matter: time to market, feature velocity, customer value delivered.

Individual speed ≠ team velocity

Luis mentioned this perfectly with the review bottleneck. Let me frame it from a product lens:

When I evaluate a new tool or process, I don’t care about individual efficiency gains. I care about end-to-end cycle time. If a developer writes code 90% faster but code review takes 91% longer, the net impact on our sprint velocity is… zero. Or negative.

The value chain hasn’t sped up. We’ve just redistributed where the time goes.

This is basic systems thinking. If you optimize one step in a process without considering the entire flow, you often just move the bottleneck. And bottlenecks don’t disappear—they just shift to wherever you’re not looking.

What happens when the easy stuff is automated?

Here’s what worries me about the “AI handles junior work” framing: it assumes the bottleneck was junior-level work in the first place.

In my experience, the constraint is almost never “we can’t write enough boilerplate fast enough.” The constraint is:

  • We don’t understand the problem clearly enough
  • We’re solving the wrong problem
  • We haven’t validated the assumptions
  • The architecture doesn’t support the feature we need
  • We have competing priorities and unclear strategy
  • Cross-team coordination is slow

These are senior-level, often non-coding problems. Automating code generation doesn’t touch them.

So we’re left with a situation where we can scaffold components 90% faster, but we still spend weeks in product discovery trying to figure out which components to build. AI doesn’t help with that part.

We’re optimizing for the wrong metric

The industry has always had a bad habit of measuring lines of code, commits, PRs shipped. These are terrible proxies for value. But they’re easy to measure.

AI supercharges this problem because it makes it really easy to generate a lot of code. So now we have more code, more PRs, more commits—and leadership sees the numbers go up and assumes we’re more productive.

But if that code requires more review time, introduces more bugs (1.7x more issues per the data), and doesn’t actually ship customer value faster, then what have we gained?

I’d rather have a team that ships one well-architected, thoughtfully designed feature per sprint than a team that generates 10 AI-scaffolded features that all need extensive rework.

The trust gap is the real signal

Maya mentioned only 33% of developers trust AI results. This is the most important stat in the whole discussion.

Think about what this means: we’re using tools we don’t trust, to produce outputs we have to verify carefully, in order to… what? Feel faster? Look more productive?

That’s not a productivity tool. That’s productivity theater.

If I have to review every line anyway, and I don’t trust the output, then I’m not actually offloading cognitive work—I’m just changing the type of cognitive work from “writing” to “reviewing.” And reviewing code you didn’t write is often harder than just writing it yourself.

So what’s the actual value prop?

I’m not saying AI tools have zero value. But I think we need to be much more honest about what they’re good for:

  • Generating options to consider (not final solutions)
  • Automating truly mechanical tasks (reformatting, refactoring)
  • Learning new patterns (not production code)

The value is in augmentation, not automation. Treating AI like a junior engineer who can ship production code is the wrong mental model. It’s more like a very fast reference library that sometimes hallucinates.

The moment we start treating AI output as “done” instead of “draft,” we’re in trouble. And I worry that the speed and convenience is seducing us into doing exactly that.

4

Maya, you’ve touched on something that keeps me up at night as I think about the future of our engineering organization: if AI eliminates the entry-level work, how do we build the next generation of senior engineers?

Luis and David are both right about the immediate productivity implications. But I’m worried about something more fundamental: we’re potentially eliminating the learning ladder that got all of us to where we are today.

Junior developer displacement is already happening

The data is stark. Employment among developers aged 22-25 dropped nearly 20% between 2022 and 2025. That’s not a gradual shift—that’s a structural change in the market.

Here’s what I’m seeing in recruiting:

  • Entry-level requisitions are down 40% across my network
  • Job postings now say “2-3 years experience minimum” where they used to say “new grads welcome”
  • Bootcamp graduates are struggling to land first roles
  • When we do hire juniors, we’re looking for people who can already work somewhat independently

The message is clear: if AI can generate boilerplate and write tests, why hire someone whose primary value was… generating boilerplate and writing tests?

But that “grunt work” was never just grunt work

Here’s what bugs me about the “AI handles junior tasks” framing: it misunderstands how people actually become senior engineers.

When I was a junior engineer at Google, I spent months writing tests, fixing bugs, and building features from detailed specs. That work taught me:

  • How to read and understand large codebases
  • Why certain patterns exist and others cause problems
  • How to debug issues systematically
  • What “good code” actually looks like in practice
  • How to think about edge cases and error handling

This wasn’t wasted time. This was my apprenticeship.

You don’t become a senior engineer by skipping the fundamentals. You become senior by doing the “simple” work thousands of times until you develop intuition about what will work and what won’t.

The expertise gap is going to get worse, not better

Luis mentioned that seniors ship 2.5x more AI-generated code than juniors because seniors know how to use AI effectively. That makes sense—seniors understand what they’re asking for and can evaluate the output.

But here’s the problem: where do those seniors come from?

They came from being juniors who did the foundational work. They built pattern recognition by writing code, making mistakes, getting feedback, and iterating. They developed judgment by seeing what works and what doesn’t in production.

If we skip that phase and jump straight to “AI generates code, seniors review it,” we’re not creating a path for juniors to become seniors. We’re creating a system where:

  • Seniors are a scarce, non-renewable resource
  • Juniors can’t break in because they lack the pattern recognition to use AI effectively
  • The skill gap between entry-level and senior widens dramatically
  • Eventually, we run out of seniors and have no pipeline to replace them

This isn’t just about individuals—it’s about organizational knowledge

At my current company, we’re scaling from 25 to 80+ engineers. Part of that growth should include junior engineers who learn our systems, absorb our patterns, and eventually become the senior engineers who mentor the next wave.

But if AI handles the work that used to onboard juniors, what’s the alternative path? We can’t just hire all seniors—they’re expensive, scarce, and frankly, they’d be bored if all they do is review AI output.

More importantly, your senior engineers won’t stay senior if they’re not solving hard problems. Luis mentioned one of his staff engineers feeling like a “full-time code reviewer.” That engineer is going to leave. And when they do, you’ve lost institutional knowledge that’s nearly impossible to replace.

The skill distribution is shifting in uncomfortable ways

Maya asked if AI is better suited as a junior engineer than a senior collaborator. I think that’s the right framing, but it leads to an uncomfortable conclusion:

If AI is a junior engineer that never levels up, and we need seniors to supervise AI effectively, then the optimal team composition becomes:

  • Lots of AI (cheap, fast, never improves)
  • A few elite seniors (expensive, scarce, reviews everything)
  • Almost no mid-level or junior engineers (displaced by AI)

That’s not a healthy ecosystem. That’s a top-heavy, fragile structure where:

  • Knowledge is concentrated in a small group
  • There’s no bench strength when seniors leave
  • Innovation slows because everyone’s focused on review instead of building
  • Entry to the profession becomes nearly impossible

Are we pulling up the ladder behind us?

This is the question that haunts me. Everyone in this thread—Maya, Luis, David, me—we all learned by doing the foundational work. We wrote boilerplate. We fixed bugs. We built features from specs. We learned by repetition and feedback.

If AI eliminates those entry points, how does the next generation develop expertise?

I don’t have a good answer. Some possibilities I’m exploring:

  • Explicitly create “learning projects” that juniors own without AI assistance
  • Pair juniors with seniors more intensively (expensive, doesn’t scale)
  • Redefine what “junior work” means in an AI-enabled world
  • Accept that the profession is becoming senior-only and adjust expectations

None of these feel satisfying. The first three don’t scale. The last one feels like we’re failing the next generation.

We need to talk about this

David’s right that we’re measuring the wrong outcomes. But I think we’re also optimizing for the wrong time horizon.

AI might make us 10% faster this quarter. But if it eliminates the pipeline that creates senior engineers, we’re trading short-term gains for long-term sustainability.

That’s a bad trade. And I’m not sure we’re making it consciously.

5

This thread captures the tension I’m navigating as a CTO: AI is changing not just what we build, but who builds it and how teams are structured.

Maya’s junior engineer analogy is compelling, but I want to push on it from a strategic perspective. The analogy works—but it might also reveal why we’re using AI wrong.

The gap between effective and ineffective AI use is expertise

The data Luis referenced is striking: senior engineers ship 2.5x more AI-generated code than juniors. 32% of seniors say more than half their production code comes from AI, compared to just 13% for juniors.

Why? It’s not that seniors have better tools. It’s that they know how to use them.

Effective AI usage requires:

  • Understanding what you’re trying to accomplish (not just how to code it)
  • Providing detailed, well-scoped prompts
  • Recognizing when the output is wrong or incomplete
  • Knowing which parts to accept and which to rewrite
  • Iterating systematically rather than blindly accepting output

These are all senior-level skills. They’re the skills you develop after thousands of hours writing code, debugging issues, and understanding what makes software work in production.

This creates a profound asymmetry

If only seniors can use AI effectively, then AI doesn’t democratize software development—it amplifies the productivity gap between seniors and everyone else.

The promise was supposed to be that AI would level the playing field. That junior engineers could be as productive as seniors by leveraging AI. But the opposite is happening: seniors who already had the advantage are pulling further ahead.

Keisha’s point about the learning ladder is critical. Juniors can’t use AI well because they lack the pattern recognition. But they can’t develop that pattern recognition if AI is doing the work they’d normally learn from.

It’s a catch-22. And it’s going to get worse before it gets better.

The trust gap tells us we’re not there yet

Maya mentioned that only 33% of developers trust AI results. I think this is actually the most important data point in this entire discussion.

Think about what 33% trust means:

  • 67% of developers don’t trust the code they’re generating
  • We’re using these tools constantly despite not trusting them
  • Every output requires verification by someone with sufficient expertise to spot errors
  • The review burden falls on seniors (because juniors don’t have the pattern recognition)

This isn’t a productivity multiplier. This is creating a dependency on senior engineering judgment that’s actually harder to scale than just writing code manually.

If I have to carefully review every line of AI-generated code, and I don’t trust it, then I haven’t offloaded cognitive work—I’ve just changed the shape of it. And reviewing code you didn’t write, with no insight into the reasoning behind it, is often more cognitively demanding than writing it yourself.

Are we creating a two-tier system?

David’s question about measuring the wrong outcomes resonates. But I think there’s a deeper structural issue emerging:

We’re potentially bifurcating software development into two distinct tiers:

  1. Senior engineers who use AI as a force multiplier - They understand context, can evaluate outputs, and ship code faster
  2. Everyone else who struggles to use AI effectively - Juniors, mid-level engineers who can’t leverage AI because they lack the expertise to evaluate it

If this bifurcation solidifies, the implications are stark:

  • Fewer total engineering jobs (AI + seniors replaces larger teams)
  • Much wider compensation gaps (elite seniors become even more valuable)
  • Reduced mobility (harder to break into senior tier without the learning ladder)
  • Concentration of technical knowledge in smaller groups (organizational fragility)

As a CTO, this worries me. I don’t want an organization where all the knowledge is concentrated in 5-10 senior engineers. That’s a single-point-of-failure risk. When those people leave—and they will, because reviewing AI code all day isn’t fulfilling—I’ve lost institutional knowledge that’s nearly impossible to replace.

AI as junior engineer is the wrong mental model

Here’s where I want to challenge Maya’s analogy. It’s accurate as description, but it might be the wrong frame for thinking about how to use AI.

A junior engineer is someone you invest in because they’ll eventually become a senior engineer. You accept the supervision cost because you’re building capability for the future.

AI doesn’t level up. It’s always going to be a junior engineer. So the economics are totally different.

With a human junior:

  • High supervision cost initially
  • Decreasing supervision over time
  • Eventually becomes independent contributor
  • Invests in institutional knowledge
  • Becomes a force multiplier as they grow

With AI as “junior engineer”:

  • High supervision cost (constant)
  • No decrease in supervision over time
  • Never becomes independent
  • No institutional knowledge
  • Productivity gains capped by review bandwidth

That’s not a junior engineer. That’s a tool that requires expert oversight.

What if we’re thinking about this wrong?

Maybe the mistake is trying to use AI like a junior engineer at all. Maybe the value proposition isn’t “AI writes code” but rather:

  • AI as a drafting tool: Generates options, not solutions
  • AI as a learning accelerator: Helps juniors understand patterns (with senior review)
  • AI as a mechanical automation: Refactoring, formatting, boilerplate (low-risk tasks)
  • AI as a reference library: Fast answers to “how do I…” questions

If we frame AI this way, the emphasis shifts from “speed” to “augmentation.” We’re not replacing human judgment—we’re supporting it.

The question is: do we need fewer juniors or more seniors?

Keisha’s concern about pulling up the ladder is real. But I think the answer isn’t to preserve junior roles artificially. It’s to rethink how we develop expertise in an AI-enabled world.

Some possibilities:

  • Redefine “junior work” - Maybe it’s not writing boilerplate anymore. Maybe it’s learning to evaluate AI output critically.
  • Invest in apprenticeship models - Pair juniors with seniors more intensively, even if it’s expensive
  • Create deliberate learning paths - Projects specifically designed to build pattern recognition, separate from production work
  • Accept a different talent pipeline - Fewer entry points, but different kinds of entry points

None of these are perfect. But I think the status quo—pretending AI doesn’t change the skill distribution we need—is the worst option.

We’re making critical decisions by default

David’s right that we’re measuring the wrong outcomes. Keisha’s right that we’re optimizing for the wrong time horizon.

But I think the deeper issue is: we’re not making intentional choices about how AI changes our teams.

Most organizations are adopting AI tools reactively. Developers start using them. Productivity numbers tick up (or appear to). Leadership celebrates. But nobody’s asking:

  • What skills do we actually need in an AI-enabled world?
  • How do we develop those skills in new engineers?
  • What’s our strategy for maintaining institutional knowledge?
  • Are we trading short-term velocity for long-term capability?

If AI really is best suited as a tool that requires senior judgment to use effectively, then we need to be much more intentional about:

  • How we recruit and develop senior talent
  • How we prevent senior burnout from endless code review
  • How we create paths for people to develop senior-level expertise
  • Whether the productivity gains are real or just shifting where bottlenecks appear

The junior engineer analogy is useful. But only if we’re honest about what it means: we’re adopting a tool that requires constant expert supervision, never improves, and potentially eliminates the path to developing that expertise in the first place.

That’s not necessarily a bad trade. But it’s a trade we should make consciously, not by accident.