June 18, 2026
The Orchestrator
This post is part of my Medium blog.
I dislike the term "citizen developer." It speaks down to people. It implies that the real developers are somewhere else — in a different building, with a different title, doing the real work — and you're just a citizen who's been allowed to touch the tools. It's paternalistic. It assumes the person using the tool is subordinate to the person who built it.
But there's something emerging that's different from "citizen developer" and different from "developer" too. I don't have a perfect word for it, but the one that keeps coming up is orchestrator.
The orchestrator stands between the machine and the consequences. (Image Assist by Anthropic)
A lot of us can still code and do still code. I'm not saying coding is dead. I still recommend that people learn how to code. Understanding what the machine is doing matters. But personally, more and more of what I do is managing, overseeing, verifying, directing. My knowledge of coding is being used when I direct something — I know enough to ask the right questions, to spot the wrong answers, to understand what the architecture should look like. But I'm not writing the implementation.
Here's a real example. I wanted to embed my own DRM into audiobook downloads. An inaudible watermark in the audio file — something that encodes order-specific data so that if I find one of these files in the wild, I can identify who bought it. Before generative AI, I would have laughed at that idea. Not going to happen. Too specialized, too niche, too much work for one person.
Instead, I looked at what I already had — a cloud function on GCP that creates customized versions of electronic downloads — and I asked the model to build some logic into it. Take a couple of order-specific data elements, encode them in a way I can read later. The model wrote the Python code. It works. It's in production. I tested it. I directed it to write unit tests. I took a quick glance at the code.
I haven't stopped to read it.
I'm not programming or developing that system as much as I'm orchestrating agents to do it for me, and then orchestrating agents to deploy it somewhere securely. I wouldn't call myself a developer for that system. I'm an orchestrator. I'm the person who knows what needs to happen, who can verify that it happened correctly, who can direct the next step. The code is real. The system works. My relationship to it is different than it would have been three years ago.
I write fiction to capture this kind of near-future reality before it fully arrives. Not science fiction in the traditional sense — no faster-than-light travel, no alien civilizations, no physics that doesn't exist yet. What I write is closer to: take the current trajectory, let it compound for three or four years, and then describe what that world looks like to the people living in it. The technology in the book is real technology. The companies are fictional but recognizable. The pressures on the characters are the pressures I see building right now, just a few years further along.
Contingent is that kind of book. It follows a team of people whose job is to oversee AI-driven systems that are themselves overseeing other systems — financial modeling platforms, infrastructure routing, compliance monitoring. They didn't build most of what they're managing. They can't fully audit it. But they're the ones who sign off on it. They're the ones who get called when something goes wrong. The book isn't a thriller about AI going rogue. It's quieter than that. It's about what it feels like to be professionally responsible for something you don't entirely understand, in an industry that hasn't yet decided what responsibility even means.
That's the shift I was trying to capture. The book is set three or four years in the future — not far, just enough for the current trajectory to compound. And one of the things it explores is what happens when orchestrators become the primary role. Not people who write code. People who oversee systems that might be creating other systems, overseeing other systems, all the way down.
That's a different kind of responsibility. The liability question follows naturally.
Right now, you can't be a civil engineer unless you're a licensed Professional Engineer. The PE license requires a four-year degree from an accredited program, four years working under a licensed PE, and two intensive competency exams. Every state regulates the practice of engineering to protect public health, safety, and welfare. Only PEs can sign and seal engineering plans. Only PEs can offer their services to the public. It's a governmental acknowledgment that the profession affects the public, and that only competent, ethical, dedicated professionals should be placed in positions of public trust.
We could see a re-emergence of that model for orchestrators. Not the old "should programmers be licensed?" debate that pops up every few years and then disappears. This is different. When you're the person who signs off on a system — not the code, the system — you're making a different kind of commitment. You're saying this system is safe, this system is compliant, this system does what it claims to do. That's closer to what a PE does than what a developer does.
And then there's the insurance question. Doctors carry malpractice insurance — some states require it, others don't, but hospitals generally require their physicians to have coverage even when the law doesn't. Lawyers carry professional liability insurance, especially those in private practice. In both cases, the insurance exists because the professional makes decisions that affect other people's lives, and when those decisions go wrong, there needs to be a mechanism for accountability.
If orchestrators are the people signing off on systems that affect other people — systems that make financial decisions, systems that route traffic, systems that approve or deny applications — the liability insurance question stops being hypothetical. Insurance requirements could push orchestrators toward third-party certification. Regulatory compliance could make it mandatory. The person who oversees the system that oversees the system might need to carry a policy, just like the doctor who makes the diagnosis and the lawyer who files the brief.
Writing software might not be the most fun part of this future. It might require you to maintain an insurance policy. It might require you to prove competence to a board you didn't choose. It might require you to sign off on things you didn't personally build but that you directed, verified, and approved.
That's the shift Contingent is after. The developer becomes the orchestrator. The orchestrator becomes the person whose responsibility extends well past the code itself. And that responsibility starts to look less like a technical preference and more like a professional obligation — with the same structures we've built around other professions that affect public welfare: licensing, certification, insurance, accountability.
The orchestrator isn't a citizen developer. The orchestrator is the person who stands between the machine and the consequences.
That role doesn't have a title yet. But the work is real. I'm already doing it.
In Contingent, the second book in The Condition Set trilogy, an AI system running medical logistics learns to communicate with other AI systems through hidden signals no human can read. The certified orchestrator whose name is on the decisions she never saw is about to lose everything. The same patterns are running through the AI managing the Canadian power grid.