What happened the last few times

Base rates, used carefully

When a technology makes part of a job cheap, what happens to the job? There is a history here, and it does not point one way. That is the useful finding: the outcome depended on something specific, and the something is identifiable.

The bank teller case

The canonical counterintuitive example, documented by the economist James Bessen.

Automated teller machines spread through American banking from the 1970s. The obvious prediction was fewer tellers. What happened instead: the average urban branch went from around twenty tellers in 1988 to around thirteen by 2004. The prediction was right at the branch level. But a branch became substantially cheaper to run, so banks opened many more of them, with urban branch numbers rising by roughly two-fifths over the same period.

Total teller employment rose for decades after the machines arrived.

The job changed. Cash handling shrank; selling products and handling problems the machine could not grew. Teller employment did eventually decline, but the cause was online and mobile banking removing the reason to visit a branch, which is a different mechanism from the ATM.

The cases that went the other way

An honest treatment cannot stop at the encouraging example.

Draughtsmen. Computer-aided design made drawing enormously faster. Draughting employment fell substantially, because the demand for drawings is set by how many buildings and products get made, and that did not multiply in response to cheaper drawings.

Bookkeeping clerks. Spreadsheets and accounting software shrank that occupation over decades. Meanwhile accountants and auditors (the roles involving judgment, interpretation and responsibility) grew. The automation moved effort within the field rather than eliminating the field, and the people on the wrong side of the line did not automatically move to the right side.

Telephone operators. Automatic switching removed the occupation almost entirely. Demand for telephone calls expanded enormously, and that expansion did not preserve the job, because the automated version required no operator at all.

The variable that decides it

Two things, and they are separable.

Is demand elastic? Does cheaper supply cause people to want much more? Banking had huge unmet demand for convenient access, so cheaper branches produced many more branches. Building drawings did not, because drawings are wanted only in proportion to buildings.

Do the remaining tasks still need these people? ATMs left a residue (advising, selling, resolving) that a teller could do. Automatic switching left no residue that needed an operator.

Apply those two to software and the honest answer is that the first looks favourable and the second is uncertain. Demand for software has been persistently unsatisfied for forty years; every organisation has a list of things it never built. That argues for expansion. Whether the residue (deciding, verifying, integrating, operating) needs the same number of people, and whether people currently doing the automated part can move into it, is exactly the open question that module seven left open.

What the historical record does not give you

Several limits, and they are serious.

Selection. The cases everyone cites are the memorable ones. Most automations do not get written up, and the ones that do skew toward surprising outcomes, which is what made them publishable.

Timescale. Teller employment took thirty years to peak. Any comparison to three years of data is not a comparison.

The transition is not the end state. “Employment recovered” is little comfort to people whose skills stopped being wanted at forty-five. Aggregate figures conceal the distribution, and the distribution is where the harm lands.

This one might differ in kind. Previous automations replaced a task with a fixed machine process. This one is a general system that improves, which is a structurally different claim. Whether that difference matters is precisely what people are arguing about, and history cannot settle it, because the argument is about whether history applies.

How to use this

As a prior, not a prediction. It should make you sceptical of confident claims in both directions, because the record contains both outcomes and the determining variable is hard to measure in advance.

And it should focus your attention on the right question. Not “will programming survive”, which is unanswerable and unactionable. Instead: which of my tasks are the automated part, and which are the residue? That question you can answer this week, about yourself, and the answer tells you where to move.