The Orchestrator

This book is near-future nonfiction. The argument was worked out in fiction first, and then I started seeing parts of that world in my own career.

Pete’s call was one of those moments. The system did not become conscious and it did not replace every expert; it let a business owner move an idea through design, implementation, testing, and deployment without waiting for the programmer who had always stood in the middle.

A change like that can feel like a loss if you define technical work by the number of people who need you, and it can also be an opportunity. For decades programmers have translated between the people who understand a problem and the systems capable of producing an answer. Orchestrated systems may let more people take part in that translation themselves.

I have a preference here, and I have already named it in the toolkit chapter: open-weight models, open harnesses, and open standards are not purity badges, but they are how an orchestrator keeps an exit ramp. Closed stacks will remain excellent for many jobs. A durable profession still wants the option to swap a model, read a skill file in git, and export a trace without asking a single vendor for permission.

The next few years will be difficult. People will lose familiar responsibilities, organizations will make exaggerated promises, and some systems will fail in ways the people who approved them never understood. The positive case is narrower: we can build structures around the change that help people learn, help businesses stop depending on one expert, and keep useful capability tied to human judgment.

Your Monday will not have Pete in it, but the Introduction asked you to test the word orchestrator against your own team, and this is the form of the test I would run. Pick the system at work that most resembles Maya’s laptop in Chapter 2 and ask who wrote down what it may change, who reads what it reports, and who is called when it stops. If the three answers are one person, you have found your Saturday programmer, and the work is to make that person less necessary the way I made myself less necessary to Pete: by writing the envelope and the record they carry in their head down where someone else can hold them. If the answers are nobody, you have found delegation by default, and the first job is to name the owner before anyone builds anything more.

Which brings me back to the phone call. “I love not having to call you” was accurate, and it was also incomplete, because Pete can still call me, and the arrangement depends on his being able to. What changed is what the call is for. I am no longer the person who makes the change. I am the person who wrote down what the system may change, who reads the report of what it tested and what it could not verify, and who is one phone call away when it stops — and the stops are the part I built. That is a smaller job than the one I had, measured in Saturdays, and a larger one measured in what I am answerable for: the envelope the system ran inside and the record it left behind are the things I put there, and they have to hold whether or not I am home. Build that structure, and make sure that when the phone stops ringing, it is because the record can answer the question, not because nobody knows whom to call.

HQ 6 — Assembled. The human and AI each wrote portions of this chapter. I assembled, reviewed, and take responsibility for the whole; the voice and arguments are mine, and I know which parts are which.