From Author to Orchestrator: The Engineer's Role in the Agentic Era

Open Table of contents

The job is moving up the stack
What rises in value
What gets commoditized
How to make the shift

The job is moving up the stack

There’s a lot of anxiety about whether AI will replace engineers. I think that framing misses what’s actually happening. The job isn’t disappearing — it’s moving up the stack of abstraction, the way it always has.

We went from punch cards to assembly, assembly to C, C to high-level languages, frameworks, and platforms. Each jump didn’t eliminate engineers; it raised what a single engineer could accomplish and changed where their time went. Agentic AI is the next jump. The valuable work shifts from typing the implementation to specifying the intent, directing the work, and verifying the result.

You stop being the author of every line. You become the orchestrator.

Author — the old loop

1 Read the ticket

2 Type the implementation

3 Debug line by line

4 Write the tests

5 Repeat, one task at a time

Orchestrator — the new loop

1 Specify intent & constraints

2 Direct agents on N tasks at once

3 Review & verify the output

4 Course-correct the approach

★ Judgment becomes the bottleneck

Same engineer, higher altitude. The leverage moves from keystrokes to decisions.

What rises in value

When implementation gets cheap, the scarce skills are the ones that decide what to build and whether it’s right:

Specification. The ability to describe a problem precisely — constraints, edge cases, definition of done — so an agent can execute without a dozen clarifying round-trips. Vague in, vague out.
Taste and judgment. Knowing that a “working” solution is actually wrong for your system. Agents produce plausible code endlessly; knowing which plausible thing is correct is human work.
System thinking. Holding the whole architecture in your head so you can tell when a locally-reasonable change is globally bad.
Verification. Reviewing at the speed agents produce. This is the new bottleneck, and I think it’s the defining skill of the era — enough so that I gave it its own post.

What gets commoditized

Conversely, the things that used to be a moat are becoming table stakes: boilerplate, scaffolding, first drafts, glue code, translating between formats, writing the obvious test. If your edge was “I can crank out CRUD endpoints fast,” that edge is gone. That’s fine — it was never the interesting part.

Humans set the direction; agents do the heavy lifting. Engineers focus on strategy, judgment, and high-leverage decisions.

How to make the shift

You don’t become an orchestrator by reading about it. A few concrete moves:

Practice specifying. Before reaching for the keyboard, write the spec as if you’re handing it to someone who will take you literally. You’ll be surprised how often the ambiguity was in your own head.
Run more than one stream. Get comfortable supervising parallel work instead of doing one thing at a time. The mental model is closer to a tech lead than an IC.
Sharpen your review. Build the muscle to skim generated code and instantly spot the load-bearing mistake. This is learnable, and it’s where your seniority pays off.
Invest in context. An orchestrator with no organisational brain is just a faster way to ship generic code. Direction needs grounding.

The engineers who thrive won’t be the ones who resist this. They’ll be the ones who realize they’ve been training for it their whole careers — every code review, every design doc, every “no, that won’t scale” was practice for the orchestrator’s job.

This is the practice I’m building around. If you want the full picture, here’s how it fits together.