A question from 1995
My film opens with a thought experiment. Imagine describing today's conversational AI, code generation and machine translation to someone in 1995, then adding driverless taxis to the conversation. These capabilities belong to different systems. Would that person recognise a thinking machine, several remarkable tools, or something for which they lacked a name?
We cannot know their answer. The question makes our own shifting expectations visible. The film spends thirteen minutes on the history of those expectations. This essay asks what an industrial leader should measure while the naming debate continues.
The goalposts move inside companies too
In 1979 Douglas Hofstadter credited Larry Tesler with the line that AI is whatever hasn't been done yet. Researchers call this the AI effect. Chess, Go, translation and olympiad mathematics each went from proof of intelligence to routine computation the moment a machine could do them.
There is a corporate version worth watching. A capable system can be purchased as an individual tool, with an IT owner and a licence review, while the budget and authority to redesign the complete process remain unresolved.
Consider a proposed workflow that reads an emailed purchase order, checks it against the customer’s price agreement and prepares a sales order. Buying the interface does not decide which exceptions it may resolve, who approves a commitment or what happens to the work around it. Those are process decisions, whatever the product is called.
AGI has no single definition that settles those decisions. For someone running a business, the useful questions are more specific: how long can the system work on our tasks, at what reliability, and what are we prepared to hand over?
Read the second clock
The best public measurement for the first two parts comes from METR, a research group that times AI agents against skilled people. It measures the length of task an agent can complete, expressed as the time the same task takes a person.
In March 2025, METR reported that this length had been doubling roughly every seven months for six years, and that the best model at the time handled tasks of about an hour. In its Frontier Risk Report covering February and March 2026, it put the strongest agents it evaluated at 16 to 20 hours of work at 50 percent success.
At 80 percent success, the same agents managed tasks of 3 to 4 hours.
Most headlines use the first number. I think operators should look at the second, and then ask a question nobody can answer for them: what success rate does our process actually need? An 80 percent benchmark success rate is not an order-error estimate. It illustrates why the acceptable failure rate must be specified separately for each kind of work and consequence.
METR is careful about all of this. It says its task suite cannot reliably measure horizons above 16 hours, and that saturation makes its conclusions highly uncertain. Its tasks are mostly software and research work with clear scoring, which is much closer to code than to a customer's tender. The numbers describe the frontier. They do not describe your plant.
The difference between the horizons shows how sensitive a capability claim is to the success threshold. It does not tell us how much human review is required. Measure that locally: checking time, retries, repairs and the cost of finding a consequential error. That is the connection to the verification ceiling.
Build your own curve
The most useful thing an industrial company can do with the AGI debate, in my view, is replace it with its own measurement.
Pick one workflow where the right answer can be checked. Emailed purchase orders, spare-part identification, service-report drafts and configuration checks are plausible starting points. Choose one rather than blending them into a single score.
An exploratory sample of about twenty recent cases can reveal obvious failures and help design the evaluation. Include missing information and exceptions, and describe how the sample was selected. Twenty successful cases would not establish the reliability of a high-consequence process, especially if serious failures are rare.
Record what a skilled employee does, how long it takes, and the acceptance standard. Run the candidate system on the same evidence. Score completeness, correctness and whether it stayed within its authority. Then measure the human work needed to make the result usable: checking, corrections, escalation and reruns.
For example, a correctly prepared order with an unresolved delivery promise can be useful if it routes that decision to the right person. It should fail a test that expects autonomous release. These are different permitted workflows, not different ways to flatter the same result.
Use the initial failures to expand the case set and improve the controls. Where the downside warrants it, obtain a larger representative evaluation and specialist review before changing permissions. Re-run after meaningful changes to the model, tools, sources or process. Keep held-back cases so the test does not merely reward solutions tailored to the examples.
Plot performance alongside review effort and cost. The line worth watching is the share of complete cases that meet the agreed standard under the intended controls. A model-only score can improve while the service manager’s queue gets longer.
The first rung is where your reviewers learn
The film has a line about the first rung of the career ladder shaking. Two studies make the tension concrete, although they cover different populations and do not establish the same causal mechanism.
The first followed 5,172 customer-support agents. In the published version of Generative AI at Work, Erik Brynjolfsson, Danielle Li and Lindsey Raymond found that access to an AI assistant raised issues resolved per hour by 15 percent on average. Less experienced and lower-skilled agents improved both speed and quality; the most experienced and highest-skilled saw small speed gains and small declines in quality. This was one tool in one firm and occupation.
The second is the August 2026 revision of Canaries in the Coal Mine? by Brynjolfsson, Bharat Chandar and Ruyu Chen. Using US payroll data through June 2026, it finds employment of 22 to 25 year olds in AI-exposed occupations 19 percent below where it would be had it kept pace with less-exposed peers. The gap comes mainly from fewer hires rather than more departures, and the authors present it as descriptive evidence, not proof that AI caused it.
One study finds that beginners in a specific support setting benefited most. The other describes weaker hiring in AI-exposed US occupations. Together they raise a question about how the next generation will acquire judgment; they do not prove that assistants caused employers to stop hiring. The short-term logic is easy to follow: if the assistant does the junior work, why hire the junior?
The long-term cost is harder to see. In an industrial company, people learn judgment by doing exactly the work that is now easiest to automate: the quotation that comes back from engineering covered in corrections, the drawing they misread once, the support case that looked routine and was not. The engineers and commercial managers who will check agent output in 2031 are learning what wrong looks like today. Remove the first rung and in five years you may have agents that produce more than ever and fewer people who can tell when they are mistaken.
My recommendation is to keep the first rung and change how people learn on it. Juniors work on real cases under a senior, including reviewing agent output and investigating the underlying task. Preserve useful corrections as test cases. That can build judgment and verification capacity together; proofreading alone would not provide the same education.
Keep someone able to check the work
There is a sensible case for waiting on an expensive platform purchase while the technology changes. A local evaluation answers a different question: which work can we delegate under conditions we can defend? Its cost should be proportionate to the decision; it is not automatically cheap or a commitment to deployment.
The first useful result may be a decision to keep human approval, narrow a tool’s access, improve the source records or leave a workflow alone. It may also show that a complete class of work can move faster without passing its errors to the next team.
Take one workflow to the leadership meeting with the acceptance standard, the observed failures, the review effort and the permission change being proposed. Ask the process owner and reviewer to make the case together. If nobody can explain how an incorrect result would be found, the next investment belongs in evaluation or control rather than wider autonomy.
That is where the naming argument ends for me. The useful decisions are concrete: which work to hand over, at what reliability, and who remains able to check it.
How the film was made. The Steep Part was written, animated and scored with Claude and narrated with an ElevenLabs voice. It seemed wrong to write about handing work over without saying how much of the film I handed over.