“Will this technology take my job?” is asked constantly and answered badly, and the reason is a measurement problem rather than a disagreement about facts. The question puts the job at the centre of the analysis. Jobs are the wrong unit. They are bundles — and bundles do not automate, their contents do.
A job title is an administrative label wrapped around a set of tasks that happened to be convenient for one person to do. A radiologist reads images, talks to referring doctors, decides what to image next, handles ambiguous cases, and signs off on liability. A bookkeeper enters transactions, reconciles accounts, chases missing receipts, and explains the numbers to an owner who has not read them. Automation does not arrive at the level of “radiologist”. It arrives at the level of a task, and it reaches different tasks in the same job decades apart.
Once the unit is right, the question changes shape. It stops being a yes/no prediction about an occupation and becomes something a data person can actually reason about: which tasks in this bundle are exposed, what remains when they go, and what happens to the shape of the job.
What determines whether a task is exposed
Exposure is not about how difficult a task feels to a human. It is about whether the task has the properties that current methods need. Four of them do most of the work.
- Is there a clear target? A task automates when success is defined precisely enough to measure. “Transcribe this audio” has a target. “Decide whether this is the right project” does not.
- Does labelled data exist as a by-product? The tasks that fall first are usually the ones where people already recorded the answer for other reasons: approved loans, tagged photos, corrected drafts, historical demand. Where labels must be created from scratch, the economics change completely.
- How expensive is an error? The same accuracy is deployable in spam filtering and unacceptable in a medical decision. The threshold for automation is set by the cost of being wrong, not by the accuracy number. This is the practitioner’s daily problem of choosing a threshold rather than a metric, scaled up to an economy.
- Is the environment stable? Systems learn from the past. Tasks in stable environments transfer; tasks where the rules move require constant relearning, which is a recurring cost rather than a one-time saving.
Physical constraints add a fifth. A task can be trivially automatable in software and still take a decade in a warehouse, because someone has to buy, install, and maintain hardware. Software eats tasks faster than machinery does, and always has.
The counter-intuitive part: which tasks are hard
The ordering does not follow human difficulty at all. Tasks that take people years of training — reading a scan, translating a contract, calculating a route — often have exactly the properties above: clear targets, abundant recorded examples, stable rules. Tasks a child does without thinking — picking up an unfamiliar object, noticing that something is off, knowing when a question is the wrong question — have none of them.
This inversion is old news to anyone who has built systems, and still surprises everyone else. It matters because public discussion ranks occupations by prestige or years of schooling, and that ranking has almost no relationship to exposure. Sorting by “how well specified is the task, and does the data already exist?” gives a very different list.
What happens to the job when a task leaves
Three distinct outcomes hide behind the word “automation”, and they have different consequences.
| Outcome | What happens | Signature |
|---|---|---|
| Substitution | The task is done by a system instead of a person | The task disappears from the job description |
| Complementarity | The system does part of it; the person does more of the rest | Time reallocates within the same job |
| Reorganisation | The bundle is redrawn — tasks split across different roles | New job titles appear, old ones split |
Substitution is the one everyone pictures, and at the level of a whole occupation it is usually the least common of the three. The other two are quieter and harder to count, which is why they are underweighted in conversation. A job that loses 40% of its tasks and gains new ones is statistically still the same job, and someone doing it would tell you it is not.
There is also a demand effect a pure task view misses. When a task gets much cheaper, the amount of it that gets done usually rises, sometimes enough to increase the total work around it. Whether that happens depends on whether demand was being suppressed by cost — an empirical question, answered differently in different sectors.
How a data person should actually reason about it
Four habits keep the analysis honest.
Decompose before predicting. Any claim about an occupation should be restated as a claim about tasks. If it cannot be, it is a vibe. This alone kills most of the bad arguments in both directions.
Distinguish demonstration from deployment. A capability shown under controlled conditions is a weak input to a forecast about work. Between demo and deployment sit integration, liability, regulation, procurement, retraining, and the tolerance for errors in that specific setting. Those gaps are where most of the time goes, and the demo hides all of them.
Separate what is measured from what is inferred. “This system matches expert accuracy on this benchmark” is a measurement. “Therefore these jobs go away” is an inference with several unstated assumptions — that the benchmark resembles the real distribution, that the rest of the bundle was small, that the error cost is acceptable. Each is checkable. Most are never stated.
Give timescales or say nothing. “Eventually” is compatible with every outcome and therefore predicts none of them. A claim without a horizon cannot be wrong, which means it also cannot be useful.
The most widely watched treatment of the long-run version of this question is What Happened to Horses Is Happening to Us by CGP Grey — worth watching with the task/job distinction in mind, since the framing is deliberately economy-wide rather than task-level.
What none of this settles is the part people care about most: how the gains and losses land on particular people in particular places. That is a question about institutions, not about which tasks are technically exposed, and no amount of careful task decomposition answers it. Being precise about the technical question is still worth doing, if only so that the harder question is argued on its own terms rather than through bad forecasts about job titles.