· Timothy O'Brien
The Emerging Role of the Orchestrator
The conversation about the death of developers has become predictable. The developer whose job was to write boilerplate or scaffold CRUD applications is done — a model can do that in seconds, and that role is not coming back. But the people announcing the end of programming are missing something more interesting. A new role is emerging across a number of areas in software, and the industry does not yet have a name for it. The term that fits is orchestrator.
An orchestrator knows how to develop software, but the job is no longer to write the code. The job is to oversee a system — orchestrating tools, agents, and generated components into something that has to work in production. There are orchestrators, and then there are technical specialists. Orchestrators are marked by a move toward generalist expertise, because the capability of a specialist is now found mostly in a model. A handful of specialists will still be needed, but not one for every technology. The individuals becoming orchestrators tend to have a couple of decades of experience and an understanding of the end-to-end life cycle of software development. Think of them as expert Renaissance programmers — generalists who understand the whole system, not just one corner of it.
This is changing the whole makeup of IT departments. The term “programmer” no longer describes what these people do.
A concrete example
Consider a recent case: adding DRM to a series of self-published audiobooks. The task required an inaudible watermark encoding order-specific data into an audio file, so that if a file is found in the wild, the original buyer can be identified. This is not exotic work, but it is specialized — the practitioner is not a subject matter expert in audio watermarking, but does understand how to write code that processes sound files. Before generative AI, this task would have taken weeks or months.
In 2026, it took 20 minutes. The tools produced three dimensions of highly encrypted watermarking and fingerprinting — essentially the work product of three steganographic audio specialists. The first 20 minutes was spent asking the models to generate five different approaches, so the right one could be chosen. Part of the orchestrator’s job is to leverage these tools not just to create, but during ideation, product design, and quality engineering. The orchestrator is there because that person knows what questions to ask. Four years ago, this would have required three months and a large team. The system shipped without the orchestrator reading every line.
The identity shift
This is an uncomfortable space to inhabit. The version of the practitioner from three years ago would have been deeply uneasy hearing that something was implemented without writing the code. The initial reaction to the idea of “stopping reading your code” was very negative, and reservations about that position remain. But in practice, not reading the code is becoming the norm — because it is not “your” code. There are maybe a hundred thousand lines of code, too much to read, and reading every line is no longer the job. The orchestrator who tried to read everything would be highly inefficient.
There is a population of developers — perhaps 20 to 30 percent of those encountered in practice — who still push back on using these tools, as if the outcome is not as legitimate as writing by hand. This is not a vibe-coder, and it is not a citizen developer. It is an expert using tools, someone who cringes when a non-programmer claims to have shipped an app. The orchestrator knows enough to understand what was done on their behalf and how to dig into the details when something breaks. They know how to debug, they have a sense of what is valid and what is not, and they are honest about what they know and what they do not.
The controversial part
This is absolutely not about “democratizing access to technology.” There is a myth that anyone can pick up these tools and code, and that is true — anyone can code, but anyone cannot deliver to production in a scalable and secure manner. It is easy to start projects with generative AI. What is difficult is finishing them. It takes the same effort, energy, and technical expertise to deliver something to production as it always has. The idea that anyone can pick up a generative AI tool and create technical perfection — that myth is about to expire. If someone builds a complicated system and cannot debug it without AI, there will come a day when they have to pay someone to do that for them, and that person is going to charge a lot.
The key point: the orchestrator is qualified enough to understand the pilot manual that AI wrote, in case debugging is needed. If AI were to disappear tomorrow, the orchestrator could rebuild the system. That is not true for many people introducing themselves to coding through AI, and it creates a dependence on the tools that needs to be managed — through certified orchestrators who can create but also support systems without the tools, especially in regulated and critical areas.
Why not architect?
Because architect never worked. In companies that have architects, what they tend to be are the people who no longer code, maybe could not if they had to, and are literally there to just tell others what to do. It is a job that is beyond its prime. These days, everyone thinking about code should be coding in some way. The orchestrator is not an architect. The orchestrator is the person who owns the outcome.
The profession ahead
Orchestrators will not come from a bootcamp or a six-week certificate. This will take an apprentice program — years of it, the same way doctors and lawyers are created. Work under someone who knows what to pay attention to, and learn by watching them make decisions.
These are employees who can do real damage. When a corporation buys insurance for people writing code, that is one set of risks. When insuring professionals who are a hundred times more productive, they also carry a hundred times more responsibility. Insurance rates, regulations, and certification requirements are all going to go up. Doctors carry malpractice insurance because their decisions affect people’s lives. A Professional Engineer has to be licensed because engineering affects public safety. Orchestrators are headed the same direction.
If you fast-forward 20 or 30 years, what we call programmers now are going to be orchestrators, and they are going to look more like doctors and lawyers than like the current population of people who write code. Code will be part of the job, but not the majority of it.