Thought Leaders
The New 10x Engineer Doesn’t Write 10x the Code. They Build the System That Writes It.

The 10x engineer has been a Silicon Valley myth for decades. The lone genius, headphones on, mass-producing elegant code at superhuman speed. We’ve debated whether they exist, argued about how to hire them, and quietly resented anyone who claimed to be one.
But something interesting happened on the way to the AI-first future: the 10x engineer became real. They just look nothing like we imagined.
OpenAI recently shared how a three-person team used Codex to ship 1,500 pull requests and roughly a million lines of code, without writing a single line manually. Three engineers, and zero hand-written code. A production product used by hundreds of internal users.
That’s not 10x; it’s closer to 100x. And the skill that made it possible wasn’t typing faster or knowing more algorithms. It was building the system that made AI agents productive: the workflows, the guardrails, the verification loops, the interfaces that agents plug into and humans review through.
I believe this is the emergence of a new key function in engineering organizations. I’d call it AI Orchestration Engineering.
Three Disciplines Walk Into a Standup
If you squint at what an AI Orchestration Engineer actually does, you’ll recognize three familiar disciplines fused into one.
The most obvious ingredient is DevOps. DevOps centralized the deployment pipeline. One team configured the CI/CD workflows that every engineer used when shipping code. AI Orchestration Engineering does the same thing, but for agent workflows. It defines how tasks get assigned to agents, how outputs get validated, how retries and fallbacks work. It’s the shared infrastructure that agents run on.
Then there’s architecture, which overlaps with DevOps more than you’d expect. Architects decide which interfaces are locked, which patterns are enforced, which boundaries can’t be crossed. In an agent-first world, this matters even more. Agents need clean, well-documented codebases with clear contracts. The AI Orchestration Engineer defines those constraints, not just for human readability, but for agent comprehension. A messy repo isn’t just technical debt anymore. It’s a productivity ceiling for every agent that touches it.
The least understood piece is the AI-specific layer. Prompt engineering, context management, model selection, agent configuration. Today, most engineers do this in a scattered, task-by-task way. Each person figures out their own prompting style, their own agent setup, their own workarounds. The AI Orchestration Engineer centralizes this. They build the shared playbooks, the reusable configurations, the organizational knowledge about what works and what doesn’t across models and use cases.
Separately, these three functions exist in most engineering organizations today. The argument is that combining them into a single, centralized role creates something qualitatively different.
The Showrunner Metaphor
A film director doesn’t operate the camera, act in the scenes, or edit the footage. But every frame reflects their decisions.
They choose the shot composition, the pacing, the tone. They decide when to push in close and when to pull back wide. They set up the environment (lighting, set design, blocking) so that every person on set can do their best work within a coherent vision. The crew is individually talented, but without that coordination, you get a mess that never ships.
AI Orchestration Engineering works the same way. The agents are capable. The models are powerful. But without someone designing the system that coordinates them, defining the constraints, building the feedback loops, structuring the workflows, you get what we’ve all experienced: inconsistent outputs, wasted compute, agents working at cross-purposes, and engineers spending more time fixing AI-generated code than they would have spent writing it themselves.
The director makes a film greater than the sum of its parts. The AI Orchestration Engineer does the same for agent fleets.
Why Most Organizations Are Underinvesting
Here’s what I see across the industry: companies are investing heavily in AI tools and not nearly enough in the systems around them.
Engineers get access to Copilot, Claude, Codex. They experiment individually. Some become power users. Most plateau at the “fancy autocomplete” stage. The 20% productivity gains that studies keep reporting? That’s the symptom of tool-level adoption without system-level thinking.
The organizations breaking through, the ones reporting 2x or greater throughput, have something in common. They’ve centralized the orchestration work. Someone (or some team) owns the agent workflows, the repository preparation, the verification infrastructure, the shared context that every agent can access.
What the Role Actually Looks Like
An AI Orchestration Engineer’s day-to-day might include:
- Designing agent workflows: defining how a feature request becomes a spec, becomes a plan, becomes parallel agent tasks, becomes reviewed and merged code.
- Building verification infrastructure: automated tests, linting rules, security scans, and evaluation frameworks that agents must pass before their work gets merged.
- Maintaining repository health for agent consumption: documentation, clear interfaces, dependency management, and codebase simplification, all optimized for agent comprehension, not just human readability.
- Centralizing prompt and context strategies: shared system prompts, retrieval pipelines, model routing decisions, and configuration templates that the whole team uses.
- Monitoring and improving agent performance: tracking success rates, failure modes, cost per task, and time-to-merge across the agent fleet, then tuning the system based on data.
This person sits at the intersection of platform engineering, software architecture, and AI expertise. They don’t write features. They build the system that makes feature delivery fast, reliable, and scalable.
The Historical Pattern
In the early days of cloud computing, deployment was every engineer’s side quest. Each team had their own scripts, their own server configs, their own way of getting code into production. DevOps emerged to centralize that work, and Platform Engineering evolved to build it into shared, self-service infrastructure.
AI is following the same arc. Right now, agent usage is every engineer’s side quest. Each person has their own prompting style, their own tool preferences, their own mental model for when AI helps and when it doesn’t. The organizations that centralize this, that treat it as infrastructure rather than individual experimentation, will pull ahead the same way that organizations with mature DevOps practices outpaced those without.
The difference is speed. The DevOps transition took a decade. The one might take quarters. though I’ll admit that prediction assumes organizations recognize the pattern faster than they usually do.
The Path Forward
If you’re an engineering leader, here’s what I’d suggest, though your mileage will vary depending on how far along your team already is.
- Identify who’s already doing this work informally. Every organization has someone who’s figured out the agent workflows, who other engineers go to for advice on prompting or tool setup. That person is your proto-AI Orchestration Engineer.
- Make it explicit. Give the function a name, a mandate, and resources. Don’t let it remain a side project attached to someone’s “real” job.
- Start with repository readiness. Before investing in sophisticated agent workflows, make sure your codebase is something agents can actually navigate. Clean interfaces, good documentation, comprehensive tests, simplified architecture.
- Centralize what works. When someone discovers a prompting strategy or workflow pattern that dramatically improves agent output, capture it. Make it the default for the whole team, not tribal knowledge locked in one person’s head.
- Measure at the system level. Don’t just track individual tool usage. Track how many tasks agents complete end-to-end, what the review and rework rates look like, where the bottlenecks are.
The New 10x
The myth of the 10x engineer was always about individual heroics. One person, outperforming everyone through sheer talent and caffeine.
The reality of the 10x engineer in the AI era is about systems thinking. The person who makes every other engineer (and every agent) more productive by building the right infrastructure, the right workflows, the right constraints.
They don’t write 10x the code. They build the system that writes it.
I’m not certain this role will crystallize exactly the way I’ve described it here. But I’m fairly sure that the organizations which figure out the orchestration layer (whatever they end up calling it) will be the ones that actually realize the productivity gains everyone else is just talking about.












