Stop Watching the Cursor: Managing Coding Agents Like Delegated Work

There's a specific moment I watch for when a team adopts coding agents. It's the moment an engineer kicks off a task, and then... sits there. Watching the terminal scroll. Reading every tool call. Occasionally interrupting to say "no, not that file."

That engineer is paying for delegation and receiving entertainment.

The big shift in coding agents over the past year isn't model quality — it's the move from synchronous pair-programming to asynchronous delegation. Claude Code, Devin, and GitHub Copilot's coding agent all now support a mode where you hand off a task, walk away, and come back to a pull request. The tooling made this shift months ago. Most teams' working habits have not.

The skill that transfers is management, not prompting

Here's my central claim: working with background agents is a management problem wearing a tooling costume. Every failure mode I've seen in async agent adoption has a direct analog in delegating to a human engineer, and every fix comes from the same playbook.

Agents fail on vague tasks. So do new hires. The fix is the same: a written task definition with acceptance criteria. "Fix the flaky checkout test" produces garbage from an agent for the same reason it produces a week of thrashing from a junior — nobody defined what done looks like. Teams that get value from async agents write tickets an agent can execute: the symptom, the suspected area, what a passing result looks like, what's out of scope.

Agents that get course-corrected every ninety seconds never build momentum. Neither do engineers whose manager hovers. If you find yourself interrupting an agent constantly, the problem is almost never the agent — it's that the task was underspecified, or too big, or you delegated something you actually wanted to do yourself.

And agents, like people, need their output reviewed at a level matched to risk. Nobody line-reviews a senior's config change and rubber-stamps their auth refactor. Same logic applies: dependency bumps and mechanical refactors get a skim and a green CI run; anything touching money, auth, or data gets a real human review.

What to change in your workflow, concretely

Three practical moves I'd make in any team adopting background agents:

1. Budget review time before you budget agent time. An async agent's output is a PR, and PRs are only worth what your review capacity can absorb. If your team merges 40 PRs a week today and agents will add 20, someone has to review those 20. Decide who, and put it on their calendar, before you scale up delegation. Otherwise you've built a queue, not a capability. The general rule from teams doing this well: delegate tasks that take the agent more than 15 minutes and don't need mid-flight steering — well-scoped bug fixes, dependency upgrades, repetitive multi-file migrations.

2. Keep a delegation log for two weeks. Every task handed to an agent: what was asked, what came back, accepted/reworked/discarded. This is the cheapest instrumentation you'll ever build, and it answers the question executives actually ask ("is this working?") with data instead of vibes. It also teaches your team, faster than any training session, which tasks are delegable in your codebase — because that boundary is different everywhere and nobody can tell you where yours is.

3. Make handoff quality a review topic. When an agent PR comes back wrong, the retro question isn't "why is the agent dumb," it's "what was missing from the handoff?" Usually the answer is context — an undocumented convention, a hidden dependency, a constraint that lived in someone's head. Fix the handoff artifact (the ticket template, the repo's agent context file), and the next delegation goes better. This compounds. Complaining doesn't.

The uncomfortable part

The reason this transition is hard has nothing to do with tooling. Synchronous copilot use let engineers keep their identity as the person doing the work, with the AI as a fancy autocomplete. Async delegation forces a different identity: you are now someone who scopes work, hands it off, and judges the result. That's a management skill set, and plenty of strong ICs have never had to build it — some became strong ICs specifically to avoid it.

Which means your rollout plan needs to treat this as a skills gap, not a tools gap. The engineers who take to background agents fastest are usually your tech leads, because they already know how to decompose work and write an unambiguous handoff. Pair them with the skeptics. The skill spreads by example.

The takeaway

If your team has background agents available and everyone's still watching the cursor, you haven't adopted async agents — you've adopted a slower IDE. Delegation is the product. Write handoffs like you're briefing a capable contractor, size your review capacity honestly, log what comes back, and treat every bad result as a handoff bug first. The teams that learn to manage agents will outpace the ones that merely operate them.