Human machine symbiosis, sixty years on

Licklider split the work by what each side was good at. The split has quietly moved onto a different axis, and that changes what is safe to hand over.

You send someone else to do the shopping.

You do not give them the items you are worse at buying. You give them the ones where you will be able to tell if they got it wrong. Milk, bread, the coffee you always get. Not the birthday present for your mother.

That is not about their taste. Their taste might be better than yours. It is that you can check the milk and you cannot check the present.

Every argument about working with machines is an argument about where that line sits. Licklider drew it in 1960. I think it has moved, and most of the current disagreement is people standing either side of a line nobody has redrawn out loud.

What Licklider drew

He opened with a fig tree and a wasp. The fig is pollinated only by Blastophaga grossorum, whose larva lives in the fig’s ovary and feeds there. Neither manages without the other. Not a tool and a user. Two organisms that became one arrangement.

Then he measured himself. Through a working spring and summer he tracked what he actually did, and found that about 85 per cent of his “thinking” time went on getting into a position to think. Finding things. Plotting things. Converting units.

So he drew the line. Men would “set the goals, formulate the hypotheses, determine the criteria, and perform the evaluations.” Machines would do the routinizable work that clears the way.

He knew it was a phase. Five years to build it, fifteen to use it, and then the honest part people skip: “The 15 may be 10 or 500.”

What he got right is that the division of labour matters more than the capability. That still holds. The rule for drawing it does not.

Where the line is now

Look at the half he kept for us. Formulating hypotheses. Determining criteria. Performing evaluations. A machine now proposes the hypothesis, writes the code that tests it, reads the profile, and reports which of the four things it tried worked.

Robin Linacre’s account is the most useful I have read, mostly because it is a field report rather than a forecast. He leads Splink and has been doing record linkage for over a decade. The load-bearing sentence:

The stronger the feedback loop, the larger the task we can safely delegate.

His examples share a shape. Profiling Splink: the check is the existing test suite. Upgrading documentation from v4 to v5: the check is whether v5 returns the same answer as v4. Porting DoubleMetaphone from Java to C++: the check is thousands of encodings that already exist.

None of those is work a machine is uniquely suited to. Every one arrives with a check that runs without him in the room.

The axis moved

Put the two together and something has changed that neither says directly.

Licklider drew the line by competence. Give the machine what it is better at.

Linacre draws it by verifiability. Give the machine what you can check.

In 1960 those return the same answer, which is why the difference was invisible. The routinizable half was also the checkable half. A conversion is right or wrong and you find out at once. They come apart now, because the machine reaches into work whose failures do not announce themselves.

Licklider Now
The question what is each side good at what can I check
The machine’s half clerical, preparatory most of implementation
What kept it safe errors were visible on their own the loop has to be built on purpose
Where the line comes from capability, discovered a person, deciding

So getting better at this is mostly not about better models. It is about being able to say, for the thing in front of you, what would tell you it was wrong. That is a skill, it is not the same skill as doing the work, and we have never had to teach it separately.

The checkable half is not the important half

A test suite is a specification somebody wrote. A benchmark is a metric somebody chose. Both are the residue of an earlier judgement, and the machine inherits it rather than making it. This is Moravec’s paradox one level up.

The place it gets concrete for me is identity. A machine can compare a million pairs of records without complaining. It cannot tell you that this particular pair matters more than the others because of something nobody wrote down.

Linacre is straight about this where it counts. Many similar experiments failed. And the overfitting on his address matcher gets caught by a person looking at real false positives, not by the accuracy going up. The score is checkable. Whether the score measures the right thing is not, and an agent running longer will find that gap faster than you will.

His last example is the one nobody will quote. Cursive handwriting, where there is no test suite for does this look handwritten, so he built a curve editor, a join analyser, a kerning editor. Throwaway instruments whose only job was to put an eye back into a loop that could not close itself.

That is the honest form of “human in the loop”, and it is the opposite of the usual one. The usual one is a person at the end of a pipeline with an output, an approve button, no instrument and no time, whose real function is to be nameable afterwards. The tell is whether the human step has a tool of its own.

What he assumed about us

He listed five prerequisites. Speed, memory hardware, memory organisation, language, input and output. Four are done. Memory organisation is still open, and in nearly his shape: he wanted retrieval by content, we built retrieval by similarity, and mistaking one for the other is most of what goes wrong in a retrieval system.

But the assumption that broke is not on the list, because he never wrote it down. He assumed the human stays the same. Every sentence about the man is in the present tense. Someone who already holds the goals, the criteria and the judgement, and needs only to be relieved of the clerical work around them. He never asks where the judgement came from, or what happens to it when the preparation goes away.

In 1960 that was fair. Plotting a curve by hand was not how anybody learned to think. It is not obviously fair now, and it is most of what stays human.

Which is the other thing about his metaphor. The fig and the wasp both changed. Nothing else in the paper is two way. The machine serves the man, the man ends up unchanged. He picked a biological word for a relationship he then described as a service.

Three worlds, not two

Licklider posed this one as well, and people forget that he did.

He described three arrangements. Systems where the human is left “responsible mainly for functions that it proved infeasible to automate”, which he said flatly “are not symbiotic systems”. The partnership itself, which he thought “will think as no human brain has ever thought”. And the end state, where machines “outdo the human brain in most of the functions we now consider exclusively within its province”. He expected the middle to be an interval, and he expected those years to be “intellectually the most creative and exciting in the history of mankind”.

So the two futures people argue about now, more with the machine or replaced by it, were both on his page. What he did not have a name for is the one I think is most likely, because it is the cheapest.

Thinking out loud, then.

More. The person does more, reaches further, and discovers things neither side could have found alone. The machine widens what one person can hold in view at once. This is the one worth wanting, and it is the one Licklider was actually describing.

Replaced. The task leaves. No person is in the loop and nobody pretends one is. Honest, at least. Where the check closes on its own this is fine, and it is already happening, one task at a time.

Hollowed. The person is still there. On the org chart, at the end of the pipeline, in the approval step. They can no longer tell whether the answer is right, and nothing in the output says so. This is Licklider’s leftover human, the one he said was not symbiosis, except the leftover is now called judgement.

From outside, the first and the third look identical. Output is up. The person is still employed. Every number that gets reported says augmentation. The difference only shows when the machine is taken away, and nobody takes it away to check.

I do not think we choose between these once. We choose per task, mostly by default, and the default is the third, because on any given day it is the fastest and the person still feels involved.

Which world should we be thinking about? The first, on purpose and against the grain. But I am less sure than that sounds about how. The model does not decide which world a task lands in. The loop around it does, and so does whether the person in that loop could still do the thing with the machine switched off. Neither of those is visible from the output.

Where I run out

  • Capability, then verifiability. Is the next axis reversibility? Something can be uncheckable and still safe to hand over if undoing it is cheap. I suspect that is the one that matters once agents act on the world rather than on a repository.
  • Can “would I notice if this were wrong” become a real per-task measure, rather than a feeling you have afterwards?
  • Symbiosis assumes both sides change. What is the machine supposed to be getting from me?
  • Can a person keep judgement about work they no longer do? Every apprenticeship we have built says you earn it by doing the boring half first. Nobody has run that experiment on people who skipped it.

The nearest thing I have to an answer is this site, where the checks are mechanical and the judgements are not delegated. It is small and it proves nothing.

What it has taught me is narrower. The boundary is the hardest part to hold. It drifts on its own, always in the same direction, and always for a good reason on the day.

Reading

First published
9 August 2026
Last revised
13 September 2026
Fingerprint
c0d2e3c0743b7652

SHA-256 of this page's markdown source. Check it yourself, or read what it proves.