Why a Seventy Year Old Technique Could Be the Key to Unlocking the Next Stage of AI Automation

Dr Philippa Hardman, a learning researcher, built an AI system this year to write individual feedback for about fifty learners on a course she runs. Roughly 200 pieces of feedback over four weeks. Learners rated it among the best feedback they had received.

The part worth paying attention to is where the work went. Building the system took less time than getting twenty-five years of her own judgement out of her head. She had been making those decisions automatically, without ever putting them into words, and turning them into rules a machine could follow was the expensive part. Her advice to anyone attempting the same thing was to expect the extraction to take substantially longer than the build.

That is the bottleneck on most AI projects that touch real work, and it rarely appears in the project plan.

Why experts cannot tell you what they know

There is a good reason this is harder than it sounds, and it comes out of one of the better-established findings in the study of expertise.

As people get very good at something, the skill becomes automatic. Steps stop being separate conscious decisions and blend into one fluent motion. That is what expertise is, and it is the same property that makes it invisible to the person who has it.

Researchers have a name for the consequence. They call it the 70% rule: when experts explain how they perform a difficult task, they leave out a large share of what a newcomer would need, with published estimates commonly landing between 40 and 70% of the critical steps. Those steps have stopped registering as decisions.

There is a further wrinkle. Where reasoning has become automatic, people do not fall silent when asked to explain it. They generate a plausible account instead, and that account does not necessarily match what they did. So the obvious approach, sitting your best performer down and writing up how they decide, produces something incomplete and sometimes confidently wrong.

Source: research on expertise and cognitive task analysis, notably work by Richard Clark, David Feldon and colleagues.

If you have watched a top performer’s documented process fail to reproduce their results, this is usually why.

The field that already solved this

Here is the part most AI commentary misses.

There is a discipline whose whole purpose is systematically documenting what a job consists of and what it takes to do it well. It is called job analysis, it sits inside industrial-organisational psychology, and it is roughly as old as modern HR. Job descriptions, competency models, selection tests, performance criteria and occupational databases like O*NET all run on it.

Its specialised branch is cognitive task analysis, a family of interview and observation methods built for the exact problem above: capturing the goals, cues, strategies and judgement calls underneath performance that has become automatic.

Read a description of what a good AI specification needs, with its rules, standards, edge cases, worked examples and prohibitions. Then read a description of what cognitive task analysis produces. They are the same document, one written for a new hire and one written for a model. Prompt engineering, done seriously, is job analysis under a newer name. One of those two has seventy years of method, validation and documented failure behind it.

The toolkit

Four techniques from that older discipline are worth knowing by name.

Ask about specific incidents rather than general practice. The Critical Incident Technique, developed by John Flanagan in 1954 out of the US aviation psychology programme during the Second World War, rests on a simple observation. General questions produce general answers, and general answers are where the invented explanations live. Ask about one particular time, in detail. Concrete cases surface reasoning that abstractions smooth away.

Walk a hard case backwards. The Critical Decision Method, developed by Gary Klein and colleagues in 1989 as an extension of Flanagan’s work, takes one difficult real decision and probes it repeatedly. What did you notice first, what were you worried about, what would a less experienced person have missed, what would have changed your mind. It was built to study expert judgement under pressure and it surfaces cues that experts do not know they are using.

Have people think aloud while working. Narrating in the moment captures reasoning that disappears the second a task is finished.

Verify with a second expert. Someone else reviewing the written version finds the gaps the first person could not see, because the omissions are invisible from the inside.

None of this is exotic. It is ordinary practice in a field most technology teams have had no reason to call.

Why this raises the value of I-O skills

The prevailing assumption has been that AI reduces the value of people who study work, on the theory that a machine will learn the job by watching.

Evidence from people building these systems runs the other way. Models are available to anyone, and your competitors have the same ones. An accurate written account of how your best people make your decisions is not available to anyone else, and it has become a direct input to how well the system performs. That account is the exact artefact job analysis was invented to produce.

There is a second reason it matters. The failure mode here is silent. A specification built on an expert’s incomplete self-report throws no error. It produces fluent, plausible output that encodes the wrong standard, and in hiring, feedback and performance management that carries real consequences. Knowing how to elicit expertise and then validate it is the control on that risk.

What to do about it

Treat knowledge extraction as its own phase, with its own time and budget. Teams that leave it out discover it late, usually after assuming the model was the hard part.

Put someone with job-analysis training on the team. If you employ I-O psychologists, organisational development specialists or instructional designers, they already hold these methods. They are more likely to be sitting in HR than in the AI working group, so move them.

Change how you ask. Specific cases rather than general practice, observation of real work rather than description of it, and a second expert to check the written version.

Write the standard down before you automate it. If your best people cannot articulate the standard, a model will substitute the internet’s average opinion, which is what these systems do when left without instruction.

Where this leaves us

The scarce skill in this moment is getting expertise out of human heads accurately enough that a new hire, a training programme or a machine can work to it. Talking to models is the easy half.

That is a measurement discipline with seventy years behind it, and most organisations already employ people who know how to do it. They are just not in the room when the AI conversation happens.

They should be.