A lot of AI adoption language is built around removing low-value work. Draft the first version faster. Summarize the call. Clean the spreadsheet. Prepare the research notes. Produce the basic copy. In isolation, this sounds almost impossible to argue with. Nobody should defend pointless friction just because it is familiar. But there is a small problem hidden inside that sentence: some work looks low-value only when it is done by someone who already understands why it matters.
Routine work is not always wasted work
Repetitive tasks are often where beginners learn pattern recognition. A junior marketer learns by rewriting clumsy claims until the difference between noise and positioning becomes visible. A young product person learns by reading support tickets that look boring until the fifth ticket contradicts the first four. Someone early in a career learns how a business actually behaves by touching work that more experienced people can process almost automatically. From the outside, this may look like administration. From the inside, it is often how apprenticeship happens.
This does not mean every manual task has educational value. Some work is simply bad process with a polite name. Copying data between systems, chasing approvals that nobody reads, rebuilding the same slide because the organization cannot decide what it wants to know: there is no virtue in preserving that. The distinction matters because the current conversation tends to flatten both categories into one convenient phrase: low-value work. It is a clean phrase, but it hides the question that matters: low-value for whom, and at which stage of competence?
Productivity can hide a broken apprenticeship
When an experienced person uses AI, the tool often compresses execution. They already have taste, context, and enough skepticism to notice when the output is too smooth, too generic, or directionally wrong. The model saves time because the human still owns the frame. When a beginner uses the same tool, the situation is different. The output may look more mature than their judgment. That is useful in some contexts, but it also creates a strange educational risk: the person can skip the struggle before they have developed the internal standard that makes the shortcut safe.
This is where organizations can fool themselves. The deck is cleaner. The summary is faster. The first draft is less embarrassing. A manager sees cycle time going down and concludes that adoption is working. Maybe it is. But the missing variable is not visible in the dashboard. Did the person learn what they would have learned by doing the messy version first? Did they notice the tradeoffs? Did they understand why one customer quote matters and another one is just noise? If not, the organization may be exchanging visible productivity for a future skill gap.
The hard part is deciding what should stay slow
I do not think the answer is to protect junior work as a museum of old inefficiency. That would be sentimental and unhelpful. The sensible question is narrower: which parts of the work create judgment because they force contact with reality? Reading raw customer complaints may be slow, but it teaches a different thing than reading a summary. Writing a first positioning memo from scratch may be painful, but it exposes whether someone understands the market or only repeats vocabulary. Debugging an edge case may feel inefficient, but it shows how a system behaves under pressure.
Slow is not automatically better. Slow without feedback is just waste with better branding. But some forms of slowness carry information. They reveal assumptions, missing context, and weak mental models. If AI removes that friction too early, the organization does not only remove labor. It removes a learning mechanism.
This becomes a management problem
Entry-level roles were already awkward before AI. Companies wanted people who were cheap enough to learn, but competent enough not to require much teaching. That contradiction was always there. AI makes it easier to pretend the contradiction has been solved. A senior person with good tools can produce more, so the company needs fewer beginners. In the short term, that can be rational. In the long term, it raises an uncomfortable question: where will the next layer of senior people come from?
There is no conspiracy here. It is just an incentive problem. Every company can decide that training juniors is expensive and let someone else carry the cost. But if enough companies do that, everyone later complains that there are not enough people with judgment, ownership, and context. The market does not magically produce experienced people. Someone paid for their inefficient learning earlier, often without naming it that way.
A better question than replacement
The question is not whether AI should replace junior tasks. That framing is too crude. A better question is sequence. What should a person attempt before AI helps? Where should AI act as a reviewer rather than a substitute? Which tasks can be automated after someone has understood the pattern manually? Where is the learning in the work, and how do we avoid destroying it while improving the process?
That requires more managerial attention than buying tools and counting usage. It means designing learning loops deliberately: first attempt, model critique, human review, second attempt, reflection. It means asking not only whether the output is acceptable, but whether the person is becoming more capable. That is a slower metric, but a more honest one.
The practical answer is that companies need to preserve the distinction between efficiency and development. Some work deserves automation. Some work deserves redesign. Some work deserves temporary protection because it creates future judgment. The difficult part is not classifying tasks once and moving on. It is staying awake to the fact that people are not born senior. They become senior through contact with work that often looks inefficient from a quarterly dashboard. That is enough to make me careful with any adoption story that treats entry-level work as waste.