AI is creating what researchers call “seniority-biased technological change.”

Here’s what that means: AI amplifies people who already have experience and judgment, it makes senior developers more productive. But it creates what Mark Russinovich (Azure CTO) and Scott Hanselman (VP Developer Community at Microsoft) call “AI drag” for early-in-career developers—the technology that should help them actually holds them back.

This isn’t speculation. A recent article in Communications of the ACM lays out the research. After GPT-4’s release, employment of 22-25 year-olds in software development roles fell roughly 13%, while senior roles grew.

The economic math is compelling: three senior developers with AI tools deliver what ten people used to. Lower headcount, better margins, faster shipping. This looks great in the short term.

This threatens the future of software engineering as a profession. If organizations stop hiring and training early-in-career developers now, where do the experienced developers come from in 5-10 years?

Why AI Creates Drag for Early-in-Career Developers

AI generates code that works, the code runs, tests pass, features ship, but the code has problems that experienced developers would catch immediately.

The issue isn’t that AI writes bad code, it’s that AI solves immediate problems without understanding deeper implications. It introduces patterns that mask real issues, creates designs that work now but fail under load, makes trade-offs without understanding operational context.

Senior developers catch these problems because they have pattern recognition from years of seeing mistakes in production, they know what fails under load, in edge cases, over time, and they have architectural intuition about what creates technical debt versus what’s sustainable.

Senior developers also have holistic understanding of the entire system and its operational complexity. They know how code gets deployed, monitored, debugged in production, scaled, and maintained over time. Even if you use different AI agents for monitoring, testing, and troubleshooting, it’s the senior developers who understand how all these pieces fit together and what makes something operationally sustainable in your specific environment.

Early-in-career developers don’t have this reference library yet, they can’t evaluate whether AI’s working code is actually good code. The CACM article gives a clear example: a coding agent “solving” a race condition by introducing a sleep statement. The code works, the race condition goes away, but an experienced developer knows this masks the real problem instead of fixing it, it will fail in production under different timing conditions.

This is what creates AI drag for early-in-career developers. They lack the judgment and context to steer, verify, and integrate AI output. They’re generating working code fast, but without the experience to know when that code creates problems down the road.

I’m Seeing This in Practice

I just finished reviewing the codebase for a project I’m working on. The entire codebase is AI-generated based on functional and technical specifications. Twenty items need fixing.

The big one: a flawed database design. Three tables in the ledger, the same record inserted into multiple tables instead of one table with one insertion and columns to indicate the record belongs to multiple ledgers.

This is exactly what the CACM article describes. The code works, it handles the functional requirements, tests would pass. But it creates operational problems – data consistency risks, maintenance burden, unnecessary complexity. An early-in-career developer using AI would have missed this, it would’ve shipped to production. An experienced developer sees it immediately.

This isn’t a failure of AI. AI solved the immediate problem based on the specifications. But AI doesn’t know that this design pattern creates technical debt, doesn’t understand the operational implications, doesn’t have the experience to recognize there’s a better approach.

The Pipeline Is Already Breaking

The labor data shows this is already happening at scale. After GPT-4’s release, employment of 22-25 year-olds in software development roles fell roughly 13% while senior roles grew.

Think of the software engineering profession as a pyramid. Senior developers at the top, experienced developers in the middle, early-in-career developers at the base learning the craft. The base is where people enter the profession, gain experience, and eventually move up.

The base is narrowing. Organizations are hiring fewer early-in-career developers because the economic math favors seniors with AI tools. But if you narrow the base, where do the middle and top tiers come from in five to ten years? You can’t sustain a pyramid by only hiring at the top.

The Paradox Making This Harder

Here’s what makes this problem more complicated: early-in-career developers want AI tools. They’re pushing for adoption harder than anyone else.

I’m seeing this in engineering leadership discussions, hearing it from other leaders. Early-in-career developers are often the change agents driving AI adoption in their organizations. They’re what people are calling “AI native” – they started their careers in a world where these tools existed.

They’re more comfortable with AI than many senior developers. They’ve already experienced the productivity gains. When they join teams not using AI tools, they feel the productivity gap acutely and push for change.

But here’s the paradox: the AI tools they’re comfortable with are preventing them from acquiring the in-field software engineering skills they need. They’re learning to direct AI to generate code, but they’re not learning how to recognize when that code creates operational problems. They’re not building the pattern recognition library that comes from seeing their own mistakes fail in production. They’re not developing the architectural judgment that only comes from experience.

They’re optimizing for today’s productivity at the cost of tomorrow’s capability.

Imagine what becomes possible if we give them the opportunity to combine their AI-native skills with in-field software engineering skills. That’s the workforce we should be building.

The Investment Required

Solving this requires investment, not just financial investment, but a fundamental shift in how we think about capacity and productivity.

We need to slow things down. This feels counterintuitive when AI is enabling three people to do the work of ten, but if we don’t deliberately create space for training, we’re optimizing ourselves into a crisis.

The CACM article proposes preceptorship programs as one approach. A preceptor is an experienced professional who takes direct responsibility for training less experienced colleagues – the term comes from medical education where senior doctors train residents. Instead of traditional mentorship where one senior developer occasionally helps juniors, preceptorship is structured: three to five early-in-career developers paired with a senior developer who dedicates significant time to their development.

The preceptor doesn’t just review code, they review the AI’s suggestions before the early-in-career developer implements them, helping the developer understand why certain approaches create problems, what patterns to watch for, and how to evaluate AI output. The AI becomes a teaching tool, not just a productivity tool.

This takes forms beyond preceptorship – code reviews become teaching moments not just quality gates, we ask early-in-career developers to spot what’s wrong with AI-generated code before reviewing it with them, we deliberately expose them to debugging, design trade-offs, and operational decisions, building the muscle of knowing when AI suggestions are wrong.

The CACM article proposes that coding assistants should offer an “EiC mode” – instead of immediately generating code, the AI would use Socratic coaching, asking questions that guide the developer to think through the problem themselves, similar to how a teacher asks “what do you think would happen if…” rather than just giving the answer. Khan Academy’s Khanmigo does this for teaching math, and the same approach could work for teaching software engineering judgment alongside generating code.

This reduces short-term capacity, so organizations need to accept that trade-off and make training an explicit goal, not something that happens when people have spare time.

The Question for Leaders

The question isn’t whether to hire early-in-career developers – we’ve established that the pyramid collapses without them. The question is how to develop them in a world where AI fundamentally changes how software gets built.

We need to create opportunities for AI-native early-in-career developers to acquire in-field software engineering skills. This is about preserving software engineering as an engineering discipline, not letting it degenerate into programming or code generation. Engineering requires judgment about trade-offs, understanding of operational implications, architectural thinking, systems design – skills that come from experience, not from prompting AI tools.

The path forward involves accepting reduced capacity in exchange for building capability. Structured preceptorship where senior developers dedicate time to training, not just occasional mentorship. Code reviews designed as teaching moments. Deliberately asking early-in-career developers to evaluate AI output before implementing it. Creating workflows where they’re exposed to the full software development lifecycle, not just code generation.

Organizations need to make training an explicit goal with dedicated time and resources, not something that happens when people have spare time.

We don’t yet know what the complete solution looks like, the profession is still figuring this out. But we do know that training the next generation of software engineers is not optional. The organizations that invest in solving this now will be the ones with the experienced developers they need in five to ten years.

What are you seeing in your organization? How are you thinking about developing early-in-career developers alongside AI adoption?

---

Research source: Russinovich, M. and Hanselman, S. “Redefining the Software Engineering Profession for AI.” Communications of the ACM, April 2026. https://mags.acm.org/communications/library/item/april_2026/4331067/

About the author: Jawahar Malhotra is a technology executive turned leadership coach, working with CEOs and C-suite leaders on organizational transformation. With 20+ years building and scaling technology teams, he helps leaders create the conditions for sustainable high performance.

Work with me:

• Individual Growth: Professional Growth Through Self-Awareness – 3-session program with iEQ9 Enneagram assessment
• Organizational Growth: Leadership Succession Partnership – De-risking critical leadership transitions in Product, Engineering, and Design
• C-Suite Growth: CEO Coaching Partnership – 12-month coaching relationship for transformational leadership
• Schedule a 15-minute conversation