What else did the work do?
There's an argument about AI and junior jobs that I think is broadly right, but perhaps for slightly the wrong reason.
AI is getting particularly good at work we've traditionally given to people near the beginning of their careers. First drafts, basic research, document review, comparison, summarisation, analysis. In
software engineering, it's writing the relatively straightforward code, fixing bugs, writing tests and working through a backlog of smaller changes.
The obvious concern is what happens to the career ladder. If organisations need fewer junior people because AI can do more junior work, eventually we have fewer experienced people too.
I think that's a real problem, but there's a slightly different version of it that interests me more. I'm not convinced all that junior work was actually a particularly good training system.
Take a junior lawyer reviewing hundreds of contracts during due diligence. After enough of them, they'll start recognising patterns.
They'll know what normally appears in a particular clause, what looks slightly unusual and what deserves escalating. Over time, some of that becomes almost instinctive.
We tend to call the result judgement.
It's tempting, then, to draw a fairly straight line from junior work, to experience, to judgement, and conclude that removing the junior work means removing the mechanism through which people become experienced.
There's obviously something in that. It does however also gives the old system more credit than it probably deserves.
Nobody sat down and decided that reviewing 300 contracts was the optimal educational programme for developing a lawyer. There were 300 contracts
that needed reviewing and somebody needed to do it. The same is true in engineering. Nobody decided that spending your first few years fixing relatively simple bugs and building CRUD applications was the perfect route to becoming a good software architect Those things needed building and fixing.
People learnt while producing something useful.
Sometimes they learnt because of the repetition. Sometimes because someone more experienced explained why they'd got something wrong. Sometimes because they encountered an unusual situation and remembered it, though I'm sure plenty of people developed good judgement in spite of some fairly poor junior work rather than because of it.
So I don't think the answer is to preserve inefficient work because that's how previous generations learnt, however I do think we need to understand what we're removing.
The work produced more than the output
When we look at a process for automation, we tend to define it by its obvious output.
Contract review produces extracted clauses, identified issues and eventually a diligence report. Research produces an answer supported by sources. Drafting produces a document. A developer ticket produces working code.
If an AI system can produce that output faster, more cheaply and at sufficient quality, then there's a perfectly reasonable case for changing the process.
The problem is that the stated output may not have been the only thing the process produced.
The junior reviewing those contracts was being exposed to variation. They were building a sense of what normal looked like and, eventually, what didn't. They were making decisions before knowing whether they were right, seeing which issues senior lawyers cared about, learning that something could be legally interesting without being commercially important and working out when they needed to ask for help.
The junior developer fixing bugs was learning how a production system
actually behaves. They were discovering that the elegant solution isn't always the maintainable one, that requirements are often incomplete and that apparently tiny changes can have consequences somewhere completely unexpected. They were reading other people's code, breaking things, debugging their own assumptions and gradually building a mental model of a system rather than simply learning a programming language.
None of those things appear in the process specification. They aren't the deliverable, but they're still outputs of the work.
Which gives me a question I think we should be asking much more often
when introducing AI:
What else did the work do?
"We'll train people differently"
The obvious answer is that we can replace incidental learning with better, more deliberate training.
I suspect that's true.
A junior lawyer might learn more from reviewing 30 carefully selected
contracts than from mechanically working through 300 largely repetitive
ones, particularly if those 30 expose them to meaningful variation and
somebody experienced actually discusses their decisions with them.
We could deliberately include near misses, ambiguous clauses and unusual
situations, or we could ask someone to make their own assessment before
showing them what the AI thought. We could give them an AI answer based on a superseded authority, or one that's technically correct but completely misses what matters to the client. Instead of waiting years for someone to encounter particular situations naturally, we could deliberately expose them to them.
Engineering could do much the same thing. If AI is going to write more of the straightforward code, perhaps junior developers should spend more time investigating failures, tracing systems, reviewing generated code and understanding why one architectural choice behaves differently from another.
We could probably expose somebody to a much richer set of engineering problems than they'd encounter by spending six months implementing similar API endpoints.
That might genuinely be better, though if you think about it something important has changed.
The 300 contracts needed reviewing, the 30 training contracts don't.
We've separated learning from production.
Under the old model, however imperfectly, the client needed the work,
the firm needed somebody to do it and the junior needed experience. The same activity satisfied all three to some degree.
Once AI does the productive part, somebody has to pay for the learning
explicitly. Someone needs to select the examples and, more importantly, experienced people need to spend time discussing decisions and giving useful feedback. The junior is now spending time on an activity that might have considerable developmental value but doesn't necessarily produce anything a client needs.
That's a different economic model for professional development.
So I think "we'll train people differently" is probably correct, but it's not a complete answer. Firms will have to accept that producing excellent experienced people becomes a more explicit investment rather than something that happens partly as a side effect of servicing clients or shipping software.
Real work has another property
There's another reason I don't think we can solve this entirely with better training.
We can recreate examples, I'm less sure we can completely recreate consequences.
Real work is messy in ways training exercises struggle to reproduce. The
document might be out of date, the client's email might contradict the
original instructions, two perfectly credible sources might disagree or
the apparently important legal issue might turn out not to matter very
much commercially. Sometimes you need to give an answer before you're
entirely comfortable doing so.
Engineering has exactly the same problem. A coding exercise can teach
you how to implement something. It's much harder to reproduce the experience of making a change to a system people are actually using,
discovering that your assumptions were wrong and having to work out what
to do next.
Responsibility changes how you think.
Somewhere in all of that mess people learn one of the most useful professional skills: recognising when something doesn't feel right even if they can't immediately explain why.
That's difficult to put into a training course because it's partly the result of seeing enough real situations to have developed an expectation of what normal looks like.
So I don't think the future can simply be AI doing the real work while inexperienced humans learn somewhere else.
We need to think about what role they're playing in the real work.
Reviewing AI isn't automatically the answer
One obvious response is that junior professionals will increasingly review AI output rather than produce the first version themselves.
Maybe... however I think we need to be careful here.
Imagine you've never drafted a particular document yourself. An AI
produces one in seconds. It's well structured, professionally written and almost entirely correct. Buried somewhere inside it is one consequential mistake.
You're now expected to find it.
That's actually much harder than producing the first draft yourself, since you're starting from the model's answer, which means you've already been anchored on one interpretation of the problem.
Engineering faces the same issue with generated code. Reading code and
deciding whether it will behave correctly isn't the same skill as producing it, particularly when the generated code looks completely plausible. A developer can approve a lot of perfectly reasonable-looking code without developing a deep understanding of why the system works.
This creates a circular dependency that I think deserves much much more
attention:
- AI does the work because humans can review it.
- Humans develop the judgement required to review it through experience
of the work. - Humans get less experience of the work because AI does it.
So where does the capable reviewer eventually come from?
We spend a lot of time talking about putting humans in the loop and we
should probably spend more time asking how those humans become qualified
to be there.
Map the work twice
I think there's a fairly practical way to start dealing with this.
When we're considering automating professional work, we should map the
process twice.
The first map is the one we'd normally make: what happens today, what
goes in, what comes out, where AI can perform the work, where humans
need to intervene and what happens when something goes wrong.
Then make a second map:
What does somebody currently learn by doing this work?
Not what the training programme says they're supposed to learn. What
actually changes after someone has done this fifty or a hundred times?
I'd ask six questions:
- What does repetition teach?
Which patterns, variations and exceptions become visible only after
seeing enough examples? - Where does judgement develop?
Which decisions require interpretation, context or uncertainty rather than simply following a rule? - Where does feedback happen?
How does somebody discover that their original judgement was wrong,
and do they understand why? - What does real responsibility add?
Is there something about making the decision on live work, with
incomplete information and actual consequences, that we can't
reproduce elsewhere? - What does proximity teach?
What do less experienced people learn by being around experienced
people making decisions, dealing with clients, responding to
incidents or handling things that don't go to plan? - What capability exists afterwards?
After someone has done this work for two years, what can they
recognise, understand or decide that they couldn't at the beginning?
There will be tasks where the honest answer is "not very much".
That's useful, we automate them. We shouldn't invent developmental value
just because historically a junior happened to do the work. Much like photocopying or juniors handling post.
Where the second map identifies something we still need, though, we've
found a capability that the new process has to account for.
Preserve, compress, simulate or move
I don't think every lost learning experience needs the same response.
There are at least four options:
Preserve, compress, simulate or move
Once you’ve identified something valuable that might disappear with the work, there are four ways to deal with it:
PRESERVE → Keep the experience
Some things may still need to be done for real, particularly early in someone’s development. A junior might make their own assessment before they’re allowed to see the AI’s answer.
COMPRESS → Keep the learning, lose the repetition
If the value comes from seeing variation rather than sheer volume, deliberately select the useful experiences. Thirty meaningfully different contracts may teach more than 300 largely similar ones.
SIMULATE → Create the experiences you can’t rely on happening
Introduce bad AI outputs, stale sources, conflicting instructions, near misses and unusual edge cases. Someone shouldn’t necessarily have to wait five years to encounter an important failure for the first time.
MOVE → Find a better place for the learning
The capability may still develop through the new workflow, just somewhere different. Juniors could investigate AI-human disagreements, handle exceptions, make independent assessments or work closer to the decisions previously made further up the chain.
I suspect good AI transformation will use all four.
The important bit is that we make the decision deliberately rather than assuming "training" will somehow absorb whatever disappears from the
process.
And there's a final step...
Test whether it worked
If we believe we've replaced 300 contract reviews with a better way of developing the same judgement, we should be able to find out whether that's actually true.
Give people unfamiliar situations. Give them plausible but incorrect AI outputs. Introduce incomplete information or conflicting sources. See what they escalate, what they miss and whether they recognise when they don't know enough to make the call.
In engineering, don't just test whether someone can get AI to generate a feature. We can give them a failing system they've never seen before. Ask them to understand what happened, challenge an apparently sensible proposed fix and explain the consequences of different choices.
What matters isn't whether someone completed the old apprenticeship. It's whether they developed the capability the apprenticeship was supposed to produce.
So the process becomes:
Map the work → Map the hidden learning → Preserve / Compress /
Simulate / Move → Test the capability
That feels much more useful to me than either preserving junior work for its own sake or assuming that conventional training can simply fill whatever gap automation creates.
What else did the work do?
I don't think any of this is an argument for slowing down AI adoption.
If anything, I think AI gives us an opportunity to get rid of a lot of fairly poor ways of developing people. Nobody needs to spend hundreds of hours doing something repetitive simply because previous generations did.
Before removing a process because we've found a better way to produce its obvious output, we should understand what else we're removing with it.
- What did people learn?
- Which repetitions actually mattered?
- Where did they get feedback?
- How did they learn what normal looked like?
- Where did they experience responsibility?
- How did they learn when something needed escalating?
Then if we still need those capabilities, where will the next generation develop them?
This isn't just a law firm problem. Engineering is already confronting it, and I suspect accounting, consulting, medicine and plenty of other professions will encounter their own versions. The details will differ, but the underlying systems problem looks remarkably similar.
For years, organisations have had processes that produced both work and workers capable of doing more difficult work later. We only really measured the first output because the second happened gradually and was difficult to see.
AI allows us to separate the two.
That could be a very good thing. We might design much better ways of developing people once we're forced to think about it explicitly, first we need to notice that there were two outputs in the first place.
I don't think the difficult question isn't simply whether AI can do more of the work, it's how inexperienced people become experienced when AI is doing more of the work they used to learn from.