Engineer Role Shift: From Implementer to Orchestrator

I spent the first eight years of my career measuring my own progress by how much code I shipped. Lines written, PRs merged, features delivered. That was the unit of value I had internalised. So when I started working seriously with agentic coding tools and found myself writing dramatically less code while shipping dramatically more, something felt off. Not wrong exactly, just unfamiliar. I had to relearn what "doing a good job" looks like.

That disorientation is what most engineers are about to experience. The shift isn't coming slowly. It's already here for anyone paying attention, and it changes the fundamental job description in ways that go well beyond "AI writes the code now." If you're still getting up to speed on how AI tooling integrates into day-to-day coding, Embracing AI-Augmented Development covers the practical side of that workflow shift.

What the implementer role actually was

Being an implementer is not a criticism. For most of software history, it was the only viable model. Requirements came in, engineers translated them into working software. The craft was in the translation: knowing the language, the patterns, the edge cases, the trade-offs between approaches. A great implementer could read a spec and produce something clean, correct, and maintainable faster than anyone else on the team.

That skill is real and it took years to develop. But the honest version of what most senior engineers spend most of their time doing is: taking a reasonably well-defined problem and writing the code that solves it. Not choosing what to build. Not challenging whether it should be built at all. Implementing what was decided upstream.

The agent changes this. Not because the agent is a better implementer than you are (though in many narrow cases it is), but because when implementation becomes cheap and fast, the organisation's constraint moves. The bottleneck shifts from "who will write this?" to "what should we actually build, in what order, structured how?" Those questions were always important. They're now the primary ones.

What orchestration means in practice

Orchestration is a term people use loosely. In the context of engineering work with AI agents, it means four specific things.

Architecture and decomposition. Before an agent can do useful work, someone has to define what work to do. This is harder than it sounds. Agents handle well-scoped, bounded tasks well. They handle ambiguous, tangled problems poorly. The orchestrator's first job is breaking a large problem into pieces small enough for an agent to execute reliably, sequenced in the right order, with clear interfaces between them.

I watched a colleague hand a half-baked feature request directly to an agent last month. The agent built something, but it built the wrong shape of thing because the request hadn't been decomposed into actual engineering decisions first. The orchestrator has to do that decomposition work. It's not glamorous. It's closer to architecture than to coding. But it determines whether the downstream work succeeds at all.

Agent coordination. Once you have a decomposed problem and multiple agents running, you're managing a workflow. Which tasks can run in parallel? Which ones have dependencies that force sequencing? Where are the integration points where two agents' outputs have to fit together? When an agent gets stuck or produces something off-target, what's the recovery path?

This is closer to technical programme management than to software engineering as traditionally understood. You're not writing the code; you're designing the system that produces the code, and monitoring it while it runs. The skill is in holding the whole structure in your head while individual pieces are in motion.

Quality evaluation. Agents are productive and confident. They are not reliably correct. They produce plausible-looking output that requires a human to evaluate against the actual requirements, against the existing codebase, against the constraints that weren't written down anywhere. This is harder than reviewing code a colleague wrote, because agents don't have context about your organisation, your users, your operational history, or the three reasons a similar approach was tried and abandoned two years ago.

Good quality evaluation requires a clear standard for "done" that you've defined before the agent starts, not after. It also requires knowing enough about the domain to spot when the output is wrong in ways that won't surface until production. The engineer who can evaluate agent output well is the one who understands the problem deeply, not just the code.

Strategic direction. Across all of this sits a harder question: is this the right thing to build? Agents can optimise for the objective you give them. They can't tell you if the objective is wrong. They can't notice that the feature you're building contradicts a decision made in a different workstream. They can't weigh the cost of this work against three other things competing for the same deployment window.

Humans hold the strategic context. The orchestrator's job includes feeding that context back into the system constantly: adjusting direction when the output drifts from intent, stopping work that is going in the wrong direction before it compounds, and connecting individual agent tasks to the larger product and engineering goals.

How the engineer role expands across multiple workstreams

One of the structural changes that comes with orchestration is that a single engineer can realistically shepherd several workstreams simultaneously. Where an implementer could work on one feature at a time (context switching is expensive when you're the one writing every line), an orchestrator can have one agent building a data pipeline, another writing tests for last week's feature, and a third exploring three approaches to a new API design, while the human moves between them at review and decision points.

This is both a capability and a responsibility. The capability is obvious: more surface area covered, faster. The responsibility is less discussed. When you're moving fast across multiple workstreams, the risk of something going wrong in a direction you weren't watching increases. Each individual agent task might look fine in isolation. The interaction between them, or the slow drift of one of them away from the intended design, is harder to catch when you're not sitting inside it continuously.

The orchestrator has to build explicit checkpoints into the workflow: points where they stop and evaluate the whole picture, not just the latest output from each stream. The engineers I've seen do this well treat their agent workstreams the same way a good manager treats their team: regular, structured check-ins with specific questions, not just "is everything okay?"

The skills that transfer and the ones that don't

Technical depth transfers. Knowing how a database query planner works, knowing what a race condition looks like, knowing why a particular API design is going to cause versioning problems in six months: these things make you better at decomposing problems, evaluating agent output, and catching mistakes. The engineer with no technical depth cannot evaluate what the agent produces. They can only guess.

Speed of implementation does not transfer. If your competitive advantage has been producing clean, fast code under pressure, that specific edge narrows. The agent does a version of that. Not identically, and not for every class of problem, but enough that raw implementation speed is no longer the differentiator it was.

Domain knowledge transfers, often more than engineers expect. Understanding a particular industry, a particular class of user problem, a particular regulatory environment: agents have almost none of this unless you put it in front of them. The engineer who has spent three years in fintech knows things about compliance, edge cases, and user behaviour that no amount of prompting will replicate. That knowledge becomes part of how you decompose problems, specify tasks for agents, and evaluate their output.

Patience with ambiguity transfers, but the nature of the ambiguity changes. Implementers deal with ambiguous requirements: figuring out what the user actually wants. Orchestrators deal with ambiguous agent output: figuring out whether what the agent produced actually matches what was intended, and why it diverged. Different problem, same underlying tolerance for sitting with uncertainty until you've reasoned it through.

What to practice now

The engineers who adapt fastest to this shift are the ones who stop treating orchestration as a side activity and start treating it as the primary craft. That means being deliberate about how you decompose work before handing it to an agent. It means building the habit of evaluating output against a clear standard rather than against a vague sense of "this looks right." It means developing the vocabulary to give agents precise direction, which is closer to writing good engineering specs than to writing code.

It also means getting comfortable with the discomfort of not being the one who wrote the thing. That turns out to be harder than it sounds for engineers who built their professional identity around the quality of their implementations. The output is still yours. The path to it just changed.

The engineers who will struggle are the ones who treat orchestration as a threat to their craft rather than an evolution of it. The craft is still there. It's just operating at a higher level of abstraction. Architects have always worked this way: defining the structure, making the key decisions, evaluating whether the execution matched the intent, without laying every brick themselves.

That is the job now. Not for architects only. For everyone.

If this kind of transition interests you, especially the path from senior engineer to staff or architect roles, the Monday BY Gazar newsletter covers exactly this territory every week. For a practical look at what the staff engineer archetype actually involves, see Leadership Without the Title: A Deep Dive into Staff Engineer. For how the development cycle itself is changing alongside the role, see Traditional SDLC vs Agentic SDLC.