When a developer first runs several AI coding agents at once, the excitement is about speed. When they run five or six — or ten — the story changes. The agents do not get tired or lose the thread. The person coordinating them does. Suddenly the hard part is not writing code or even reviewing it. It is keeping track of who is doing what, and remembering where you were when one of them comes back with a question.
That problem has a familiar shape. It is a management problem. And management is something the industry already knows how to do.
Some developers you brief by phone. Others need a whiteboard.
Anyone who has led a team of engineers knows they are not interchangeable. Some developers you can call on the phone and talk through an entire feature. They hold the design in their head, you describe the goal, and they run with it. Others cannot work that way — they need a shared screen or a whiteboard, and you draw the flow out together before anything gets built.
Neither is the better engineer. They need different modes of collaboration. The mistake a new manager makes is forcing everyone into one mode — usually the one that suits the manager.
AI agents are just as varied
The more we work with coding agents, the more that human experience transfers straight over. Some agents you can direct by talking. A lot of real development — especially architectural decisions and working out how a flow should move through an application — is genuinely better done out loud, before any code exists. You brainstorm it, you talk it through, and the agent runs with the direction.
And then you hit a wall. There is always a point where you need to see the thing. You need the application actually running in front of you, or a specification document open, or a UI you can test against. Voice carries you a long way and then it stops carrying you. Pretending otherwise just slows the work down.
The lesson most teams get wrong
The instinct, when a team adopts agents, is to standardize on a single interface. Pick the terminal, or pick the dashboard, and make everyone live there. That is the equivalent of managing every developer the same way — and it leaves half the value on the table.
The teams that get the most out of agents do the opposite. They make it easy to move between modes without friction: talk the problem through when thinking is the bottleneck, switch to a full screen when you need to see the app, reach in from a browser or a phone when you are away from the desk. The switching itself is the capability.
This is the principle behind DevThrottle, the agent-orchestration tool we have been building. One of its pieces is Wingman — a voice layer that sits on top of a running agent, summarizes what it is doing, and reads that back to you in natural speech, so you can stay in the loop while walking or between meetings. Wingman is not meant to replace the screen. It is one mode among several, useful for some of the work, some of the time. The point is that when you need to see something, you switch — and the workflow does not punish you for it.
Why this matters for adoption
If your organization is rolling out agentic development, the tooling question is not “which single interface should everyone use.” It is “can people move between voice, screen, and remote access as the work demands.” Teams that answer yes keep their engineers in flow — a conversation can start on a walk and finish at the desk. Teams that answer no end up with a fast tool that only works when someone is chained to one screen.
Managing AI agents well is turning out to be less about the AI and more about applying what good engineering leaders have always known: meet each contributor in the mode where they do their best work. The agents are new. The management lesson is not.
For the builder’s-eye version of this — the day-to-day of running a fleet of agents by voice and screen — see our companion piece on the DevThrottle blog: Some agents you can manage by voice. Others need a whiteboard.