Isaac Asimov, 1991: AI and us, two specialisations that complete each other
In 1991, Isaac Asimov talks neither about robots nor about science fiction. He talks about arithmetic, about what we do badly and what the machine does well. His conclusion fits in one sentence, and it describes better than any white paper how to make an AI project work in an organisation.

I have shown this clip to executives and to front-line teams. It lasts twenty-two seconds. Every time, the discussion changes nature: people stop talking about replacement and start talking about dividing the work.
What Asimov says, word for word
The interview was posted on YouTube by Brian Roemmele, who dates it to 1991 and presents it as Asimov’s last major interview. I could not verify either point against an independent source, but the content itself can be checked by listening.
Asimov starts with what we do badly:
“We do a great many things we’re not good at. For instance, we’re not really good at arithmetic. We need help, we need numbers, we need pen and paper, we need devices. Well, the cheapest computer in the world can multiply and divide faster and more accurately than we can. That’s its specialty. Our specialty is different things.”
Then he concludes:
“So that you end up not having artificial intelligence and natural intelligence identical, but two different things, two different specializations. They work together, each supplies the lack of the other, and in cooperation they can advance far more rapidly than either could by itself.”
Why this sentence beats a debate about replacement
Since 2022, the question I hear most often is “will AI replace my team?”. It is the wrong question, because it assumes the machine does the same thing as people, only cheaper. Asimov asks the right one: what does the machine do better than us, and what do we do better than it?
With a language model, the answer has become finer than in 1991, but it has the same structure.
- What the tool does better: read fast and without fatigue, find a piece of information in a thousand pages, rephrase, summarise, classify, produce a first draft, apply the same rule a thousand times without getting bored.
- What we do better: know what matters in a specific situation, negotiate, decide when rules contradict each other, take responsibility for a decision, sense that a case “does not look like the others”.
A language model predicts the most plausible continuation of a text. That is a formidable specialty, and it is also its limit: it does not check, it has no opinion. I told the story of where that mechanism comes from in Shannon’s 1948 experiment.
Dividing the work, in practice
In my engagements, I turn Asimov’s sentence into a half-day exercise with the team concerned. We take a real task, end to end, and cut it into steps.
- List the steps. Receive the request, look up the information, write, check, decide, send, follow up. A “20-minute” task often contains ten of them.
- Mark each step. To the tool: what is repetitive, documented, and where an error is visible. To the human: what commits the company, what depends on context nobody wrote down, what requires an agreement.
- Draw the handover. Where the tool stops, what it passes to the person, in what form. This is the point that makes or breaks the project: “each supplies the lack of the other” assumes both know where the boundary is.
- Measure before, measure after. Time spent, rework rate, errors. Without a baseline, you will never know whether the cooperation moved anything forward.
This approach avoids the two classic failures: the tool left alone on the whole task, which invents confidently as soon as it leaves its frame, and the tool rejected outright because it was judged on the part of the work it does badly. The reasons projects stall between the demo and production are detailed in this note.
What Asimov adds, and what we tend to forget
In the same interview, Asimov also says we must think about side effects now, “before it’s too late”, and he takes the example of the car: cities were built without the automobile in mind, and we then spent a century not knowing where to put it. The equivalent in an organisation is installing a tool without deciding who is accountable for it, how its errors are detected, and what happens when it is wrong. That is not a technical question. It is an organisational one, and it is settled before deployment, not after.
Why I keep this clip
Because it is short, because it comes from someone who spent his life imagining intelligent machines, and because it promises nothing. It only says: two specialisations, one cooperation, and a boundary to draw. Thirty-five years later, that is still where an AI project starts.
Source: “Isaac Asimov On AI, Last Interview”, video posted by Brian Roemmele (YouTube, 2017), excerpts 2:41-2:58 and 3:01-3:24. Transcript checked by listening; the 1991 date and the “Visions of the Future” series are stated by the channel and not independently verified.
In the same series
The other episodes of “the ancestors of LLMs”, in chronological order:
- Ada Lovelace, 1843: the engine “originates nothing”
- Markov, 1913: Pushkin letter by letter
- Shannon, 1948: a book opened at random
- Turing, 1950: the test, and the wrong question
- Dartmouth, 1956: the first underestimated AI quote
- Rosenblatt, 1958: the Perceptron’s promise
- ELIZA, 1966: a machine that understands nothing
- Jelinek, 1980s: statistics beat grammar
Frequently asked questions
Was Asimov talking about today’s language models?
No. In 1991 he is talking about computers and what was then called artificial intelligence. His reasoning is about the nature of the tool, a specialty different from ours, and it applies as is to language models, which predict plausible text without checking it.
How do you decide what goes to the tool and what stays with the team?
By cutting a real task into steps with the people who do it. To the tool: the repetitive, the documented, what shows its errors. To the human: what commits the company, depends on unwritten context or requires an agreement. Then you draw the handover between the two.
Where should a small business start?
With a single task, the teams concerned, a baseline measurement and one person accountable for results. A few days of scoping are enough to pick that task and define what the tool must check before acting.