From One Agent to Many: What Orchestration Changes About Who You Hire

We flagged this shift in passing in an earlier piece, a VP of Engineering telling us the agentic layer was “a small cohort at the moment. It won’t be small for long.” The data from the first half of 2026 suggests that cohort is growing faster than most hiring processes have caught up with.

Here is what the current numbers actually show, and what we think it means for how you evaluate a contract developer.

Usage has nearly doubled. Trust hasn’t caught up.

Stack Overflow’s May 2026 pulse survey found AI agent usage among developers had nearly doubled year on year, from 31% to 59%. That is a genuinely fast shift. What it did not find was a matching shift toward autonomy. Most respondents, 60%, block agents from making unapproved system changes. A larger share, 68%, still prefer a single, predictable agent over a more complex multi-agent setup. Where developers have settled on one agent, GitHub Copilot and Claude Code account for the large majority of that usage.

The people who have moved to running multiple specialized agents at once are still a minority. They also, notably, use agentic workflows daily far more than single-agent users do. Adoption of orchestration is uneven, but where it has taken hold, it looks like a genuine change in how someone works day to day, not an experiment.

The delegation gap

Anthropic’s 2026 Agentic Coding Trends Report names something worth sitting with: developers now use AI in roughly 60% of their work, but report being able to fully delegate only 0 to 20% of tasks without close supervision. Constant use. Limited trust. That gap between how often the tooling is present and how much of it can actually run unsupervised is, per the report, the central problem of what it calls the orchestration era.

This matters for how you think about a candidate’s experience. “Uses AI agents daily” and “can be trusted to delegate meaningfully to them” are not the same claim, and the gap between them is exactly where the report says most of the current difficulty sits.

Why orchestration is a different skill from prompting

Directing one agent well is largely a prompting and review skill: describe the task clearly, check the output, iterate. Directing several agents working in parallel is closer to managing a small team than to prompting a tool. Each agent needs a clear scope, what it owns, what success looks like for its piece, and what it should not touch. Ambiguity that a single agent might absorb without much damage gets amplified when several agents are acting on overlapping or adjacent parts of a system at once.

That is a materially different skill from being fast and comfortable with a single coding assistant, and it is not one that shows up automatically just because someone has used more than one AI tool.

What this means when you’re hiring

We think this adds a layer to the question we already ask by default, not does a developer use AI, but what have they learned to catch. For orchestration specifically, the useful follow-up is what happens when they are coordinating more than one agent at once, not just one.

A developer who has genuinely built this skill can usually describe how they scope work across agents so the pieces don’t collide, how they catch it when two agents make conflicting assumptions about the same part of a system, and where they’ve decided full delegation still isn’t warranted. A developer who has only used a single assistant, however fluently, generally can’t answer those questions with much specificity, because the failure modes are different and they haven’t run into them yet.

Where we’re being careful not to overstate this

The Stack Overflow data is clear that single-agent, closely supervised use is still how most developers work in practice, not multi-agent orchestration. This is a leading-edge skill right now, not yet a baseline expectation, and treating it as something every contractor should already have would be ahead of where the market actually is. What we do think is worth doing now is asking about it specifically for roles where it’s genuinely relevant, rather than waiting until it’s already the norm to start evaluating for it.