What Actually Got Automated Away in Previous Software Waves
"Automation always creates more jobs" is too coarse to use. What each previous wave specifically removed — and what it left — is a much sharper predictor, and this wave's profile mostly matches.
Arguments about AI and engineering jobs lean heavily on historical analogy, usually stated as "automation always created more jobs than it destroyed." That's too coarse to be useful. The interesting question is what specifically disappeared each time, because the pattern in what goes is more informative than the aggregate headcount.
Four transitions, and what each removed
Assembly to compilers. What went: hand-allocating registers, writing platform-specific instruction sequences, manual optimization of loops. An entire specialty — the programmer who knew a particular machine intimately — largely stopped existing as a role.
What stayed: deciding what the program should do, and the algorithmic thinking underneath. Compilers removed the translation step, not the design step.
Manual memory to managed runtimes. What went: a category of work and an entire class of bug. Engineers stopped spending significant time on allocation discipline and leak hunting.
What stayed: knowing when memory behavior still matters. The people who understood it kept an advantage in exactly the situations where the abstraction leaked.
Building infrastructure to using libraries and open source. What went: writing your own HTTP server, your own JSON parser, your own connection pool. Enormous volumes of work that used to be someone's project became an import line.
What stayed — and this one is instructive — choosing which library, and understanding it well enough to debug when it misbehaves. The work moved from producing components to selecting and integrating them, which is a different skill wearing the same job title.
Racking servers to cloud. What went: physical provisioning, capacity planning on a hardware timeline, a lot of operational toil. Roles focused purely on machine care shrank substantially.
What stayed: understanding what the system does under load. Cloud removed the hardware, not the distributed-systems reasoning — and arguably made that reasoning more necessary, since the systems got more distributed.
The pattern in what goes
Across all four, the same properties predict removal:
- Mechanical translation from a specification to an implementation, where the specification is complete.
- Work with a verifiable correct answer and no judgment about what the answer should be.
- Effort that exists because a lower layer is exposed, which vanishes when the layer gets covered.
And the same properties predict survival:
- Deciding what should be built, which no layer of abstraction touches.
- Knowing when the abstraction leaks, which stays valuable precisely because fewer people can do it.
- Integration and selection, which grows as the number of available components grows.
→ Each transition moved engineers up a layer, and the work at the new layer was less about producing and more about choosing, composing, and judging.
Where this wave looks the same
The exposed categories match: implementation from a complete specification, boilerplate, mechanical translation between representations, work with an immediate verifiable check. That's the same profile as every previous wave, which is the honest basis for the optimistic analogy.
⚠️ Where it might not
Two differences worth naming rather than glossing.
Previous waves automated the layer below the decision. This one is pointed at parts of the decision. A compiler never chose what to build. An agent proposing an approach is operating, partially, at the layer engineers moved up to. That may be a difference of degree — the previous transitions also felt qualitatively new — but claiming certainty either way is over-claiming.
Previous waves had a clear next layer to move up to. Assembly programmers became systems programmers; server administrators became infrastructure engineers. Where the current layer is judgment and specification, it's less obvious what the layer above that looks like, or how many people it employs. Possibly it's problem selection and organizational judgment; possibly the answer isn't visible yet, which is what the previous transitions also felt like from inside.
✅ What the pattern suggests doing
Position where every previous wave left value: choosing rather than producing, knowing when the abstraction leaks, integrating rather than building components, and holding the judgment about what's worth doing.
That advice would have been correct in each of the four transitions above, which is a reasonable argument for it being correct now. The additional move this time is getting good at verifying generated output — the analogue of the library-selection skill, applied to work rather than to components.
The takeaway
Every wave removed mechanical translation from a complete specification and left the deciding, the judging, and the knowing-when-it-leaks. This wave's exposed categories match that profile. The difference worth watching is that it reaches further into the decision layer than its predecessors, and the layer above that one is less clearly mapped — which is a reason for humility about the analogy, not a reason to discard it.