From Coder to Orchestrator

As agents do the typing, the engineer's job shifts from authoring code to directing it -- scoping work, choosing approaches, reviewing output, and steering several agents at once. The unit of work moves up a level: from writing functions to specifying intent and judging results.

The Pattern

"The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate." -- Kent Beck (source)

Coding was never only typing -- you already broke features down, weighed approaches, and reviewed. Agents shift the balance: the generating moves to them, and your time concentrates on the framing and the judging. The unit of work moves up a level -- from writing functions to specifying intent and judging results, often across several agents at once. The developer becomes, in Rich Miller's phrase, "the orchestra conductor" (Rich Miller).

Addy Osmani splits the new work into two modes on a spectrum (Osmani):

• Conductor (in the loop) -- one agent, synchronous: the IDE or CLI pair programmer, steering each step and approving each diff.
• Orchestrator (out of the loop) -- many autonomous agents, asynchronous: set high-level goals, hand out tasks, get back ready-to-review pull requests.

The same person flips between them through the day; what changes is whether you sit in the loop -- hands on every step -- or out of it, reviewing outcomes after the fact. Which one a given task wants is its own skill (collaborating with agents). This is the orchestration end of loop engineering, and it leans on the coding interfaces that make running a fleet practical.

Why It Matters

This is the spine of the theme -- comprehension, learning, hiring, and performance all follow from the day reorganizing around direction rather than authorship. It is not people-management; it is orchestration of agents, closer to an engineering lead's judgment than a typist's throughput. The leverage is concrete: OpenHands runs "agents in parallel to solve CVEs across the entire codebase -- 90% get resolved automatically," leaving humans the 10% that didn't pass (vendor, directional) (OpenHands). Effort front-loads into the spec and back-loads into review, with little in the middle.

The roles converge

As agents get more autonomous, the orchestrator's job resembles several senior roles at once:

• Manager -- run a team of agents and a pipeline, not one assistant.
• Architect -- give direction and constraints, not implementations.
• Product owner -- prototype and experiment to discover what is worth building.

The same shift is mapped by the four patterns of AI-native development -- producer→manager, implementation→intent, delivery→discovery, data→knowledge -- which push developers toward "the work senior engineers have always done: managing, specifying, discovering, and curating knowledge," not faster typing (AI Native Dev).

Not everyone wants to let go

The shift cuts against temperament: some engineers love the craft of detailed coding and want the code right under their own hands; others happily give direction and judge the result. Even enthusiasts feel the sting -- "a part of you dies when you realize you can't implement stuff anymore" (Kent Beck). And the market reprices the same revaluation: "AI won't take your job, but it will take your ability to charge a premium for it" -- the skill premium, not the role, is what erodes (Sangeet Paul Choudhary).

For a team lead, that makes the transition a management task, not a mandate: people sit at different comfort levels, and the move needs active support, not just a directive. Where someone still wants to work in the details, channel that craft where precision still pays -- have them write the rules and guardrails the agents follow (an AGENTS.md, lint and policy gates) and improve the harness itself, so their instinct for getting it right shapes the system instead of fighting the workflow.

Keep what you orchestrate legible

Orchestrating at scale means you stop eyeballing every change as it lands. Osmani is blunt that oversight "remains critical as the final failsafe" and "the code review loop is going to need work if all this code is not to be slop" (Osmani). The failure mode is orchestrating work you no longer understand -- which is why this pairs with comprehension debt and leans on automated review and verification to keep review from becoming the new bottleneck.

Last reviewed: 2026-06-26