I've got a good one for you. A VP of engineering told me last quarter, "AI is our junior team now." He said it with a smile. He meant it as good news. And honestly, on the spreadsheet it looks even better: cut the entry-level roles, let AI do the grunt work, let the senior people review the output. Clean math. Makes sense. Looks great.
Except the math has a hole in it. And that hole shows up within a year, guaranteed.
This is the talent problem I see most organizations not planning for. Or they're keeping quiet about it, which might be the same thing, or worse. Organizations are cutting junior roles because AI is going to handle the work that juniors used to do. The trouble is, that work was the best way juniors learned. And a lot of teams are finding that AI-generated code needs more senior judgment to review, not less. So we're building a review bottleneck and removing the pipeline that would actually solve it. That's what fascinates me about this moment.
The Budget Meeting Where Junior Roles Quietly Disappear
Picture a planning meeting. Budget season. You know how it goes. Someone pulls up next year's headcount spreadsheet and asks the obvious question: if AI writes all of this boilerplate, do we still need three junior hires?
The room gets quiet. Everybody looks around, nods, and two of those roles come off the board. It feels responsible. It feels modern. It feels good.
But here's the big "but." AI doesn't just produce code. It produces a particular kind of code that needs a senior-level person to approve it, especially if you're working with enterprise software. If you're building something for mom and dad, maybe not. But in the business world, automating real business processes, you need more rigor around it.
The Hole in the Math: AI Writes Code That Needs Review
Get specific about what's actually happening to the code. GitClear analyzed 211 million lines of code that changed from 2020 through 2024. In 2024, duplicated code blocks rose eightfold. Refactoring dropped from around 25% of changes to under 10%.
You all know refactoring.
Why Refactoring Is the Thing Nobody Puts on the Spreadsheet
Refactoring is one of those things most of our stakeholders see as rework, or waste. I try to teach people all the time, especially leaders and managers, that the nature of software development requires refactoring. It simply means we wrote the program with the knowledge we had at the time, then we learned more, or the technology changed, and we have to revisit the code based on what we learned.
People know the term "technical debt," but it's so much more than that. It's an overused word, in my opinion. Refactoring is the real, specific thing, and it's really important.
So the code we're now producing is more volume, less reusability. That leads to more rework. And the defects hide in the places only experienced people know about. They're in the dark corners that only the scar tissue of a developer who's been up at 2 a.m. troubleshooting a production issue can find.
AI is genuinely good at this. I use Claude Code for a lot of things, just to practice with it and experience the workflow, and it does an amazing job troubleshooting. But here's what I notice: we get desensitized. We watch the words scroll past us. Some of you are already doom-scrolling your phone while it runs. You're not even really reading what's going by. Why would you? It's handling it. I can eat a steak while Claude Code goes and figures out what happened with GitHub. And so we start looking at it less and less. That's a dangerous thing too. Senior developers have an acquired skill that helps us troubleshoot far better than a passive scroll ever will.
The Cost Nobody Modeled: Compute Now Costs More Than People
There's another piece of research worth sitting with, reported by Fortune and Axios this spring. The cost story is wild. Microsoft burned through its entire 2026 AI budget in just a few months. Uber's CTO said roughly the same thing four months in. An NVIDIA VP put it plainly: the compute now costs more than the people using it.
Let that sink in.
So here's the trap. You cut the cheap end of the pipeline. You kept an expensive AI running. And you pointed all of it at the one bottleneck you also stopped feeding.
Three Gaps Hiding Inside "AI Will Handle It"
These are not all the same problem, and they don't all get fixed the same way. But they're real gaps.
1. The Skills Gap
For decades, a junior learned by writing code. You took a small task, struggled with it, got it wrong, a senior marked it up and made you feel like an idiot, and you got better. That loop built judgment. That's where the scar tissue came from.
When AI writes the first draft, that loop disappears. Now the junior's job is to read, evaluate, and direct AI output. That's a real skill, and it's harder than writing the code, not easier. Nobody is born knowing how to spot a plausible-looking function that quietly went wrong.
It's like when teams tell me, "We don't need Agile, we just configure off-the-shelf software." I think that's even harder than writing software. You're still writing text files, still configuring the tool, and you still have to test it. Sometimes that's the hardest part.
With Claude Code, I'm trying to practice an architectural pattern, building constitution documents to keep the bot on really good guardrails. And I've come to a conclusion across the two or three programs I've built this way: it spends about 80% of its time writing, redoing, and refactoring tests. It doesn't take long to write the code. What takes long is checking whether we broke something. The regression testing, the unit testing, the CI suite that runs at least eight minutes every time I push a change. And I'll be honest, I'm not sitting there scrutinizing all of it. I'm not a seasoned architect anyway, so who cares what I think. But I'm trying to follow the process, and I catch myself going, "Looks good to me." Now ask yourself: if you're writing an enterprise program, does "looks good to me" feel good enough? If you're that VP of engineering, do you sleep well at night? I wouldn't.
2. The Mentorship Gap
This one has data. LeadDev surveyed more than 880 engineers and leaders for its 2025 report, and 38% agreed that AI tools have reduced the direct mentoring juniors get from senior people.
Think about why. The senior who used to teach through code review is now reviewing AI output at a volume that eats the whole day. There's no bandwidth left to teach. The mentoring didn't get deprioritized on purpose. It got crowded out.
3. The Institutional Knowledge Gap
This is the quiet one. Some of the most valuable things a senior developer knows never get written down. If you're an engineer, do you really write down, "Oh, that's a gotcha, let me file that away"? Usually not.
We have better tools now. If you're experimenting with Claude Code or Codex or Cursor and you're not documenting decisions, keeping a log of architecture decisions and PRDs, you're going to be in trouble. So maybe you start writing it down and let the bot read it. Great. But what's your process to keep it up to date? Why did the team abandon a particular architecture decision in 2019? Is anyone keeping a record? Which integration looks simple and will wreck your quarter later? We don't know.
That knowledge transfers by working shoulder to shoulder on real problems. Cut the apprentices and the transmission line goes dark. The knowledge doesn't get handed down. It just leaves when the senior does. And they will.
This Isn't Fear. It's Already in the Data.
So is this actually happening, or am I just forecasting fear? I believe it's happening, and I'm not here to scare you. I'm here to help.
The Stanford Digital Economy Lab ran a study I love the name of: "Canaries in the Coal Mine." They tracked payroll data across millions of workers. Employment for software developers aged 22 to 25 fell nearly 20% from the late-2022 peak. Developers over 26 stayed flat or grew. The two groups moved together for years, then split right after ChatGPT launched. The entry level is already thinning.
None of this means AI is the villain. AI is a genuine accelerant. It should be exciting, and embraced. I use it every day. The villain is how we use it. Are we treating the headcount line as a cost to cut instead of a pipeline to feed?
This is where the research on how teams actually improve matters. We talk about DORA a lot because they've spent years studying what makes software teams perform. The through-line is not raw output. It's learning culture, fast feedback, and the safety to surface problems early, when they're much cheaper to fix. More AI in the workflow can speed some things up and strain others hard. The teams that win keep learning. They don't just ship the most lines of code.
Naming It: The Apprenticeship Gap
Hold all of this together. The work juniors did is being automated. The skills juniors built are needed more than ever. The people who teach those skills now have no time to do it. And the learning culture you'd have used to develop people is the very thing under pressure. In the database world we'd call that recursion.
I'm going to call it the apprenticeship gap. I'm not claiming I coined the term. I'm reading the studies and naming what I see. Instead of "AI is going faster," call it the apprenticeship gap: the distance between the judgment your organization will need and the judgment it's actually building.
What To Do About It (None of It Requires a New Tool)
We're all still new at this, so let's be deliberate. Three moves. None of them require a new tool or framework to learn.
Build Apprenticeship on Purpose, Not by Accident
The old model assumed juniors would learn by osmosis, just from being near seniors and shipping tickets. That assumption started dying in the remote-work era, and it's dead now, because the tickets that taught them are done by AI.
Replace osmosis with design. Sit down and ask: what experiences build the judgment we're looking for? Then assign those experiences on purpose. Reviewing AI-generated pull requests. Writing a hypothesis for a product experiment. Facilitating a retrospective. Documenting an architecture decision. The work that builds a senior is no longer the same work AI took. You have to hand it over deliberately.
Coach the New Core Skill: Evaluation Before Generation
Most teams hand a junior an AI tool and say "go faster." To me that's backwards. Before you teach someone to prompt AI, teach them to judge AI. Put the junior in the reviewer's seat first.
When I teach my Product Owner and Scrum Master classes, I'll often hand people the prompts, not because I don't want them learning to write prompts, but because I want them to read the output first. If you can't read the output and figure out what it's telling you, you can write the best prompts in the world and it won't matter. Prompting is the easy part. It comes after.
So give a junior AI-generated code and ask: What's wrong here? What would you change? Would you ever ship that? Would you put your name on that deployment, even though the bot wrote it? Reading critically is the muscle. A junior who can spot the plausible-but-wrong function is worth more than one who can generate ten functions fast.
Redesign Mentorship for the AI Workflow
The old version of mentorship assumed time you no longer have. Line-by-line code review at AI volume is dead. So the unit of mentoring has to change.
Instead of marking up code, run a 30-minute pairing session where the senior thinks out loud while evaluating AI output. The junior watches the judgment happen in real time. You're not teaching syntax anymore. The tools handle that. You're teaching the questions a senior asks before they trust anything: What is this assuming? Where does this break under load in an enterprise application? What did the AI not know about our system? Because let's be honest, it only knows what we tell it, or what it goes and researches.
Every one of those moves takes the thing AI cannot do, judgment, and makes building it the explicit job, not a side effect.
In my own work, I notice how easy it is to get complacent. I'll have a conversation with Claude, which is good because I'm building context the bot doesn't have, and I can send it to research code that would've taken me weeks to read. But do I still trust the output? It doesn't know what it's saying. It's fundamentally scoring the probability of the next word. So judgment is everything.
Let's Be Honest About the Cost
Put the spreadsheet down for a second. What I'm describing is slower. I'm sorry, but it is, at least in the short term. A junior reviewing AI output with a senior coaching them through it is slower than the senior just doing it alone.
You've seen this before. Remember pair programming? Managers would say, "You've got two people doing the same thing." No. You've got two brains doing one thing. None of us is smarter than all of us. That's a hard lesson to teach someone who doesn't understand the nature of knowledge work.
When you pair, you spend money up front to save money later. Organizations can't seem to get that through our heads, even though we do it everywhere else. Finance invests millions into things that pay off later. It's the same with developing people, it's just hidden. It's not a line item. Maybe it needs to be one.
You're not buying speed this quarter. You're buying the senior engineer you'll desperately need in 2029, before someone else hires them. There's no faster way to grow one. There never has been.
Do One Small Thing This Week
Before your next budget or headcount conversation, try this. It'll tell you a lot.
Get your engineering leads in a room for 30 minutes. Put one question on the whiteboard: Where do the senior engineers we'll need in three years come from? Go around the table and get real answers. Not "we'll just hire them." No, you won't. From where? Trained by whom? Doing what work that builds the judgment we just described?
If the honest answer is "we assumed AI would cover it," you just found your gap, and you're in trouble. Write it down and go fix it.
Then pick one junior, an early-career person on your team, and give them one apprenticeship assignment this week. Make them the reviewer on an AI-generated pull request, and have a senior spend 20 minutes walking it through with them. Pair on it. That's it. One assignment, one pairing.
By Friday, one junior has reviewed AI output with a senior beside them, and your leadership team can name where the 2029 seniors come from, and commit to investing in them internally. Some of those people will leave. That's fine. But if you can't even name it, that is the work.
A Headcount Decision Is a Three-Year Bet
A headcount decision is not a cost cut. It's a three-year bet on the judgment your organization will have when it needs it most, and by then it's too late to start.
If this is the gap you're staring at, the good news is it's coachable, and you don't need a new framework to start. The way I teach Product Owners and Scrum Masters now is built around exactly this skill: putting people in the reviewer's seat, teaching them to judge AI output before they generate it, and designing the experiences that grow real judgment. If you want help closing the apprenticeship gap on your teams, come explore our classes and coaching. Build the seniors you'll need before you need them.