When to let the agent drive and when to take the keyboard back

A tech lead at a gaming company described watching one of his engineers lose an hour in a way that taught the whole team something. The engineer had a gnarly problem, a subtle bug that lived in the interaction between three systems and required holding a lot of context in your head at once. He handed it to the agent and let it drive, prompting and re-prompting as the agent produced attempt after attempt that did not quite work. An hour in, he took the keyboard back, thought about it himself for fifteen minutes, and fixed it. The agent had been the wrong tool for that particular problem, and the skill the engineer was still learning was not how to prompt better. It was when to stop letting the agent drive and do it himself.

Who should drive depends on the task

Pairing, between humans, always involved a fluid question of who should be at the keyboard. The stronger person on a given problem drove, and it switched naturally as the problem changed. Good pairs managed this without thinking, matching the driver to the task, because it was obvious that different problems suited different people.

Pairing with an agent has the same question and it is harder, because the agent’s strengths and weaknesses are less intuitive than a human colleague’s. The agent drives well on some tasks. Well-specified work, familiar patterns, boilerplate, things where the answer is a known shape, it is fast and good. On other tasks it drives badly. Deep bugs that require holding a large mental model, problems with subtle context that is hard to convey in a prompt, work where the hard part is understanding rather than typing, it flails, producing attempt after attempt that misses the point. The trouble is that when the agent is the wrong driver, it does not tell you. It keeps producing plausible attempts, and you keep prompting, and an hour disappears into a loop that a human would have exited by simply thinking. Knowing when to take the keyboard back is a real skill, and it is not the same skill as prompting well. It is knowing which problems the agent is bad at, and having the discipline to switch drivers when you are in one.

The failure mode is specific and common. The engineer stays in the passenger seat too long, because taking over feels like giving up on the tool, and because each new attempt looks like it might be the one. Meanwhile the actual path to the answer was to stop, hold the problem in your own head, and work it. The agent was not going to get there, and it was never going to say so.

Learn where the agent is the wrong driver

The lesson is that engineers have to learn when the agent should drive and when they should, because the agent will not surrender the keyboard on its own, and staying with the wrong driver wastes real time. This judgment is a skill worth developing deliberately.

How engineers decide who should drive.

Let the agent drive well-specified, familiar, pattern-shaped work, where it is genuinely fast and good.
Take the keyboard back for deep bugs and problems that require holding a large mental model the prompt cannot carry.
Set a limit on attempts, so a loop of near-misses becomes a signal to switch drivers rather than an invitation to prompt again.
Notice when the hard part is understanding, not typing, since that is where the agent is weakest and you are needed.
Treat taking over as a normal move, not a failure, so the switch happens when it should instead of an hour late.

The skill is not just prompting the agent well. It is knowing which problems to hand it and which to keep, and switching quickly when you have handed it the wrong one.

How we think about it at Density Labs

The hour lost to the wrong driver is a common and quiet cost of pairing with agents, and it is not a prompting problem. The engineer prompted fine. The mistake was staying in the passenger seat on a problem the agent was structurally bad at, waiting for an attempt that was never coming, when the answer was to take over and think. The agent does not know its own limits, and it will happily keep driving off the road.

When we help teams work well with agents, we treat the driver question as a skill to build, not an instinct to assume. Knowing when to let the agent drive and when to take the keyboard back is one of the highest-leverage habits a team can develop, and it is learned, not given.

The agent is a good driver on the right roads and a bad one on others, and it will never pull over. Knowing when to take the wheel is your job.