Delegate the right work

An agent fails in two ways. It does the wrong thing confidently, or it does a thing so large that you cannot tell whether it is right. Both are delegation problems, not model problems, and both are fixed before the agent starts.

Size the task

The right unit is one thing you could review in fifteen minutes. A function, an endpoint, a migration plus its model change, a bug with a reproduction. If you would split the work into two pull requests for a colleague, split it for the agent.

Signs a task is too big: it touches more than a handful of files, it needs a design decision the agent cannot make, or you cannot state what “done” looks like in a sentence.

Write the spec

The agent’s context is everything it knows. Your instruction file covers the repo. The spec covers this task. Give it:

• What to change and why. The why lets it make small decisions the way you would.
• Where. File paths or function names. Do not make it search when you already know.
• What done means. A test that should pass, a command that should succeed, an output that should appear.
• What not to do. No new dependencies, do not touch the public API, keep the migration reversible.

A spec that fits in a paragraph is usually right. One that needs a page is two tasks.

Ask for a plan first

For anything beyond a one-file change, ask the agent to describe its approach before it writes code. You are checking for three things: it understood the task, it found the right files, and it is not about to do something expensive. Claude Code has a plan mode for this. Cursor has one too. In Codex, ask for the plan as the first step and approve it before letting it run.

Correcting a plan costs a sentence. Correcting a finished implementation costs a review and a rewrite.

Let it run, then stop it

Once the plan is right, let the agent work uninterrupted. Interrupting to redirect every step is slower than letting it finish and reviewing once. The exception is any action that is hard to undo: deleting, force-pushing, running a migration against a shared database, calling an external service. Every tool asks before those by default. Do not turn that off to save clicks. See human-in-the-loop.

Keep these for yourself

• Decisions with a long tail. Schema design, public interfaces, dependency choices. The agent will pick something reasonable and you will live with it for years.
• Anything you do not understand yet. If you cannot review it, you cannot delegate it. Do the first one by hand, then delegate the next.
• Reading the codebase. Delegating exploration is tempting and it produces summaries you have to trust. Read the code yourself for anything you will own.

Do this today

1. Take the next ticket and split it into fifteen-minute pieces before opening the agent.
2. Write the spec for the first piece as four bullets: what, where, done, not.
3. Ask for the plan. Correct it. Then let it run to the end.
4. Notice which piece you would not have been able to review. That one was yours.