AI tools make senior engineers dramatically more productive. They make junior engineers slower. That's not a bug — and it's a problem nobody wants to say out loud. There's a paper in the April 2026 issue of Communications of the ACM, co-authored by Microsoft Azure CTO Mark Russinovich and GitHub VP Scott Hanselman, that finally names it. They call it "AI drag." And if you're early in your career and you've been leaning hard on AI tools, there's a decent chance it's happening to you right now — quietly, invisibly, in ways your sprint metrics aren't going to catch.
This isn't a post about whether AI is good or bad. It's a post about a trap that a lot of junior developers are walking into, and how to get out of it before it costs you the career you're trying to build.
What AI Drag Actually Is
AI drag isn't about being slow to adopt tools. It's the opposite.
It happens when you adopt the tools before you've built the foundation to use them well. You ask the AI for code. It gives you something that looks right. You don't fully understand it, but it passes the tests, so you ship it. Repeat a few hundred times and you've built a workflow that produces output — but hasn't built you. The problem compounds. Because when something breaks at 3am, or the PR reviewer asks you to explain why you made a specific architectural choice, or the AI gives you something subtly wrong and you need to catch it — all of those moments require judgment you develop by doing things the hard way first. Judgment that AI-assisted shortcuts specifically bypass. You can't evaluate output you don't understand. And if you've been accepting output you don't understand, you've been quietly accruing a skills debt that doesn't show up until it really matters.
The Feedback Loop Nobody Told You About Here's the thing about learning to code that nobody puts in a job description: most of it happens when things break.
You write something. It doesn't work. You stare at it. You Google it. You try five wrong things. You sleep on it. You figure it out. And somewhere in that miserable loop, something clicks — about how memory works, or how the framework actually handles state, or why that database query is slow. That's not suffering for suffering's sake. That's how the mental model gets built. AI removes the walls. And that sounds great until you realize the walls were load-bearing.
When the tool generates working code for problems you haven't struggled through yet, you skip the loop. You get the output without the understanding. Your velocity looks fine. Your foundations are hollow.
Senior engineers using the same tools don't have this problem — because they already did the hard part. They hit the walls years ago. Now the AI is accelerating work on top of a foundation they already own. They can look at generated code and immediately sense when something's off, because they've debugged enough of it to have instincts.
You're not there yet. That's fine — nobody starts there. But if you're outsourcing the part of the job that builds those instincts, you're not going to get there.
The Career Trap
This is the part that should make you uncomfortable. A lot of organizations are already moving toward a "senior-only plus AI" model — fewer headcount, more output per engineer, hiring only people who can operate independently at a high level. Junior roles are getting cut. The ones that remain are competitive.
If you're early in your career right now, the path forward runs through actually becoming a strong engineer — someone with real debugging chops, real systems intuition, real architectural opinions. The AI tools don't replace that path. They reward it. The junior dev who does the work to build genuine skills will use these tools better than anyone. The junior dev who uses these tools to avoid building those skills will plateau early, at exactly the moment the market starts asking harder questions.
You're building your future leverage right now. Make sure you're actually building it.
What to Do About It
Not "stop using AI tools." That's not the answer and it's not realistic. The answer is to be intentional about when you reach for them.
Struggle first, assist second. When you hit a problem you haven't solved before, try it yourself for a real stretch before handing it to AI. Twenty minutes of genuine effort — not to be a hero, but because that's where the learning lives. Then use the tool. Compare. Understand the diff. Never ship code you can't explain. If AI generated something and you couldn't walk a teammate through why it works, that's a flag. Don't merge it until you can. This slows you down in the short term. It's the whole point. Debug manually, on purpose. Pick one debugging session a week where you don't ask AI for help. Just you, the logs, and the problem. It'll feel slower. Do it anyway. Ask more questions in code review. When a senior engineer gives you feedback, don't just fix it — ask why. The institutional knowledge packed into a good code review comment is exactly the kind of thing you can't get from a language model.
Own your understanding of the system. Know how the pieces fit together. Know where the data goes. Know what breaks what. This context is yours, it's not in any model's training data, and it's what turns a code-shipper into an engineer.
A Note on Metrics
Your manager is probably not going to tell you about AI drag. Not because they're hiding something, but because velocity metrics don't catch it. Your PRs are getting merged. Your tickets are closing. Everything looks fine. The hollowness shows up later — at the performance review where you can't articulate your technical growth. At the incident where you freeze because you've never debugged something this gnarly without help. At the interview for the next job where they ask you to design something from scratch.
Don't wait for the metrics to catch up with you. Be honest with yourself now.
The AI tools are genuinely powerful, and you should use them. But they work best as a multiplier on skills you actually have — not as a substitute for the years of discomfort that build those skills in the first place. You're early enough in your career that there's still time to build the real thing. Don't trade that away for faster-looking tickets.
Sources: SD Times · LeadDev · IEEE Spectrum · Optimum Partners