AI didn't make our new developers worse. It made them unfinished, and nobody noticed until production did.
A few months ago, one of the junior developers on my team messaged me late on a Thursday.
"The API keeps returning 500. I've asked the AI four times. Every fix breaks something else."
I walked over and asked one question.
"What does the traceback say?"
He looked at me for a second. Then he scrolled up through forty lines of red text. He had copied it, pasted it into a chat window four times, and never actually read it.
The answer was sitting three lines from the bottom. A KeyError on a field the serializer expected and a recent migration had renamed.
We fixed it in two minutes.
He wasn't lazy. He wasn't careless. He was one of the sharpest people we had hired that year, and he had shipped more features in his first three months than I did in my first year.
But he had never really read a stack trace. Not properly. Not once.
That was the night I realised we had a problem that no sprint report was going to show me.
The Speed Everyone Celebrates
Here is the story our industry is telling right now.
AI makes junior developers productive from day one. The gap between a fresher and a mid-level engineer is shrinking. New hires close tickets faster, open more pull requests, and need less hand-holding.
And on paper, it's true. I've seen it on my own team.
But there's a second story underneath, and it's the one that matters for the next ten years of your career.
For decades, output and understanding grew together. You couldn't ship a working Django view without first learning how requests, models and querysets fit together. The struggle was slow, but it left something behind.
Now the two have come apart. A junior can produce senior-looking output without building the understanding that used to come with it.
I've started calling this Hollow Velocity.
Hollow Velocity: shipping speed that looks like experience, without the mental model that experience used to build.
It looks great in a sprint review. It breaks the first time the AI is confidently wrong, and nobody in the room knows how to find out why.
Three Signs of Hollow Velocity
Once I had a name for it, I started seeing it everywhere. Not just in one developer. In patterns.
1. They can build it, but they can't explain it.
Ask "why did you use select_related here?" and you get silence, or "the AI suggested it." The code is correct. The reasoning was never theirs.
2. They debug by regenerating, not by narrowing.
An experienced engineer treats a bug like a search: form a guess, test it, cut the problem in half. A hollow-velocity developer treats it like a slot machine. Paste the error, pull the lever, try the new answer, repeat.
3. They freeze when the AI is confidently wrong.
This is the dangerous one. When the model invents a setting that doesn't exist, or misreads an old pattern in your codebase, there's no internal alarm. Nothing feels off, because they never built the instinct that says this doesn't smell right.
Why It's Happening
Learning to debug used to follow a loop:
- Something breaks
- You read the error
- You form a guess
- You test it
- You understand a little more than before
AI collapses that loop into three steps:
error → paste → answer
The steps it removes (reading, guessing and testing) are exactly where the learning used to happen. The answer arrives, but the understanding never gets built.
And honestly, it's not the juniors' fault.
We built this. In a lot of teams, especially in service companies where client deadlines drive everything, we measure people by tickets closed and features delivered. We praise speed in standups. Nobody gets praised for spending an hour reading Django source code to understand why a query was slow.
We rewarded the output and assumed the understanding would follow. It didn't.
What I Changed on My Team
I'm not anti-AI. I use it every day, and so does my team. Banning it would be pointless and a little dishonest.
But I changed what we pay attention to.
- The "explain it back" rule. In code review, any non-trivial change has to be explainable in two or three sentences by the person who opened the PR. Not perfectly. Just honestly. If they can't, we pair on it before merging.
- Read before you prompt. When something breaks, spend the first ten minutes with the traceback, the logs and the code. Write down one guess. Then ask the AI, and compare its answer with yours.
- Weekly debugging sessions. Once a week, someone shares a real bug from our codebase and walks through how they found it. The fix doesn't matter. The search does.
- Different questions in one-on-ones. Instead of "what did you ship?", I ask "what broke this week, and what did it teach you?"
None of this slows us down much. It just makes sure the speed has something underneath it.
If You're a Junior Reading This
You're not behind. You're in a strange moment that nobody before you had to deal with. Here's what I'd do in your place:
- Read the last three lines of every traceback first. Most of the time, the answer is already there.
- Write your guess down before you ask the AI. Even if you're wrong, being wrong on purpose is how you learn.
- Use AI to explain, not just to fix. "Why does this fail?" teaches you more than "fix this."
- Build one small thing a week without help. A view, a query, a management command. Feel the friction on purpose.
- Read the source. Django's code is open. When something surprises you, open it and look.
The goal isn't to stop using AI. It's to make sure that when the AI is wrong, you're not.
Back to That Thursday Night
That junior still uses AI every day. He's faster than ever.
But last month, he messaged me again about a failing deployment. This time the message was different.
"I think it's the connection pool. The traceback points to the worker timeout. Can you check if I'm right?"
He was right.
That message made me happier than any feature he has shipped. Not because he solved the bug, but because he read it first.
Seniority was never about how fast you write code. It was about knowing what to do when the code stops making sense.
AI can give our juniors the speed. Our job as leads is to make sure they get the rest.
Over to You
Are you seeing Hollow Velocity on your team, or in yourself? I'd genuinely like to hear how other leads are handling this. Tell me in the comments 👇
If this was useful, follow me here for more stories from the backend trenches, and subscribe to The Backend Tech Lead on Substack for weekly blueprints.
Top comments (0)