English | EN 
This is not a deeply technical article—just a reflection that came after a discussion with a colleague who wondered why we weren’t recruiting more juniors. His concern was simple: if we stop hiring and training juniors today, where will our experts come from ten years from now?
With the rapid evolution of AI capabilities, and the improving quality of answers generated by different prompts, AI is increasingly able to perform many of the simple tasks that used to be part of a developer’s everyday work. From creating boilerplate code and writing unit tests to generating commits and pull requests, all of these tasks now fall well within the scope of AI’s autonomy, requiring minimal human input once the configuration and initial trials are done.
When I started working in IT, these activities were usually assigned to juniors or the newest team members. They helped us build understanding, confidence, and autonomy on a project. Today, that model is fundamentally changing.
We are now at a crossroads:
Do we continue leveraging AI for these efficiency gains, or do we preserve some of these tasks for juniors so they can build the skills and experience that will eventually make them experts? If we choose to keep certain tasks for junior development, then we need to push AI toward handling more complex tasks. But that also reduces the pool of midlevel, “expert entry” tasks that senior developers used to perform on their way to mastery. We’re essentially shifting the same problem one level up.
So the balance becomes tricky. Automation eases the workload for senior engineers, freeing them to focus on highvalue work. But without a strong junior pipeline, we jeopardize the future renewal of our expert pool—people capable of independent thinking without relying solely on AI. We want our future experts to sit with a client and propose ideas and solutions confidently, not just prompt an agent to produce them. At the same time, we don’t want our current experts spending their days redesigning the same microservicebased Kubernetes cluster for the hundredth time.
Some might then ask: “Why not automate the lowlevel tasks with AI and let juniors learn from the results?”
My answer is this: a lowlevel task isn’t complete until a human reviews the output and says, “Yes, that’s what I expected.” The same is true when a junior completes a task—the senior only considers it done after reviewing the pull request. In both cases, the senior must be involved.
But there is a fundamental difference.
If AI performs the task, the junior is reduced to a reviewer with no influence on the outcome. They are not involved in the decisionmaking process, which means they are not truly learning.
When a junior performs the task themselves, they hold responsibility for the result. Yes, it may take longer, but they gain understanding through doing—not through validating someone else’s (or something else’s) output.
This brings us to the real question:
Is someone still an expert if they no longer have practical experience with the foundational tasks of their domain?
Or put differently:
Is expertise purely theoretical, or is it the combination of knowledge and handson ability?
Personally, I believe an expert should be able to talk about their subject and demonstrate or validate what they say. If we rely entirely on AI, we risk reaching a point where no one can challenge the results. Normally, that wouldn’t be a problem—if AI reasoned logically and independently. But today’s AI does not think. It generates results based on patterns and probabilities drawn from what it has learned. It can simulate novel solutions, but they remain rearrangements of existing ideas.
AI agents are fantastic tools for automating workflows, validating ideas, and assembling solutions from existing components. But their users must remain critical thinkers. And for that, those users must themselves be experts—capable of detecting faulty outputs or unrealistic proposals.
In a follow-up post, I’ll share my vision for how to maintain a strong junior pipeline while still benefiting from AI automation, along with a few practical examples.