The Orchestrator

A software developer is responsible for building or changing software, and the immediate objects of the work are lines of code, functions, services, APIs, repositories, tests, deployments, and releases.

A developer may well use an AI coding agent, and that agent may explain a module, draft a function, suggest tests, or open a pull request. The developer is still doing software development. The surrounding job is substantially unchanged: understand the requirement, decide how the implementation should work, inspect the result, test it, review it, help release it. The central question stays the same too — does this implementation correctly change the software?

The developer’s unit of work is code. The orchestrator’s unit of work is the outcome. Developers decide how to implement a component; orchestrators decide what should happen, which agents and systems should do it, what they may change, and what evidence will show that the result is correct. The title is still forming because the job is new, but the shift in responsibility is already visible.

This is not an unsupported prediction. Microsoft’s 2025 Work Trend Index, a vendor report, describes the rise of an “agent boss” — a worker who builds, delegates to, and manages agents — and expects that directing teams of specialized agents will become part of ordinary jobs.² Microsoft’s term will not settle the final title. It is evidence that a distinct role and mental model are forming.

People are already arguing about where this line sits, and some take a much stronger position than I do. On that view an orchestrator should not care about code at all, because the role is fundamentally about governance, objective-setting, and evaluation, and getting close to the implementation is a distraction from the higher-order work.

That is not this book’s position, and I think the honest version is simpler. Code is not the primary point of attention for an orchestrator, but it can be, and an orchestrator who can read code has a real advantage over one who cannot — because inspecting the implementation is part of evaluating whether the system is doing what it claims. An orchestrator who can write code has a further advantage still, because the ability to intervene at the implementation layer when the delegated system cannot is part of what keeps the whole arrangement honest. The distinction is about where attention sits by default, not about what a person is permitted to care about. A developer’s attention starts at the code and moves outward toward the customer; an orchestrator’s starts at the outcome and moves inward toward the evidence, the process, and, when it has to, the code.

This will be especially true during the transition we are in now. The tools for orchestration are immature, and the systems that are supposed to inspect, evaluate, and report on delegated work are still being built, so in practice orchestrators today spend a lot of time reading code, writing code, debugging agents, and doing work that looks like ordinary software engineering — because the automated layer is not yet reliable enough to make any of that unnecessary. As the tools improve, attention will move further from the implementation. The ability to go there when the situation demands it will remain part of the job.