There is a problem forming in technology organisations that nobody has to solve this quarter, which is precisely why it will be expensive.
The tasks that junior engineers and analysts traditionally cut their teeth on are the tasks that AI now does well. The first ticket, the small fix, the report nobody senior wanted to write. That work was never valuable in itself. It was valuable because it was how people learned the system, earned trust and built judgment.
Remove it without replacing it, and you have not just changed the entry-level job. You have interrupted the supply of people who become senior.
The ladder had rungs for a reason
Nobody designed the traditional progression deliberately. It emerged, and it worked for a specific reason: there was a large volume of low-stakes work that had to be done, and doing it was how you learned.
You read a lot of code before you were trusted to change much of it. You made small mistakes in places where small mistakes were survivable. You built a model of how the system fitted together, mostly by working on it in pieces.
That apprenticeship was invisible because it was a by-product of the work rather than a programme anyone ran.
Now the work is cheap and the by-product has gone with it. An organisation can meet this year's delivery targets with fewer junior people, and most will, because the alternative costs money now against a benefit that arrives in four years.
That is a rational decision for each company and a poor one for all of them together.
What the entry-level job becomes
The honest answer is that it becomes harder, not easier.
If producing a plausible implementation is no longer the skill, the remaining skills are framing the problem, directing the work, evaluating what comes back, and knowing when something is subtly wrong. Those are judgment skills, and judgment has historically been the thing people acquired last.
So the new entry-level job asks for the hardest part first. That is a real difficulty and pretending otherwise does not help.
It does, though, suggest what to build. If judgment can no longer be a by-product of volume, it has to become the explicit subject of the training.
What to put in place
Make reviewing the curriculum. The most valuable thing a junior person can do now is read work critically: generated code, generated analysis, a plan, a proposed architecture. Structure it. Give them real changes to assess, have someone senior review the review, and discuss the difference. This teaches the exact skill the job now requires, and it produces useful output from the first week.
Restore the small mistakes. People learn from consequences and the safe places to experience them have thinned out. Build them deliberately: realistic environments, scoped ownership of something real but not critical, incident participation as an observer before as a responder.
Teach the system, not the task. When nobody has to write the whole subsystem by hand, understanding has to be taught rather than absorbed. Architecture walkthroughs, incident reviews conducted as teaching, time explicitly allocated to reading the parts of the system someone does not work on.
Pair people with AI and with a person. AI-assisted apprenticeship can make someone productive much faster than the traditional route. What it cannot do is tell them whether what they produced was any good, or notice that their model of the system is subtly wrong. Both are needed, and dropping the human half because the machine half is cheaper is the obvious mistake.
Protect the time. Every organisation says it develops people and most discover, under delivery pressure, that development was the first thing to go. If it does not survive a difficult quarter, it is not a programme.
The leadership version of the same problem
This extends further up than most people plan for.
The scarce skills in an AI-native organisation are problem framing, taste, critical thinking, accountability and the ability to make sound decisions under uncertainty. Those are also the skills that distinguish good technology leaders, and they have always been developed through years of consequential decisions with visible outcomes.
If mid-level people spend less time making those decisions, the pipeline into senior roles thins as well, on a longer delay and with less warning.
A technology leadership team that is not deliberately creating decision-making opportunities for the level below it is consuming judgment it is not replacing.
Why this is worth doing anyway
The argument for building this properly is not only about supply.
Organisations that develop people well attract better ones, and the market for people who can direct AI and evaluate its output competently is going to be tight for a long time. Being a place where that capability is built, rather than only bought, is a durable advantage and a reasonably cheap one.
There is also a simpler reason, which is that it is worth doing. My work has never been only about systems. It is also about the people who build and inherit them, and the pathway into this profession is narrowing at exactly the moment the profession is becoming more interesting.
Human judgment becomes more valuable as execution becomes cheaper. That is an argument for developing more of it, not for assuming it will continue to appear on its own.