When I started my career on a support desk, I dealt with failed logins, missing permissions and recurring system errors every day. The work was repetitive, but repetition taught me to spot patterns, test assumptions and look beyond the symptom a user reported. Over time, I was resolving around 90% of incidents at first contact. That experience still shapes how I approach infrastructure work. As AI takes on more of these routine tasks, I worry about how the next generation of engineers will develop the same judgement.
That kind of repetition is becoming harder for early-career engineers to get. AI tools are already embedded in software development, with 84% of developers surveyed by Stack Overflow saying they use or plan to use them, while 51% of professional developers use them daily. SignalFire’s 2026 State of Tech Talent report found that entry-level hiring has fallen roughly 65% at major technology companies and 76% at early-stage startups compared with 2019. AI is increasing productivity at the same time that the traditional entry point into engineering is narrowing, making the training built into junior work increasingly important.
The Apprenticeship Hidden Inside Routine Work
Some of the most valuable lessons in my early roles came through work that looked highly repetitive from the outside. I handled joiner, leaver and mover access administration, investigated recurring permission failures and worked with developers when the same issues kept returning. I encountered former employees whose access had not been fully removed, role changes where permissions had only been partially updated, and new starters who were missing access because part of the process lived in undocumented knowledge. Treating each incident as an isolated ticket only delayed the next occurrence. Root-cause analysis, process fixes, knowledge-base documentation and runbooks helped remove whole categories of failure. The ticket queue was a training ground disguised as a cost centre.
Dealing with those problems repeatedly taught me the importance of structured fault diagnosis. When I coach colleagues, I see the difference most clearly when an infrastructure issue has no obvious answer. One engineer will work through the error systematically, rule out possible causes and build an explanation from the evidence. Another may paste the error into an AI assistant, receive a plausible fix, apply it and then become stuck when the fix fails. AI can accelerate the first attempt, but recovering when that attempt is wrong still depends on having a mental model of the system. Stack Overflow’s 2025 survey found that 46% of developers distrust the accuracy of AI output, compared with 33% who trust it, while 66% say their biggest frustration is receiving AI solutions that are almost right but not quite.
When the Training Ground Disappears
Businesses need to be careful about treating every automatable junior task as work that can simply be removed. A repetitive task can still be where an engineer learns to diagnose unfamiliar problems. If AI resolves routine tickets in seconds, companies need to create other opportunities for junior engineers to investigate failures from start to finish. That could mean reviewing AI-generated fixes, explaining why a recommendation makes sense, testing alternative causes, or giving them ownership after AI completes first-pass triage. Even when AI handles the first pass, a junior engineer should still get the opportunity to take an incident from diagnosis through to resolution. DORA’s research shows that 90% of technology professionals now use AI at work and more than 80% believe it has increased their productivity, while time saved during creation is often reallocated to auditing and verification. That verification work is part of the apprenticeship too.
Over the next five or ten years, we could end up with a workforce that is extremely fast at directing AI but has had fewer opportunities to develop independent technical judgement. Companies could have engineers who are highly capable with AI systems but less comfortable when a production problem falls outside a familiar pattern. That judgement comes from exposure to real failures, including the frustrating ones where the first diagnosis is wrong. If companies remove those experiences from junior roles, they will eventually feel the gap further up the organisation.
I think back to that early support desk because the value of those tickets was easy to miss at the time, even though they taught me how to approach unfamiliar technical problems. AI should remove unnecessary friction from engineering work and give teams more leverage. Companies therefore need to think carefully about what those saved hours mean for junior engineers who would previously have spent them diagnosing routine problems. The engineers who matter most in an AI-heavy environment will use these tools quickly and still understand what to do when the tool is wrong. Building that judgement means making sure junior engineers continue to get enough real problems to investigate and solve.
