Automation and the Reorganisation of Knowledge Work

“Will this job be automated” is the wrong unit. Jobs are bundles of tasks, automation happens to tasks, and what a bundle does when you remove one task from it is not obvious in either direction.

The task model, and why it predicts better

The framework comes from labour economics — Autor, Levy and Murnane’s work on routine task content, later formalised in the task-based models of Acemoglu and Restrepo. The core idea: production requires a set of tasks; each task can be performed by labour or by capital; technology changes the relative cost. Automating a task has two opposing effects. It displaces the labour that did it, and it lowers the cost of the whole output, which raises demand for everything else in the bundle.

This is why the historical record is so unhelpful to both sides of the public argument. Occupations that were heavily automated in one task sometimes shrank and sometimes grew, depending on whether the remaining tasks were complements and whether demand for the output was elastic. The often-cited case of bank tellers and cash machines cuts both ways and is used by both camps; the useful lesson from it is only that the direction is not determined by the automation alone.

The practical payoff is that a task-level view makes testable local predictions. Take a role, list what someone in it actually spends hours on, and ask of each item separately. The answers are usually mixed within a single role, which is precisely why job-level headlines are unreliable.

Which task properties actually matter

Notice that only the first is about the model. The others are properties of the organisation, which is why two firms with identical tooling get very different results — an observation that matches the diffusion literature on earlier general-purpose technologies, where complementary organisational investment dominated the returns.

The verification bottleneck

The most consequential structural change is simple to state. Generation became cheap; verification did not. Where a process used to be limited by how fast competent people could produce work, it becomes limited by how fast competent people can check it — and checking is often the scarcer skill, held by the more senior person.

Several observable consequences follow. Review queues grow and become the new constraint. The value of a reviewer rises relative to a producer. Volume rises even where quality does not, because the cost of submitting has fallen for everyone including the low-effort submitter — visible anywhere a queue receives unsolicited work. And there is an asymmetry worth naming: an error that is expensive to detect is far worse than one that is expensive to fix, so tasks where wrongness is subtle are exactly the ones where cheap generation is most dangerous.

The apprenticeship problem is the second-order version. The tasks that are easiest to hand to a model are frequently the ones junior staff learned on. If those disappear from the junior role, the pipeline that produces the senior reviewers is disrupted, and the effect appears years later. This concern is raised across law, medicine, accountancy and software; whether it materialises is genuinely unknown, and it is not a reason to keep make-work, but it is a real design question for anyone restructuring a team.

The jagged frontier

Dell’Acqua and colleagues described the boundary of model capability as a jagged frontier: tasks of apparently similar difficulty fall on opposite sides of it, and the boundary is not visible from outside. Their field study of consultants found improvement on tasks inside the frontier and degraded performance on a task outside it, where participants accepted plausible but wrong output.

That produces two symmetric failure modes in real teams. People who calibrate on the successes over-trust and stop checking — the expensive direction. People who calibrate on one bad experience under-use the tool on tasks where it works. Neither is fixed by training people to “use AI”; both are addressed by mapping the frontier for your own tasks empirically and writing down which side each falls on.

The frontier also moves, which makes any map perishable, and it moves unevenly: a capability that was outside it can be inside it after a model change, and occasionally the reverse after a provider adjusts behaviour. That is an argument for keeping a small internal set of representative tasks with known correct answers and re-running it on every model change — the same discipline as a regression suite, applied to a dependency that updates without asking. Organisations that do this discover the change before their customers do; organisations that do not find out from a complaint.

Designing the work

• Put generation where verification is cheap, and invest in making verification cheaper before investing in more generation.
• Write the context down. In most organisations the model is not the constraint; the undocumented convention is.
• Keep a human at the point where the error becomes irreversible, not at every step — review everywhere is review nowhere.
• Instrument the outcome, not the usage. Tokens consumed and seats occupied measure adoption, not value.
• Decide deliberately what juniors still do by hand, and be honest that this is a training investment with a cost.

One caution about the wider debate. The task frame is a good predictor and a poor moral argument. It tells you which parts of a role are exposed; it says nothing about whether the resulting reorganisation is well handled, who captures the gain, or what happens to a person whose bundle is dismantled faster than they can rebuild it. Those are distributive questions and they are not answered by getting the task analysis right — a point worth keeping in view when the analysis is used, as it often is, to imply that the outcome is settled.