The Orchestrator

There is a useful history hidden inside the title of this book, and it begins with a word that changed owners. Before computer meant a machine, it meant a person who computed.

Human computers worked in astronomy and navigation, in surveying and telecommunications, in ballistics and aeronautics and engineering. The job was to break a difficult calculation into repeatable steps, perform those steps with pencil and paper or a mechanical calculator, check a colleague’s work and have your own checked in turn, plot the results, and hand over numbers that other people would use to design a machine or commit to a decision. It could be tedious work. That is not the same thing as unimportant work, and the difference between those two judgments is going to matter for the rest of this book.

At NASA’s predecessor, the National Advisory Committee for Aeronautics, many of these computers were women. At the Langley laboratory the computing pools were segregated: NACA began hiring white women as computers in 1935 and Black women in 1943, and Black women worked in a separate unit, with restricted facilities, pay, and promotion. Katherine Johnson, whose hand calculations checked the electronic computers for John Glenn’s Friendship 7 flight, came out of that pool. Dorothy Vaughan supervised the segregated West Area Computers and taught herself electronic programming as the work moved onto the new machines. Mary Jackson used her experience as a computer in a wind-tunnel group to qualify as an engineer. The National Park Service preserves these transitions, and the reason it preserves them is worth sitting with: the story that matters is not only that these women performed the calculations, but that many of them learned the new machinery and moved into new forms of technical work as the role, its title, and its tools changed.¹ The Jet Propulsion Laboratory had its own corps of human computers — most of them women with mathematics degrees — who computed and checked trajectories for the early robotic missions and became some of NASA’s first computer programmers as the machines arrived.²

The machine did not arrive to announce that the mathematics was worthless. It arrived to perform more of the repeatable calculation, which left people to do everything the calculation had never covered — choosing the problem, checking the assumptions, interpreting the result, understanding the physical system well enough to know when a number was impossible, finding the error, and deciding what any of it meant. NASA’s account of its early human computers records the fact: trajectory computation moved to the machines, while trajectory analysis and mission planning remained human work. The further analogy to programmers today is mine.

That is the relevant warning for programmers, and I want to state it carefully, because it is easy to hear as reassurance and it is not. The fact that a machine can generate a function does not mean programming knowledge has become worthless. It means the part of programming that consisted mainly of producing routine code may no longer be the thing that organizes a career. People who understand systems, data, interfaces, failure, security, testing, and consequences will still be needed. What changes first is the title, and the need for technical judgment outlives it.

The comparison is not exact, and I would rather say so than let it do more work than it can bear. An electronic calculator was not an agentic system, and the disappearance of the human-computer title does not prove that the title programmer will disappear on any particular schedule. History is not a forecast. What history offers here is narrower and more useful than prediction: it shows what happens when a profession’s routine work is automated before the institutions responsible for that profession have built the next path into it.

That gap is the problem this book calls orchestration. The next generation of technical workers will need to direct systems that write, test, operate, and improve software, which means they will need enough technical understanding to inspect the machine’s work, enough domain knowledge to recognize when it is wrong, and enough authority to stop it. If organizations remove the beginner work that used to teach those three things, they will have to build another way to teach them. The alternative is an industry that produces more software every year and fewer people capable of taking responsibility for any of it.