AI pair programming vs delegating tasks to agents

AI pair programming vs delegating tasks to agents is a choice about where your thinking happens: in pairing you think alongside the agent in real time, and in delegation you do the thinking up front, write it down and judge the result later. Pairing needs your attention but very little preparation; you can start with a half-formed idea and shape it as the agent works. Delegation needs little attention during the work but a lot of preparation: a task the agent can finish without asking you anything, a scope, and a check that tells you whether it succeeded. Developers who get good results with agents tend to use both and switch deliberately, pairing on design and unfamiliar code, delegating mechanical and well-specified work. The mistake is drifting between them: delegating a task you have not thought through, or pairing on something so routine that you are just pressing approve. This page covers what each mode asks of you and the signals that tell you to switch.

What pairing asks of you

Pairing with an agent looks like pairing with a fast, well-read colleague who does not know your project. You stay in the session, read what it proposes and steer.

What it needs from you: attention, domain knowledge and quick judgment. The agent will offer a plausible approach; you are the one who knows that the team rejected that library last year, or that this endpoint must stay backward compatible. You catch wrong turns at the moment they are easy to undo.

How to do it well: ask for a plan before edits (Claude Code's plan mode is designed for this, and with any tool you can simply ask for one), approve the plan in small pieces, and run the tests yourself between steps rather than trusting the agent's summary. Keep a scratch note of decisions made in the session, because they vanish when it ends. Planning before agent edits covers the first step in more detail.

Where it pays: unclear requirements, unfamiliar code, design work, debugging where each finding changes the next question, and any change you would struggle to review cold. Where it does not: routine work you could specify in three sentences.

What delegation asks of you

Delegating means writing a task an agent can complete without you, then leaving it alone. The effort moves to the start and the end.

At the start, write the task so that a capable stranger could finish it: the outcome in one sentence, the files or area it may touch, the constraints that are not obvious from the code, and the check that decides success. For example: make parse_date accept ISO week dates; touch only dates.py and test_dates.py; keep the existing error messages; test_parse_iso_week must pass and the rest of the date tests must stay green. Writing tasks agents can finish goes further.

At the end, review as if a stranger wrote it, because in effect one did. Read the diff against the scope, rerun the check yourself and look for changes to tests or to files outside the area. Treat the agent's summary as a claim to verify.

Delegation pays when you have more well-understood work than attention: dependency bumps, test coverage for existing behavior, mechanical refactors, small bugs with a reproduction. It fails when the task description quietly depends on knowledge only you have, because the agent will fill the gap with a guess.

Signals to switch modes

Switch from pairing to delegation when you notice you are approving without reading, when the remaining work is a list you could write down, or when you can state the acceptance check. That is the moment to stop the session, write the rest as tasks and get your attention back.

Switch from delegation to pairing when a delegated task comes back wrong twice in different ways. That usually means the task was underspecified, not that the agent is weak. Also switch when the agent's notes reveal a design decision nobody has made, or when the result passes its check but you cannot tell whether it is right. Sit with it, find the missing piece, then decide whether to delegate again.

A delegated task should also be allowed to stop. If the agent hits a decision outside its brief, the right outcome is a clear question recorded on the task, not a guess. When agents should stop and ask covers how to make that the default.

Finally, notice the cost of switching. Each handoff loses context. Write a two-line note at every switch: what was decided, and what is next.

A worked example: one feature, both modes

Say you are adding CSV export to an admin dashboard.

Pair on the design. In an interactive session, look at how existing exports work, decide the column format with the agent, and settle the edge cases: dates as ISO strings, money in cents, empty fields as blanks. Record those decisions in the task or a decisions file. This is the part where your judgment matters most and the requirements are still moving.

Delegate the mechanics. Split the rest into tasks with their own checks: add the row formatter with unit tests for each edge case; add the endpoint with an integration test; add the export button with a component test. Each task names its files, so two agents could take two of them without colliding.

Review with the decisions in hand. When the tasks come back, check each against its scope and the recorded decisions, then run the whole feature yourself. If one task comes back wrong, pair on that one rather than re-delegating blindly.

The pattern generalizes: pair where the decisions are, delegate where the decisions are already made, and review against what was decided. Reviewing agent output covers that last step.

QUESTIONS

Is AI pair programming faster than writing the code yourself?

It depends on the task and on you. For unfamiliar code and boilerplate, many developers find it faster. For code you know well, reviewing the agent's suggestions can take as long as writing it. Measure on your own work: time from start to a reviewed, passing change, not time until the agent says it is done.

How detailed should a task be before I hand it to an AI agent?

Detailed enough that the agent never has to guess a decision only you can make. In practice that means the outcome, the files it may touch, non-obvious constraints and a named check that must pass. If you cannot write the check yet, the task is not ready to delegate; pair on it first.

What should I do when a delegated agent task keeps failing?

Stop re-running it. Two different wrong results usually mean the task is missing information, not that the agent needs another try. Open an interactive session, find the missing decision or constraint, write it into the task, and only then delegate again, or finish it yourself if it turned out to be design work.

RELATED GUIDES

• How to create a project card in BRAIN FLUID Desk

RELATED HARNESS PAGES

• Interactive vs unattended AI coding sessions Interactive vs unattended AI coding sessions: terminal pairing, single unattended tasks and authorized multi-task runs compared on authority and failures.
• How to write a task an AI coding agent can finish How to write a task an AI coding agent can finish: one outcome, a scope, dependencies, completion criteria and the check that proves them.
• Read-only first: planning sessions before an agent edits code Read-only first: planning sessions before an agent edits code, using Claude plan mode or a Codex read-only sandbox, then a scoped task.
• human review of agent output Human review of agent output: what to inspect before accepting AI changes, and how recorded outcomes make the review honest.