AI Is Making Engineers Faster. But How Will We Build the Next Generation of Senior Engineers?

There is a conversation happening inside engineering organizations right now that probably sounds familiar.

Someone looks at the backlog. Then they look at what coding agents can already handle: small bug fixes, routine implementation, test scaffolding, documentation, refactoring, even entire first passes at features.

The productivity case is getting easier to make. The harder question is what happens after that.

Stanford’s analysis of payroll data found that employment for software developers aged 22 to 25 fell by nearly 20% from its late 2022 peak through July 2025, while employment for other age groups continued growing.

That is one dataset, not a verdict. The researchers themselves caution against claiming AI fully explains the change. Hiring conditions, interest rates, the post pandemic technology correction, and other economic factors were moving at the same time.

But underneath the employment numbers is a problem that extends well beyond junior hiring.

If AI can do much of the work engineers once learned by doing, where does the experience come from next?

The obvious concern is that there is less work for junior engineers. The bigger concern is that some of the work disappearing is the same work that taught engineers how systems actually behave.

Debugging the strange production issue. Reading code they did not write. Making a bad assumption and discovering why it was bad. Sitting through a difficult code review. Tracing a request through three services. Shipping something, watching it fail, and understanding what they missed.

That work was never particularly efficient. It was also how engineers got good.

So we do not think this is simply an entry level employment problem. We think it is a pipeline problem.

And eventually, it becomes an engineering capability problem.

The Spreadsheet Makes Sense Until You Look Past the Quarter

The short term logic behind AI adoption is not difficult to understand.

Experienced engineers equipped with good AI tools can move faster. Tasks that once consumed hours can take minutes. Boilerplate can be generated. Tests can be scaffolded. Documentation can be summarized. An engineer can explore an unfamiliar codebase without spending half a day searching through it manually.

For engineering leaders under pressure to deliver more without growing headcount at the same rate, that matters. It also changes the hiring equation.

Microsoft’s Mark Russinovich and Scott Hanselman described the mechanism in Communications of the ACM. Agentic coding assistants can multiply what experienced engineers are able to ship while providing less immediate leverage to early career developers who do not yet have the judgment or system context required to steer, verify, and integrate what the agent produces.

The resulting incentive is understandable: hire experienced engineers, give them increasingly capable tools, and automate more of the work around them.

The Stanford data offers one signal of where that could already be happening. After accounting for firm level effects, young workers in the most AI exposed occupations saw a 16% relative decline in employment. The declines appeared primarily where AI automates work, while the effects were more muted where AI augments it.

None of that makes the short term calculation irrational. The problem is what happens when you keep running it.

Senior engineers are not an infinite resource. They came through a process that gave them progressively harder problems, greater system context, more opportunities to fail, and eventually ownership.

If the early stages of that process disappear, you have not eliminated the need for experienced engineers. You have changed where they are supposed to come from.

The spreadsheet works this quarter. The pipeline shows you what happens five years from now.

AI Is Removing Friction. Some of That Friction Was Useful.

Experienced engineers have seen versions of this problem before.

Skip the refactor. Defer the upgrade. Put off documentation. Cut the on call training because the team is busy.

Every decision can make sense when viewed independently. The consequences appear later.

AI introduces a more subtle version of the same tradeoff because many of the things it removes are things engineers genuinely do not enjoy doing.

Consider a flaky test.

An engineer reads unfamiliar code. They form a theory. The theory is wrong. They add logging. They follow the wrong path. Eventually they notice something they did not understand about the system. Maybe they ask another engineer a better question than they would have asked an hour earlier.

From a throughput perspective, most of that time looks wasted. From a learning perspective, something important happened.

Now give the same problem to an agent.

The agent traces the likely cause, proposes a change, updates the test, and explains what it did. The engineer reviews the diff. CI passes. The ticket closes.

That is unquestionably useful. But it is not necessarily the same experience.

Researchers at Seoul National University interviewed 14 junior and senior engineers in South Korea and described a pattern they call “absorption.” Work that once went to less experienced engineers is increasingly redirected into senior plus AI workflows. In the process, junior engineers can lose the productive struggle through which expertise was traditionally developed.

The study is small, and it should be treated accordingly. But the underlying pattern should be recognizable to anyone who has learned software engineering by doing it.

When AI absorbs the work, it can also absorb the opportunity to learn from the work.

And this does not stop mattering once someone loses the word “junior” from their title.

Every engineer encounters unfamiliar systems, technologies, architectures, and failure modes. A senior Go engineer learning a new distributed system still has things to learn. An experienced backend engineer moving into AI infrastructure still has gaps. A staff engineer taking ownership of an unfamiliar platform still needs to build context.

Expertise is not something an engineer finishes acquiring.

The question is whether AI helps accelerate that process or quietly allows us to skip parts of it.

The Tool Is Not the Whole Story

It is tempting to turn this into a simple question about the technology itself.

Does AI make people worse engineers?

The research suggests the answer is more complicated. The outcome depends, in part, on how the tool is used.

Anthropic ran a randomized controlled trial with 52 mostly junior engineers learning an unfamiliar Python async library. Participants using AI assistance scored 17% lower on a comprehension quiz than those who coded without it, with the largest difference appearing in debugging. The speed advantage for the AI assisted group did not reach statistical significance.

But the more interesting finding was what happened inside the AI group.

Developers who primarily used AI to ask conceptual questions scored 65% or higher. Those who delegated code generation scored below 40%. The researchers identified six different usage patterns, three of which kept developers cognitively engaged and preserved more of the learning process.

Same technology. Very different outcomes.

That distinction matters far beyond onboarding junior developers.

Think about how engineers use coding agents today.

One engineer asks the agent to explain an unfamiliar package, challenges its assumptions, writes an implementation, and then uses the agent to critique it.

Another describes the ticket, accepts the generated implementation, watches the tests pass, and moves on.

Both may close the same ticket. Both may look equally productive in Jira. But they are not necessarily building the same understanding of the system.

That turns AI usage into an engineering practice question, not simply a tooling question.

Do engineers understand the code they are merging? Can they explain why the implementation is safe? Are they challenging the agent or accepting its first answer? When production behaves differently than the model predicted, can they continue debugging without it?

Those habits matter at every experience level.

Multiplied across an engineering organization and several years, they help determine who can actually own the systems being built.

Throughput Is Becoming an Even Worse Measure of Engineering Capability

Software organizations have always had a measurement problem.

Tickets closed, pull requests merged, story points completed, and lines changed are visible. Judgment is much harder to put on a dashboard.

AI widens that gap.

An engineer can now produce more code without necessarily understanding proportionally more of the system. That is not automatically bad. We use abstractions everywhere in software precisely because engineers should not have to understand every layer underneath their work.

But there is a difference between abstraction and dependency.

The Anthropic study illustrates the problem. The AI assisted participants produced better code during the learning exercise while demonstrating weaker comprehension afterward.

A dashboard measuring only output could conclude that the AI assisted group performed better. A production incident six months later might reveal something different.

This is why the more interesting question is becoming:

What can this engineer do now that they could not do six months ago?

• Can they debug an unfamiliar service?
• Can they explain why a change is safe rather than simply explain what changed?
• Can they review an agent generated diff and catch a subtle architectural problem?
• Can they reason through a production failure when the obvious solution does not work?
• Can they take ownership of a component rather than simply contribute code to it?

For an early career engineer, those questions tell you whether they are moving toward independence.

For a senior engineer, they tell you whether expertise is continuing to deepen or whether AI is simply increasing the volume of work moving through them.

The exact measurements will vary from team to team. The principle should not.

Measure the capability you are growing, not just the work that shipped.

Trace Where Judgment Comes From

If an engineering leader came to us tomorrow concerned about what AI was doing to their team’s long term capability, we would not start by arguing about how many junior engineers they should hire.

We would start somewhere more fundamental.

Where does judgment come from inside the organization?

Look at the work engineers were doing two or three years ago and compare it with what happens today.

Which tasks taught people how the architecture worked? Which tasks forced engineers to debug? Where did they learn to recognize a dangerous implementation? What gave someone enough context to eventually own a service?

Who does those things now?

If the answer increasingly becomes “the agent,” there is a gap worth understanding.

Then look at mentorship.

Russinovich and Hanselman propose a preceptor model borrowed from medicine. Early career developers work alongside senior mentors inside real product teams, making learning part of the engineering process rather than something that happens around it.

They are candid about the cost. Developing engineers requires experienced engineers to spend time developing engineers.

AI does not remove that cost. If anything, it may make the investment easier to avoid because the alternative can look so productive in the short term.

Then look at how AI itself is being used.

If asking conceptual questions strengthens understanding while blind delegation weakens it, that distinction should eventually become part of team norms rather than remaining an individual preference.

And finally, look at the entire path from learning to ownership.

The Seoul National University researchers argue that preserving the pathway requires deliberate design across education, workplaces, and the criteria used to evaluate engineers.

These may sound like people problems. They are also system design problems.

Where does knowledge enter the system? Where does it get reinforced? What happens when an upstream stage disappears? Where are you creating dependencies? How long does it take before a failure becomes visible?

The engineering talent pipeline is a system too. It just has unusually long latency.

The Engineering Role Itself Is Changing

There is another possibility worth considering.

Maybe the answer is not preserving every task engineers used to perform. Maybe the role has to change.

That is particularly important at the entry level, where AI is increasingly capable of doing the exact work companies historically assigned to new engineers.

IBM has taken that view.

In February 2026, IBM announced plans to triple its US entry level hiring across technical and administrative roles, without disclosing specific headcount figures. Its chief HR officer said AI can perform much of the entry level work that existed two or three years earlier, which means those roles need to create value differently.

For software engineers, that has meant spending less time on routine coding and more time working with customers.

IBM’s chief HR officer also raised the longer term question directly: if a company stops investing at the entry level, what happens three to five years later?

There is no pipeline.

That is one company’s approach, not an industry blueprint. But the broader idea matters.

We do not have to preserve yesterday’s junior engineering role just because it produced yesterday’s senior engineers.

The role can evolve.

Engineers entering the field may spend less time writing routine implementation from scratch and more time understanding requirements, validating generated code, investigating failures, interacting with customers, reasoning about systems, and overseeing AI output.

Those are not consolation tasks left over after AI takes the “real” engineering work. Increasingly, they are the engineering work.

And the same shift is already happening further up the experience ladder.

As generating code gets easier, understanding what should be built, knowing whether an implementation belongs in the system, recognizing failure modes, and taking responsibility for production outcomes become more valuable.

The goal should not be to protect old workflows from AI. It should be to make sure the new workflows still produce engineers capable of judgment and ownership.

Hiring More Juniors Does Not Fix This

There is an important caveat to the pipeline argument.

Hiring more junior engineers does not automatically create more senior engineers.

You can hire twenty early career developers tomorrow, give them coding agents and a backlog, and reproduce the exact same problem.

An engineer who delegates every difficult problem is not necessarily learning from those problems. A team with no time for mentorship is still not mentoring. A role with no progression toward ownership is still a dead end.

And a senior engineer who increasingly delegates unfamiliar work without interrogating the result can fall into a version of the same trap.

The concern is not ultimately about age, title, or years of experience. It is about whether the engineering environment continues producing expertise.

We should also be careful not to overstate what the current research proves.

The Anthropic trial measured immediate comprehension of one unfamiliar library, not long term engineering ability. The Seoul National University research is based on 14 interviews. The Stanford figures describe employment trends rather than proving that AI caused them. A Stanford policy brief also noted that after additional controls were introduced, declines among entry level software workers were not notable until 2024, suggesting other forces may be involved.

There is still a lot we do not know.

But engineering organizations make decisions under uncertainty all the time.

You do not need perfect evidence that a dependency will fail before you decide whether the architecture is too dependent on it.

The same thinking applies here.

If AI is changing where engineers get experience, it is worth designing for that change before a talent shortage makes the consequences obvious.

Because rebuilding an engineering pipeline takes years, not months.

Final Thoughts: The Next Senior Engineer Is a Decision You Make Today

The first phase of AI adoption was about productivity. Give engineers the tools and see how much faster they go. We needed that phase.

But the next phase asks a longer question:

Who will be able to run, verify, and fix these systems in five years?

That does not mean AI failed. It means AI is changing how engineers are made, and that has to be designed with purpose.

The opportunity is bigger than making existing engineers faster. Used well, AI can help engineers explore unfamiliar systems, ask better questions, shorten feedback loops, and spend more time on the parts of software engineering that require judgment.

But that only works if we are deliberate about what we automate and what capabilities we still need people to develop.

If your output is rising while your bench is thinning, the answer probably is not to hire indiscriminately or to wait and hope.

It is to build the pipeline deliberately.

That is where Ardan Labs can help. Ardan Labs is a software engineering firm delivering training, consulting, staff augmentation, software development, and AI engineering in Go, Rust, Kubernetes, and AI.

Need experienced engineers now? Our Staff Augmentation service adds experienced engineers who integrate directly into your team and contribute from day one. That provides senior ownership while you develop capability internally, and it puts experienced engineers alongside the people who are still growing into greater ownership.

Want structured growth for your engineers? Our training programs offer live and self paced options for individuals and teams seeking production focused skills in Go, Rust, Kubernetes, and AI.

Adopting AI and want to do it right? Our AI Implementation Services bring systems level engineering into AI programs and deliver production ready solutions, whether you are implementing AI directly or developing the internal capability to build and operate it yourself.

Want your engineers working directly with AI systems? Our Private Ultimate AI Workshop is a hands on, full day experience for teams that want to understand modern AI systems inside their own infrastructure. Engineers build and run the systems themselves rather than only reviewing what an agent hands them.

The seniors you will need in five years are the engineers you choose to grow today.

AI Training That Builds the Skills Behind the Pipeline

If AI is changing how engineers learn, build, and work, training has to change with it too.

That is why Ardan Labs is expanding its Go training bundles to include practical AI training alongside core engineering skills.

Miki Tebeka's AI training is now available as part of our Go bundles, giving engineers a structured way to learn how to work with AI while continuing to build their Go development skills.

The focus is not simply on using AI tools. It is understanding how to build with them, question their output, and apply them effectively in real engineering work.

And this is just the beginning.

Bill Kennedy's AI training will be available soon, bringing the same production focused approach to AI that engineers have come to expect from Ardan Labs training.

The goal is simple: help engineers develop the skills they need for the systems they will be building tomorrow, not just the ones they are building today.

Because if AI is changing the engineering workflow, the path to engineering expertise has to evolve with it.

Explore the Go Bundle

Sources

• Stanford Digital Economy Lab, “Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence”
• Stanford Institute for Economic Policy Research, “What is really happening to jobs? Separating AI hype from reality”
• Communications of the ACM, “Redefining the Software Engineering Profession for AI” (March 5, 2026)
• Anthropic, “How AI assistance impacts the formation of coding skills”
• arXiv, “Who Will Become the Next Senior? How Generative AI Erodes the Development Pathway in Software Engineering”
• Axios, “IBM plans to triple entry-level hiring this year because of AI” (February 13, 2026)
• IBM, “The bottom rung returns as AI reshapes entry-level jobs”