The Engineer Becomes the Orchestrator

Software engineering has mostly meant turning intent into implementation. You understand the problem, design something, write it, test it, ship it, and fix what breaks. That’s starting to change, not because code matters less, but because producing it is becoming a smaller part of the work.

A lot of what I build now (mostly the side projects I wrote about in Why I Still Build) starts with me describing what I want and letting an agent take the first pass. Sometimes it’s good. Sometimes it’s confidently wrong. Usually it gets far enough that the problem changes, and I spend less time on implementation and more time deciding what should happen next.

Moving up a level

Software has always climbed through abstractions. Better languages, then libraries and frameworks, then cloud platforms and managed services, each one letting engineers stop thinking about some lower-level detail. Agents feel different, but I think they fit the same pattern, and the new layer is intent. Instead of asking for a function, I can say “here’s the system and the problem, figure out why this is happening and propose a fix,” or “build this using the existing patterns, add tests, and deploy it somewhere I can see it.” When that works, it feels less like autocomplete and more like delegating, though how well it works depends heavily on the context and how clearly I framed the problem.

The hard part moves

Implementation getting easier doesn’t make engineering easier by the same amount. Somebody still has to know what we’re actually trying to accomplish, how the problem should be broken down, what the agent should be allowed to touch, and whether the result is right. Those were always the engineering questions. They’re just harder to ignore once the code shows up in minutes.

There used to be a natural speed limit on bad ideas, because somebody had to write all the code. That limit is mostly gone. I saw it when we rolled out Claude Code across Corteva’s engineering and data science teams. Suddenly there was a lot more code, and the next bottlenecks started showing themselves. (The product side of this, deciding what shouldn’t get built at all, is what Scarcity Doesn’t Disappear. It Moves. is about.)

A lot of those bottlenecks come down to reading. Engineers have always spent most of their time writing code and some of it reviewing, and agents flip that ratio. If a machine can produce an implementation faster than I can, most of my job becomes deciding whether it’s any good: whether it fits the architecture, handles the failure modes, and leaves the system easier to understand rather than harder. The 2024 DORA report found something similar across the industry, where a 25% increase in AI adoption was associated with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. At some point generating code faster stops helping, because the real limit is how fast you can evaluate it and safely fold it in.

Good systems become more valuable

Agents make ordinary engineering discipline matter more. Clean code is easier for them to follow, good tests tell them when they broke something, and a fast CI/CD pipeline gives them a short feedback loop. That was always good practice. Now it’s also what makes an environment workable for an agent.

It’s changed how I think about platform engineering. A good platform gives engineers a paved path, and agents can use the same path. If deploying takes tribal knowledge, six manual steps, and a conversation with three teams, an agent won’t fix that for you. If deployment is encoded and observable, humans and agents can both move a lot faster.

The engineer becomes the orchestrator

“Orchestrator” is an imperfect word for what’s left, but it’s the closest one I have. The engineer increasingly works across agents, tools, code, and existing systems, and the job is getting them to produce an outcome. Sometimes that means handing an agent a whole problem and sometimes something very narrow. Sometimes you stop it halfway, and sometimes it’s faster to just do the thing yourself. Knowing which one is most of the skill. We’re still on the hook for the system.

I’m skeptical of predictions that programming is going away. People will still write code directly, and there will still be tangled systems, bugs that need first-principles reasoning, and performance and security problems that don’t yield to a good prompt. But the share of software a human has to write by hand will keep shrinking. The engineers who do well won’t be the ones who can produce the most code. They’ll be the ones who can take an ambiguous problem and turn it into a working system without leaving a mess behind, which takes as much technical depth as ever and probably more judgment.