Over the last few months, I started using GitHub Copilot for work. It took me quite some time (and a lot of tokens) to learn to use it properly. But once I knew what I was doing, it at least 10x'ed my work.
Until this day, I am surprised how well and fast AI models like ChatGPT or Claude can:
- Scaffold CRUD endpoints
- Generate unit tests
- Refactor straightforward code
- Debug simple errors
- Document APIs or services
- Explain unfamiliar code
With the help of AI, I feel way more productive and efficient than before.
Today, many senior engineers delegate these tasks to GitHub Copilot. And honestly, in many cases that actually IS the more efficient choice. But, if AI is increasingly becoming better at execution-heavy development tasks, what exactly are junior developers supposed to learn from?
Which creates an uncomfortable question: If junior developers stop doing this work, where exactly do future senior engineers come from?
Most Engineers Learn Through “Low-Value” Work
Throughout my career, I was able to work with a lot of very smart and very capable software engineers. And there is one thing they all had in common: they didn't become experienced by reading architecture diagrams or attending conference talks. They became experienced by spending years dealing with messy code, repetitive tasks, flaky tests, deployment mistakes, and occasionally even frustrating work. They all gained experience by working with real software systems.
A lot of this mentioned frustrating work early in my career was actually building a foundation:
Fixing bugs:
While I was fixing bugs, I was not just solving individual issues. I was slowly building debugging instincts. Over time, I stopped focusing on the specific problem in front of me and started learning how to investigate systems that didn't behave the way they were supposed to.
Dealing with flaky tests:
Flaky tests taught me more about reliability than many books or conference talks ever could. Every time a test failed for no apparent reason, I learned a little more about reliability. Eventually, I started recognizing how seemingly harmless decisions can slowly erode confidence in a system.
Maintaining "legacy" services:
A huge amount of my understanding of software architecture came from maintenance work. Reading old code, following dependency chains, and figuring out why a workaround existed taught me far more than architecture diagrams ever did.
Most of this work looks low-value from the outside because it is difficult to measure. It does not always produce visible features. It is often slow, repetitive, and operational in nature. But it's exactly where software engineers develop essential skills like:
- pattern recognition
- risk awareness
- debugging intuition
- systems thinking
- operational judgment
Traditionally, juniors learned through an apprenticeship-like process inside engineering teams working on exactly those tasks with guidance from seniors. But this pipeline seems to change. Which brings us back to the question from before:
If AI absorbs all of this work, organizations may accidentally remove the environments where engineers develop those skills.
And if that happens, where do future senior engineers come from?
Senior Engineers Are Produced, Not Hired
When discussing AI and productivity, many people focus on the individual developer. How much faster can they ship? How many tickets can they close? How much code can they generate?
But there is a bigger organizational question hiding underneath all of this: Where do senior engineers actually come from?
When scrolling through my LinkedIn, I see a lot of open positions for senior software engineers. Companies seem to assume that senior engineers can simply be hired when needed. But, if every company wants to hire senior engineers, who is producing them?
In my opinion, every engineering organization should depend on internal talent growth. Because senior engineers are far more than simply better coders. They are engineers who have accumulated instincts and habits over many years of dealing with all the complexity that comes with real-world software development.
Today's senior engineers were yesterday's juniors. They are developed over time. And if engineering organizations start removing those learning opportunities, they are unintentionally weakening the system that produces their future technical leaders.
AI May Create Fragile Engineering Organizations
What makes this whole evolution dangerous is that the impact may not be visible immediately.
If a company starts using AI to handle more junior-level work, productivity might even improve in the short term. Features get delivered faster. Less time is spent on repetitive tasks. Engineers can focus on more complex problems.
At first glance, that sounds like a win. The problem is not the AI-generated code itself. The problem is what happens to the human systems around it.
If fewer engineers spend time debugging difficult issues, maintaining older systems, or investigating production incidents, fewer engineers develop a deep understanding of how those systems actually work.
Over time, organizations may find themselves in a situation where only a small group of experienced engineers understands the critical parts of the system. And this creates a subtle form of organizational fragility.
The codebase continues to grow. Development speed keeps increasing. AI makes engineers more productive than ever before. But at the same time, the number of people capable of understanding and handling that growing complexity may actually decrease.
And here is where it becomes interesting. AI makes it easier and faster to produce software. But it does not make it easier and faster to verify and validate it. The faster code gets generated, the more important verification and judgment become.
Every generated pull request still needs to be reviewed. Every deployment still needs to be validated. Every production issue still needs to be understood. Every architectural decision still needs critical thinking. And AI cannot fully evaluate those decisions within the broader context of an organization.
In other words, AI may reduce the amount of coding required to ship software. But it may increase the importance of engineering judgment, systems thinking, testing, review processes, and quality engineering.
And if those skills become concentrated in a small group of senior engineers, they eventually become a bottleneck for the entire organization.
The Best Teams Use AI Differently
After reading all of this, it might sound like I am arguing against AI. Well, I am not.
The question is not whether repetitive work should be automated. The question is how organizations can preserve the learning opportunities hidden inside that work.
In my opinion, the best engineering teams will use AI very differently. Instead of replacing apprenticeship, they will redesign it.
Junior engineers should still spend time debugging production issues, investigating flaky tests, maintaining existing systems and learning how software behaves under real-world conditions.
The difference is that AI can help them do those things more efficiently and learn faster.
Instead of spending hours searching documentation, they can spend more time understanding the actual problem. Instead of being completely stuck, they can get guidance and continue learning.
In other words, AI can reduce friction without removing exposure.
The same is true for senior engineers. Their role becomes less about writing every line of code themselves and more about reviewing, mentoring, and helping others develop engineering judgment.
Because the goal is not to protect junior work. The goal is to protect the pipeline that turns today's juniors into tomorrow's senior engineers.
Top comments (0)