The better your AI gets, the harder the human's job becomes

In 1983, a control-systems researcher named Lisanne Bainbridge wrote a short paper about industrial automation that has aged into something close to prophecy. Her observation was simple and it turns the usual pitch inside out. When you automate a job, you automate the parts a machine does well — the routine, the predictable, the easy. What’s left for the human is, by definition, everything that was too hard or too rare to automate. You didn’t lighten the human’s workload. You boiled it down to only its most difficult moments.

Follow that through and a set of ironies falls out, each one uncomfortable. The human is kept in the system precisely to handle what the automation can’t — the novel failure, the weird edge case, the situation nobody anticipated — which are exactly the situations that demand the most skill and judgment. But because the automation now handles everything ordinary, the human never practices that skill. Abilities you don’t exercise decay. So you’ve arranged for a person to perform the hardest version of the task with the least-rehearsed hands, and usually to do it after a long stretch of passive monitoring — and sustained monitoring is something human attention is genuinely, measurably bad at. We cannot stay vigilant watching a system that is nearly always fine. We tune out. Right up until the rare moment we’re the only thing standing between the system and disaster.

If that pattern sounds familiar, it should, because we are shipping it everywhere right now under a friendly name. Every “the AI handles the boring ninety percent, humans handle the important ten percent” pitch is describing Bainbridge’s irony without noticing it. A coding copilot writes the routine code, and the developer’s job shifts to reviewing fluent, plausible output for the subtle wrong thing — a genuinely harder task than writing it, performed while their own hands-on fluency quietly atrophies from disuse. A support AI clears the easy tickets, so the human gets only the gnarled escalations, with less of the everyday pattern practice that used to build the intuition those escalations require. A diagnostic AI flags the obvious cases, leaving the human the ambiguous ones plus the near-impossible discipline of staying sharp while rubber-stamping a system that’s usually right — and “usually right” is the exact condition that breeds automation bias, our tendency to defer to a confident machine and stop actually checking.

So the build work is to design for the human’s new job, the hard one you just created, instead of pretending you eliminated it. Keep the human in the loop, not merely on it — require real engagement at the decision points rather than a one-click approval, and surface the why, not just the answer, so the person can actually verify rather than defer. (This is where legible, calibrated confidence earns its keep: reasoning the human can inspect is what makes them a participant instead of a stamp.) Preserve the skill on purpose — rotate people through the routine occasionally, or build in practice, so the hands that have to handle the crisis aren’t rusty when it comes. Make the handoff loud and early: good automation escalates before the emergency, with the context the human needs, instead of dumping a cold crisis after hours of silence. And design against automation bias directly — make disagreeing with the AI easy, cheap, and expected, and never present its output as settled truth. Match the leash to the stakes: let it run free where mistakes are cheap and reversible, and keep the human genuinely awake where they’re expensive.

The obvious objection is that this sounds like an argument for less automation — and it isn’t, at all. Automate aggressively; the productivity is real, and the routine genuinely should be offloaded from people. The point is the opposite of Luddism: it’s that naive automation silently makes the human’s remaining job harder while advertising that it made it easier, and then designs nothing to support the job it actually left behind. The failure isn’t automation. It’s automation that assumes the leftover human role is trivial, when it is precisely the least trivial part of the whole system.

I’ll keep this honest about what it is. Bainbridge’s ironies are observations from human-factors engineering, durable because they keep recurring — the aviation world is full of autopilot-era accidents that read like case studies of exactly this — not a controlled law you can put a number on. And automation does erase some roles outright; the ironies bite for the roles that stay partly human, which, for the current wave of copilots, is nearly all of them. So when you ship the thing that does ninety percent of the work, don’t only ask what it can now do for the person. Ask what you’ve left the person to do — and whether you’ve built anything at all to keep them able to do it.