Somebody left a comment on Reddit recently that has been circulating because it says something uncomfortable in very few words. The gist: industries are about to discover that they destroyed the pipeline that manufactures senior experts.
The argument runs like this. AI removes the boring junior work. The boring junior work is also the work that makes people good at their jobs. You do not become a skilled engineer by reading books. You become one by writing bad code, breaking things, debugging them, reading other people’s code, arguing with people who know more than you, and slowly assembling an internal model of how the system actually behaves. Take that away and, ten or fifteen years later, the people who genuinely understand things become rare.
It is a good comment. It is also, almost line for line, an argument that people have been making since the first power looms, which does not make it wrong. It makes it worth checking against the record, because we have now run this experiment four or five times and we know some things about how it goes.
The apprenticeship was a machine for making experts
Before industrialization, apprenticeship was not a nice extra attached to work. It was how expertise physically reproduced itself. A beginner stood next to experienced craftspeople, did simple real work, got corrected, did harder real work, became a journeyman, and eventually, sometimes, a master. The economics and the pedagogy were the same activity. Nobody had to fund the training separately, because the training was indistinguishable from the output.
That arrangement started coming apart in the early 1800s. Factories replaced skilled craft production with machines run by partially trained workers, and the Department of Labor’s own retrospective on registered apprenticeship describes traditional apprenticeship deteriorating in exactly that period, as employers moved toward cheaper labor and machinery that demanded less craft skill.
So the shape of the problem was already visible two centuries ago, and it has a very particular structure. The old system was a sequence: novice, easy real work, mistakes, feedback, harder work, expert. The new technology absorbs the easy real work. Fewer novices get hired. Experienced people supervise machines instead. For a while, this looks fantastic. Output per worker goes up, costs go down, and nothing appears to have been lost.
The bill arrives later, and it arrives as a question: where does the next cohort of experienced people come from?
Fig. 01Where the entry point went, 1780 to 2030
Scroll to run the clock
Each wave of automation absorbed work from the bottom of a ladder and left the top intact. The rungs do not disappear from the job; they disappear from the hiring. What moves is the lowest rung a person can be hired onto, and it has only ever moved in one direction. Positions are schematic, not a data series.
Taylor made the split official
The nineteenth-century version of this was mostly implicit. Machinery encoded pieces of what skilled workers used to know, and a process that once needed one trained craftsperson could be decomposed into narrower jobs. The productivity gains were enormous. So was the worry, which we would now call deskilling: a worker could operate one piece of a process competently without ever understanding the whole.
Around 1900, Frederick Winslow Taylor turned that into a management doctrine. Scientific management explicitly separated thinking about the work from performing the work. Engineers studied a job, decomposed it into steps, and told workers precisely how to execute those steps. This was genuinely powerful, because expertise could now live partly outside of workers’ heads, in procedures, measurements, and management systems, where it could be copied.
The tradeoff was obvious even at the time. Spend twenty years executing tightly specified procedures and you may become extremely proficient at those procedures without ever developing the mental model that someone who had to solve the underlying problem would have built. In 1974, Harry Braverman’s Labor and Monopoly Capital made the systematic version of this argument: modern industrial organization transfers knowledge and control out of workers and into management and machinery. Most of today’s deskilling literature descends from it.
Notice what is actually being moved in both cases. Not effort. Judgment.
Then computers did it again, and the effect got subtle
From roughly the 1960s through the 1990s, computers automated an enormous volume of clerical and routine professional work. Bookkeeping is the cleanest example, because you can hold both versions of the job in your head at once.
Picture a junior accountant in 1960. They spend a great deal of time reconciling ledgers by hand, checking arithmetic, tracing transactions through books, finding discrepancies, and slowly learning what the various accounts actually represent. Spreadsheets and accounting software removed almost all of that labor, which was, on balance, wonderful. Nobody should reconcile ten thousand transactions by hand to preserve the character-building properties of the exercise.
But something changes underneath, and it is not the thing people usually name. The 1960 clerk who reconciled ten thousand transactions encountered a few hundred strange ones along the way, mostly by accident. The modern one, whose software reconciles 9,950 of them, sees fifty exceptions. The second worker is dramatically more productive. They are also learning from a completely different distribution.
That is the part worth staring at. The exceptions are the educational part, so on one reading the modern junior gets a denser curriculum. But they only ever see cases the software already flagged, they never build the background sense of what normal looks like, and they have no idea how the routine 9,950 got resolved. The same transformation ran through manufacturing with CNC machines, aviation with flight automation, medicine with diagnostic systems, and finance with computerized trading.
Fig. 02One year of casework, as automation absorbs the routine
Scroll to raise the automation threshold
Each tick is a case, sorted by how unusual it is. Automation takes them from the easy end first, so what is left in human hands is not a smaller sample of the same work. It is a different distribution: far fewer reps, far higher average difficulty, and no exposure at all to what ordinary looks like. Illustrative model, not measured data.
Nobody calls a junior engineer an apprentice
Meanwhile, the formal institution kept shrinking in the places it used to dominate. The Department of Labor’s retrospective puts one number on it that is hard to forget: in 1979, about 37 percent of U.S. registered apprentices were in manufacturing; by 2007, manufacturing accounted for roughly 6 percent.
Registered apprenticeship did not die, and in the trades it has grown substantially in recent years. But professional knowledge work never built apprenticeship institutions at anything like that scale. Instead it built an informal one and declined to name it.
- Junior analyst, analyst, senior analyst, manager.
- Junior developer, developer, senior engineer, staff or principal.
That is an apprenticeship with the label filed off. Nobody calls a junior software engineer an apprentice, but functionally that is frequently what they are: someone paid a real salary while encountering thousands of problems that gradually assemble a working model of a system. The company thinks it is buying labor. It is also, without putting it on any ledger, running a training program.
Which is precisely why it is so easy to cut. A line item nobody records is a line item nobody defends.
Offshoring gave us a preview of what that costs. From the 1990s onward, firms discovered that a lot of routine junior knowledge work could be done somewhere cheaper. Imagine a consulting practice with twenty analysts, six managers, and two partners. Move most of the analyst grunt work offshore and you now have five analysts plus a vendor, six managers, and two partners, at a considerable saving. Ten years later the firm notices that the original twenty analysts were also the pool the six managers had been selected from. This has a name in the literature: the talent pipeline problem.
Is it actually happening, or does it just sound true?
This is where the argument usually stops being interesting, because the historical pattern is so satisfying that people forget to check whether the present matches it. As of 2026, the first half of the Reddit comment has unusually good empirical support. The second half does not, and cannot yet, because the thing it predicts would take another decade to show up.
Here is what the on-ramp actually looks like right now.
- −65%
- Entry-level and new-grad hiring at major tech companies versus 2019, with early-stage startups down about 76 percent. Over the same period, overall engineering hiring at those companies is down only about 11 percent, and at early-stage startups it is up about 7 percent.SignalFire, State of Talent Report 2026
- 71%
- Share of the increase in U.S. software development postings between May 2025 and May 2026 that came from senior roles. Postings rebounded; the rebound was not evenly distributed.Indeed Hiring Lab
- −12%
- Regression-adjusted employment of 22 to 24 year olds in the most AI-exposed industries over the ten quarters after ChatGPT’s release, driven mainly by firms sharply reducing hiring of young workers rather than by firing older ones.U.S. Census Bureau working paper, CES-WP-26-27
- 45%
- How much less likely recent graduates from top U.S. computer science programs were to enter an engineering job at a major tech company, compared with a few years earlier.SignalFire, State of Talent Report 2026
That is about as close to the predicted shape as labor data ever gets: the on-ramp contracts sharply while demand for people who already have the skill holds up or grows. Indeed’s analysts have been explicit that the composition is shifting toward experienced, AI-fluent workers rather than that software is dying, and that the market is tilting toward seniority generally.
And now the caveat, which matters more than the headline. You cannot read causation off that chart. Tech overhired enormously during the era of near-zero interest rates. Rates rose. Venture funding changed shape. Layoffs put an unusually large pool of experienced engineers into the market at the same time. Remote work changed how firms train people. AI arrived in the middle of all of it. Overall hiring at major tech companies remains well below its 2019 baseline, so some of this is simply a smaller industry buying fewer of everything and buying juniors last.
The honest summary has three tiers. Very strong evidence: the junior pipeline in technology has contracted enormously. Growing evidence: employers are shifting toward experienced workers and asking entry-level candidates to demonstrate more. Suggestive but unproven: generative AI is one of the causes, which is plausible mostly because it performs exactly the routine coding and debugging that apprentices were historically handed. Not demonstrated at all: that this produces a shortage of senior engineers in the 2030s.
That last one is not a technicality. It is the entire disagreement, and there is a serious argument on the other side.
The other hypothesis: the same tool, run backwards
The pessimistic model assumes less manual work means less experience means less expertise. But experience is only worth anything insofar as it changes the learner’s internal model. A person can write CRUD endpoints for eight years and accumulate eight years of employment without accumulating eight years of architectural understanding. Years are a proxy we use because we never had anything better.
If you unpack the proxy, expertise looks closer to a product of four things: useful learning iterations, quality of feedback, difficulty, and diversity of situations. Traditional apprenticeship is generous with the first and wildly inconsistent with the other three, because it delivers whatever happened to walk through the door. AI can, in principle, raise all four at once.
The distinction that decides everything is whether AI replaces the practice loop or compresses it. Most people use it the first way:
The second way is a deliberate apprenticeship engine, and it looks nothing like autocomplete:
Concretely: point an agent at a real architecture and have it walk you through each node, explaining what problem that node solves and why it exists, then have it ask you a question designed to find out whether you actually followed. Once you can narrate the system, flip the mode and have it attack you. Not quiz you. Attack you.
Say you claim you understand Kafka. A good adversarial tutor does not accept the claim. It says: you have three consumers, consumer two crashes after processing a message but before committing the offset, what happens? Then: now do exactly-once semantics. Then: now explain why exactly-once does not literally mean every operation happens once. Then: design the system without Kafka. Somewhere in that sequence it finds the exact point where your model stops working, which is the only place learning was available.
This is the part traditional mentorship structurally cannot do. A senior engineer cannot spend three hours a day continuously diagnosing one junior’s mental model, because they have their own work. An agent can, and it never gets bored of asking the follow-up question.
Fig. 03Finding the weak spots: accident versus search
Scroll to spend the same budget of probes on both
Think of competence as a map with soft cells. Both sides get the same number of attempts. On the left, experience hits cells at random, which is what a career does. On the right, a tutor that can test you goes at the softest cell it can find, every time. The left panel is not lazy. It is just untargeted, and untargeted search on a large map leaves holes.
Manufactured experience, and its honest limits
There is a second advantage that I think is larger than the first, and it is about variance rather than speed.
Traditional apprenticeship is hostage to what happens to you. Work on a monolith for five years and you become very good at that monolith. You may never once encounter distributed consensus, event sourcing, high-volume streaming, multi-region failover, or a genuinely nasty concurrency bug. Not because you were incurious, but because your employer never had those problems.
An agent can manufacture the encounter. Your payment system handles fifty transactions per second; tomorrow it needs fifty thousand, redesign it. Now the database is intermittently unavailable. Now two regions lose connectivity. Now messages are being duplicated. Now your retry logic has caused a retry storm. You can walk through twenty architectural disasters in an afternoon that might otherwise take a decade to meet organically, and each one leaves a real dent in your model.
I want to be careful here, because there is a reason this is not a complete substitute. Simulated experience is not the same as being responsible for a production outage at two in the morning with people waiting on you. Real consequences build instincts that exercises do not fully reproduce, and anyone who has been on both sides of that knows the difference immediately. What simulation does is raise the density of learning, not replace the part of expertise that comes from having something at stake.
The other thing an agent can do, which mentors mostly cannot, is force transfer. You learn backpressure in a message queue. Fine. Now backpressure in an HTTP service. Now in a streaming pipeline. Now in a factory. Now in a team of people. If you can recognize the same structure in an unfamiliar domain, you have acquired the abstraction rather than memorized an example, and that is the difference between someone who knows a stack and someone who can learn the next one quickly.
The one failure mode that decides it
None of the above happens automatically, and the failure mode is not subtle. It is cognitive outsourcing, and it takes about four seconds.
The agent asks why this queue needs to be here. You say: just tell me. You have now destroyed essentially all of the learning value of the exchange, and you will feel productive while doing it, because you got an answer and the answer was correct.
Which is why a system built for this should refuse. Give me your hypothesis first. How confident are you? Now here is the case your hypothesis does not cover. Only after you have committed to a model does it explain, because a model you committed to is a model that can be corrected, and a model you never formed cannot be.
Two people can use exactly the same AI system for two years. One becomes dramatically more capable. The other becomes progressively less able to work without it. That divergence is not a property of the tool.
I think that ends up being one of the real dividing lines of this era, and it is uncomfortable because it is mostly a matter of individual willingness to stay in difficulty when an exit is one keystroke away. The bottleneck is no longer access to information. It is whether a person will repeatedly choose to be confused for twenty minutes when the machine will happily remove the confusion for them.
It is worth saying plainly that this is not only an individual virtue problem. If a company rewards shipped output and never once asks whether the person who shipped it could debug it, it has chosen the second outcome for everybody it employs.
What a replacement pipeline would actually have to do
If the goal is to avoid the bad version, the move is not to preserve boring work because it is boring. It is to preserve the learning functions that boring work used to perform, which is a different and much more tractable problem. Five parts:
- Keep deliberate apprenticeship roles. Hire juniors even where AI could technically cover the work, and define the job as partly production and partly structured skill acquisition. A residency, not a cheap coder.
- Require human reasoning before AI answers. For architecture, debugging, incident response, security, and data modeling, the junior predicts, explains, or diagnoses first. The AI is a coach after the attempt, not a vending machine before it.
- Track an explicit competency graph. Promote on demonstrated ability to reason about service boundaries, transactions, failure modes, observability, and performance, rather than on years served. The scores should come from adversarial testing, not from having had something explained to you.
- Manufacture the experience the job no longer supplies. If a junior will never meet five hundred mundane bugs, hand them realistic failures, broken systems, architecture tradeoffs, and incident simulations on purpose. Engineered experience replacing accidental experience.
- Protect real ownership. Eventually they need to own something that can actually fail. Explain this component, then design it, then operate it, then handle the incident when it breaks at two in the morning.
And the thing companies would have to start measuring is not the one they currently celebrate. “One senior engineer plus AI now does the work of five” is a real and impressive fact about this quarter. It is silent about next decade. The number that is not silent is how many independently capable engineers the organization produces per year, against how many it loses.
Call it the expertise reproduction rate. Above one, the expert base grows. At one, it holds. Below one, the organization is consuming institutional expertise faster than it makes it, and can do that profitably for years before anything visible breaks.
ModelThe expertise reproduction rate
Retirement, promotion out of the craft, burnout, and competitors. All three of these are numbers an organization could measure about itself this quarter, and almost none of them do.
Taken on30
Reach proven competence20
Leaving the expert pool20
Every value here is yours, not a published figure. That is the point: an organization can compute this about itself in an afternoon, and the reason almost nobody does is that the denominator was never anyone’s responsibility.
Turn the middle dial and watch what it does. At a high enough training quality, a much smaller intake still holds the line, which is the compressed-apprenticeship hypothesis expressed as arithmetic. At a low enough one, no plausible intake saves you, which is the pipeline-collapse hypothesis expressed the same way. Both futures live inside the same formula, and the variable that separates them is the one that AI could move in either direction.
Automate execution. Do not automate cognition.
The two hypotheses are not really in competition over whether the junior job is shrinking. It is shrinking; the 2026 data is not ambiguous about that. They are in competition over what happens to the people who are still hired.
If the old industry needed a hundred juniors to eventually yield twenty strong seniors, an AI-heavy industry might take on thirty apprentices, train them deliberately and much faster, and produce twenty anyway. Or it might take on thirty, let the machine do their thinking, and produce five people who genuinely understand what they ship. Nothing about the technology chooses between those. Institutional design does, and so does what each of those thirty people decides to do on an ordinary Tuesday.
So the thing to prevent is not falling junior headcount by itself. It is falling junior headcount without a compensating rise in the rate at which the remaining juniors become genuinely capable. Those are different problems and they take different medicine. The first is a hiring question. The second is a design question, and nobody currently owns it.
Some institutions are at least looking. The OECD published a 2026 report on developing vocational education and training with AI, examining how AI is starting to reshape curricula, qualifications, and occupational standards rather than merely absorbing tasks. That is the right question being asked in the right decade, which is not always how this goes.
If I had to compress the whole argument into one operating rule, it would be this: automate execution aggressively, and do not automate cognition. If the AI writes the migration, the junior should still be able to say why it is safe, what could fail, how the rollback works, which invariants must hold, and how they would diagnose a bad deployment at three in the morning. Ship the output. Keep the understanding.
A mature engineering organization in this era will end up asking five questions about every person it employs, and they are not hard questions. Can they explain it? Can they predict how it fails? Can they modify it without the AI? Can they debug it when the AI’s diagnosis is wrong? Can they carry the principle into a situation nobody has seen before?
Answer yes and the machine is accelerating expertise. Answer no and it is manufacturing dependency, on exactly the same subscription, with exactly the same interface.
The risk was never inherent to the technology. The risk is deploying it purely as a labor-replacement tool and never once asking it to also be an expertise-production tool, which it is unusually well suited to be. The bench in the film is still lit. Somebody has to decide to stand at it.
