The Orchestrator

6.1.1 The entry-level problem

The traditional engineering career gave a junior developer a series of small tasks — fix a bug, add a field, write a test, update a query, read a log, open a pull request, respond to review, watch the change reach production — and none of it was glamorous. It was how the developer built a mental model of the system.

Agentic coding tools now perform most of those tasks, which is useful and also removes the first rung of the career ladder before organizations have built a replacement for it.

The evidence is already concerning, although it does not support every dramatic claim made about the future of work. A Stanford Digital Economy Lab study of payroll data found that employment for software developers aged 22 to 25 fell nearly 20 percent from its late-2022 peak, while employment for older developers held steady or grew, and that early-career workers in AI-exposed occupations generally — customer support included — saw a relative decline.¹ Stanford’s 2026 AI Index adds that one-third of surveyed organizations expected AI to reduce their workforce in the following year.²

Those figures do not prove AI caused every lost job, since hiring cycles, interest rates, over-hiring, and ordinary churn in the technology sector all matter too. What they do show is a problem organizations should not ignore: the people who would normally be learning through routine technical work have fewer opportunities to perform it.

Meanwhile developers are adopting the tools quickly. Stack Overflow’s 2025 survey found 84 percent of respondents using or planning to use AI tools in development while 46 percent said they did not trust the accuracy of the output, and the same survey found developers least willing to delegate high-responsibility work such as deployment, monitoring, and project planning.³ That hesitation is sensible, and it also points straight at the training problem.

Remove the junior work without replacing the learning it provided and you eventually have fewer people who understand the technical details. Put automated systems into production on top of that and you have systems producing more code than anyone left can explain. Which is the crisis in one sentence: automation makes technical fluency more important at exactly the moment it makes technical fluency harder to acquire through ordinary work.

6.1.2 What an orchestrator has to know

An orchestrator does not need to know everything, since that standard is impossible to meet. They need to know enough to locate what they do not know, bring in the right specialist, and keep the system from acting beyond the available evidence. Every orchestrator needs a technical foundation in:

• reading code and configuration;
• data structures, state, and control flow;
• APIs, networks, authentication, and service boundaries;
• databases, schemas, transactions, copies, and data lineage;
• version control, code review, CI, tests, and release processes;
• permissions, secrets, least privilege, and audit records;
• logs, traces, queues, dashboards, and decision records;
• deployment, rollback, feature flags, and incident response; and
• basic measurement, including denominators, samples, false positives, and tradeoffs.

None of that demands every orchestrator become a full-stack developer; it is a safety requirement. Somebody who cannot read a permission change cannot safely approve an agent requesting new access, somebody who cannot tell an API response from a completed business action cannot safely direct an agent that calls the API, and somebody who cannot read a test cannot know whether an apparently successful change is safe.

Domain knowledge matters just as much. The database specialist knows what corruption looks like, the security specialist knows how an apparently harmless permission turns into an incident, and the customer-service specialist knows which exception makes a person abandon the process entirely. An orchestrator does not replace any of those people, and has to know when their judgment is required and how to make that judgment part of the system.

6.1.3 Different systems require different orchestrators

Orchestration will not be one universal job practiced in the same way everywhere. There will be orchestrators in software, healthcare, finance, logistics, manufacturing, government, education, and other fields. The general work is similar: define goals, delegate bounded work, inspect evidence, manage permissions, and remain responsible for the result. The knowledge required to do that work is different in each domain.

The same distinction applies inside software organizations. A person who orchestrates software-engineering systems needs to understand software engineering. They need to know how repositories, branches, code, architecture, APIs, CI, deployment, and rollback fit together. A person who orchestrates quality-assurance systems needs to understand test design, fixtures, regression, coverage, evaluation cases, release criteria, and the difference between a passing test and a trustworthy result. The same holds for databases, security, compliance, and operations.

That list pushes toward what this book calls a broad-coverage technologist, though the label that keeps sticking is renaissance technologist. The honest precedent is less Alberti than the staff engineer who has worked three layers of the stack: not mastery of everything, but exposure to the full spectrum of technologies involved in building and operating software systems, plus a genuine capability in several areas — enough to reason about each one, to recognize sound work and weak work in it, and to know when a specialist has to be brought in. The breadth does not replace the fundamentals. A person needs an awareness of each of these disciplines at a fundamental level before they can be responsible for orchestrating a system that automates one, and experience is not something you can skip. That is one of the challenges of the emerging job title: it is tough to get experience when everything is automated.

Nobody has to master every one of those areas to the same depth, and nobody can safely direct a component whose work they cannot understand at all. Which gives you four levels of training rather than one:

1. General foundation. Every person working with delegated systems learns basic programming, data, APIs, permissions, testing, telemetry, deployment, and failure handling.
2. Component qualification. The person learns the professional discipline represented by the systems they direct: software engineering, QA, databases, security, operations, compliance, or another specialty.
3. Workflow qualification. The person learns how those components interact in one end-to-end business or technical workflow, including goals, handoffs, authority, customers, and failure modes.
4. Critical-system qualification. The person passes a system-specific review covering edge cases, audit, legal or compliance questions, security, operations, code-level intervention, wide-mode and deep-mode diagnosis, and operation without AI.

6.1.4 The education this requires

Those requirements add up to more than a hiring profile. They describe a different kind of technologist than our education system currently produces, and the education system is going to have to respond. This profession is going to require a renaissance technologist, and the label carries a demand for a new kind of education: a reinvestment that produces fewer narrow specialists and more technologists with an exposure to all the different areas they may one day be responsible for orchestrating.

It may mean a real departure from what we currently call computer science. It would not be surprising if the term itself faded from professional training, because computer science as taught today concentrates on tasks that are now largely automated or commoditized. Knowing how a compiler works is real knowledge, but it is becoming specialist knowledge — the sort of thing one person in the organization carries, not the price of admission.

There will still be specialists, and organizations will still employ them. A hospital employs physicians who do nothing but anesthesia and physicians who do nothing but radiology, because those skills are deep and worth concentrating in particular people. Large organizations will keep employing database specialists, security specialists, compiler specialists, and machine-learning specialists the same way.

---

1. Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen, “Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence,” Stanford Digital Economy Lab, August 2025 (revised November 2025). https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine. Using ADP payroll data, the paper reports that employment for software developers aged 22–25 declined nearly 20 percent from its late-2022 peak to mid-2025 while older age groups grew, and a roughly 13 percent relative decline for early-career workers in the most AI-exposed occupations after controlling for firm-level shocks. The authors are explicit that the findings do not establish a single causal explanation for every change.↩︎

2. Stanford HAI, The 2026 AI Index Report, Economy chapter, especially the sections on workforce impact and productivity. https://hai.stanford.edu/ai-index/2026-ai-index-report/economy. The report presents these figures as uneven labor-market effects and does not attribute every employment change to AI alone.↩︎

3. Stack Overflow, 2025 Developer Survey, AI section. https://survey.stackoverflow.co/2025/ai. The survey reports self-described use, trust, and intentions among respondents; it is not a controlled productivity study.↩︎