This article by Tim O’Brien originally appeared on Medium and is republished here with the author’s permission.
There’s a lot of talk about the demise of developers. Routine coding work—boilerplate, scaffolding CRUD apps—can now be produced by models in seconds, and those specific jobs are disappearing. But that doesn’t mean programming itself is ending. Instead, a new role is emerging: architects and developers are evolving into orchestrators—individuals who direct work that once required entire teams.
What distinguishes an orchestrator from a developer?
An orchestrator understands software development, but their primary function is no longer writing most of the code. They oversee systems, coordinate tools and agents, and stitch generated components into production-ready solutions. Crucially, an orchestrator emphasizes operating and developing the systems that produce software, rather than delivering every line of software themselves.
Technical expertise that once went into designing database schemas or object models is now applied to guiding subsystems that make most tactical decisions. Where a 2023 developer might choose how React stores state, a 2027 orchestrator focuses on DESIGN.md standards for a subsystem that fuses analytics and customer feedback to recommend, test, and implement site changes as part of a more autonomous business operation.
Orchestrating delegated intelligence
While many tools today call themselves "agents" (examples include Hermes and OpenClaw), O’Brien suggests a clearer category: delegated intelligence. This term captures systems that have memory and operate with a degree of independence, while still being traceable to a responsible human operator—the orchestrator.
Delegated intelligence implies automation, productivity, and the need for accountability. As organizations use autonomous agents to run critical systems, questions like “under whose authority was this delegated intelligence operating?” will become essential after outages or incidents.
An ecosystem of orchestrators: generalists and specialists
Orchestrators are typically generalists with end-to-end experience—think of seasoned professionals who understand the whole software lifecycle. Specialists remain necessary but are fewer, and some specialists may themselves become specialist orchestrators. The role will be complex: one orchestrator could replace the output of 20–30 developers plus QA teams, while still relying on a limited number of domain experts.
A practical example: DRM watermarking in minutes, not months
O’Brien recounts adding inaudible, order-specific watermarks to audiobooks he self-publishes. Previously this project would have taken weeks or months. When he orchestrated the task recently, the system produced three dimensions of highly encrypted watermarking and fingerprinting in about 20–40 minutes. He spent the first 20 minutes asking the system for five different approaches, then had it model long-term cost, operability, customer experience, and a pros-and-cons matrix, ending with a recommendation.
The system that implemented the solution had tracked content development for months and used customer knowledge, analytics, and product design to inform its proposals before implementation.
The job is orchestration, not line-by-line coding
Today’s orchestrators use tools across ideation, product design, and quality engineering. Their value comes from asking the right questions and taking responsibility for outcomes. O’Brien admits he often does not read every line of generated code—because the code is not strictly his—but he must understand what was done and be able to debug or rebuild if necessary.
This creates an identity shift for many programmers: shipping production systems without reading every line is uncomfortable for some, but it’s becoming normal as the orchestration role grows.
Not everyone is a finisher
There’s a myth that these tools democratize production-grade software development: anyone can pick up generative AI and create technical perfection. O’Brien rejects that idea. Starting projects is easy; finishing them—delivering secure, scalable, maintainable production systems—still requires significant expertise. If organizations build complex systems without an orchestrator responsible for creation and operation, they will eventually need to hire someone to do it, and that will be costly.
Planning for contingencies and ensuring support
Before deploying his DRM system, O’Brien required the agent to record code locations, architecture, approach, and generate documentation that would allow debugging and support if AI were unavailable. He didn’t read the entire "pilot manual" the system produced, but he understands the control points and believes he could land the plane without autopilot. This capacity to operate—or to recreate—the system offline is a core responsibility of the orchestrator, especially in regulated or critical domains.
Organizational, regulatory and insurance implications
The rise of orchestrators reshapes IT teams: a single orchestrator can substitute for dozens of developers, altering staffing models. O’Brien argues this role won’t be teachable in a short bootcamp; it requires apprenticeship-style training over years, similar to professions like medicine or law. Orchestrators carry significant liability—insurers, certification bodies, and regulators will need to respond. Just as doctors have malpractice insurance and Professional Engineers are licensed because their decisions affect public safety, orchestrators may face comparable requirements.
Looking ahead
In 20–30 years, the professionals we now call programmers are likely to be orchestrators whose work resembles that of lawyers or doctors more than today’s code-writing community. Writing code will remain part of the job, but it will no longer dominate the role.
Author: Tim O’Brien (originally published on Medium)
