Where does the load go?

In a job interview, a director draws a space frame on the whiteboard and asks where the load goes.

The candidate has four years experience after graduating. Good CV, real projects, fluent about all of them. He takes a run at the question. It's... fine. He's not obviously wrong. Just strangely lightweight. He can trace the load path, but he struggles when the question shifts from what happens to why it happens or how you'd improve it. You get the sense that he's seen the answers many times without ever having had to discover them for himself.

In that four years, he worked on real buildings, shipped real drawings, had his work checked by people who knew what they were doing. But what he built in that time was fluency at running the tools that produced the answers, not a deep understanding of the underlying theory.

Nobody did anything wrong. His previous firm made sensible calls about getting work out of the door. His supervisors signed off work that was correct. The technical expertise that he was supposed to be gaining was being bypassed, one convenient task at a time, and the first person to notice was a stranger with a whiteboard marker.

He can orchestrate the tools. He cannot reason without them.

Nolan Lovett published a paper about this, in Human Resource Development Review. He separates internalised mastery from distributed mastery:

• Internalised mastery is deep domain knowledge built by struggling through real work at rising difficulty.
• Distributed mastery is skill at orchestrating human-AI systems to produce professional output.

What connects them is the validation tether. Distributed mastery stays safe only while internalised mastery sits underneath it, because deep knowledge is what catches output that appears correct but is actually wrong.

Lovett's model deals with checking too. Surface validation asks whether the output is consistent, formatted, plausible. Many people can do that. Substantive validation asks whether it is correct: this superstructure, these ground conditions, this client, this fabricator's standard connections. Only deep domain knowledge can achieve that, and a consultancy practice that measures output volume may see the difference between the two.

Your discipline is protected. The entry-level work may not be.

Lovett identifies two failure modes relevant to professional consultancy:

• Stock depletion is fewer people holding deep expertise, because firms stop hiring juniors. It is a hiring decision many practices will never make: graduates are cheap, professional bodies require them, and the firm's identity is bound up in training people.
• Functionality degradation is people in senior positions holding shallower expertise than their equivalents a generation ago, because they built fluency in orchestration while their domain knowledge stalled. It shows up as validation errors, and it happens without cutting staff.

He also scores occupational vulnerability across a number of factors and puts engineering consultancy in the safer half.

• Task substitutability is low for the discipline, but high for the kind of work graduates cut their teeth on: take-offs, spec research, drawing iteration, basic calculation, option generation, document review.
• Regulatory intensity is aimed at the person, not the method. Section 11F of the Building Regulations asks whether a designer has the necessary skills, knowledge, experience and behaviours - but not how they applied them.
• Safety criticality is high and the error signal is slow - failures often happen a long time after the mistake was made. While rare, they can be catastrophic.
• Work modularisation is rising, because drawing, spec and calculation will all unbundle more cleanly as the technology improves.
• Professional institutions are strong. ARB, RIBA, ICE and IStructE all run supervised practice and CPD, and all of them require logged experience. Some are beginning to take a position on AI - the IStructE's guidance suggests a senior engineer review any design an AI produces, and the ASCE states that AI cannot be held accountable.

The data only looks at half the problem

Maybe this concern turns out to be overstated. The recent evidence is actually quite encouraging. Ramp's economists looked at roughly 22,000 US firms and found the heaviest AI spenders grew white-collar headcount 10.2% over two years, entry-level hiring rising faster still. Anders Humlum and Emilie Vestergaard found near-zero effects on Danish earnings and hours in the first two years of chatbot adoption. Lovett does say that the depletion mechanism is not universal and that the tragedy has not arrived.

But none of that deals with degradation in internalised mastery and substantive validation skills. A firm could double graduate recruitment while quietly reducing the amount of work that develops deep understanding. Hiring more graduates does nothing if they spend three years becoming very good at using AI without becoming equally good at the underlying discipline. Headcount can keep growing and there still be a decay in deep domain knowledge, and the current evidence measures only the first.

What a practice can actually do

This feels more manageable if you frame it as a training problem instead of an AI problem.

Start by auditing what you are currently handing off to AI. For each task, ask what a graduate learned when they had to do it. Did these reps add to their deep domain knowledge? Where the answer is yes, you may have reduced a cost in the short term, but stored up a real problem for the future.

A few practical habits seem worthwhile, when handing something off to AI:

• Sort tasks by how much judgement is required. Isolated tasks with clear verification can run with a human at the final checkpoint. Where judgement is more important, put the human at the front. Write the intended approach and expected order of magnitude before the tool runs, then reconcile the two.
• Ask the AI for three options rather than one. Paul Nutt found that developing multiple options raised decision success from 56% to 70%, and that managers did it in fewer than a fifth of cases. Comparing alternatives exercises judgement in a way that just accepting a single recommendation doesn't.
• And don't generate more material than somebody can realistically review in one sitting. The temptation with AI is always to produce more. Faye's rule for code, generalises to any deliverable.

Giving it a name

Lovett's paper is conceptual and does not reflect the recruitment numbers holding firm in recent surveys. Professional expertise is not about to collapse.

What it gives us is a vocabulary for discussing the effect AI is having on professional workplaces and occupational vulnerability - a language for describing a risk that many people seem to recognise intuitively but struggle to explain. Before it, a director had an anecdote about one weak candidate in an interview. After it, they have something they can identify, monitor, and mitigate. The question isn't whether AI can carry the load. It's whether you've made sure it's carrying the right load.