There is a real cost to delegating: writing the request, reading the result, and correcting it. For a lot of work that cost is trivially worth it. For some work it exceeds the work.
Recognising the second category early is worth more than any prompting technique.
1. You already know exactly what to type#
If the change is fifteen lines and you can see them in your head, type them. Describing them takes longer than writing them, and then you still have to read the result to check it matches what you already decided.
This sounds obvious and is violated constantly, because delegating has become a reflex.
2. The problem is that you do not understand the system#
An agent can explain the system to you. It cannot understand it for you.
If you are stuck because you do not know why the retry logic is shaped that way, asking for a fix produces a change to code you still do not understand — and you are now the reviewer of a diff in an area where you cannot tell right from wrong.
Use the agent for what it is good at here: explain this to me, cite the lines. Then make the change yourself, or delegate it once you can evaluate the answer.
3. The decision is a product decision#
"Should deleted users keep their order history" is not a technical question. An agent will answer it anyway, and the answer will be reasonable, and it will be a decision made by nobody.
Anything that changes what the product does for a user belongs to a person. Delegate after the decision, not instead of it.
4. It has been wrong twice in the same place#
Two failed attempts on the same problem is a strong signal that the agent's model of the situation is wrong, and a third attempt will usually be a variation of the second.
Stop. Either you are missing context it needs — in which case supply it and restart fresh — or the problem is in the category above, and you need to understand it yourself first.
The failure mode to avoid is the fifth attempt, by which point the codebase has accumulated four abandoned partial fixes.
5. The verification is harder than the implementation#
Some code is easy to write and hard to check: concurrency, floating-point maths, security boundaries, anything where a plausible-looking implementation and a correct one are indistinguishable by reading.
For that code, delegation moves the effort from writing (where you have leverage) to reviewing (where you have less). If you cannot construct a test that would catch a subtle error, you should be writing the code yourself and thinking carefully while you do it.
6. It is genuinely novel#
Agents are extraordinary at things that resemble things. On a problem with no precedent — a protocol nobody has implemented, an algorithm specific to your domain — output will look like the nearest familiar pattern, which is exactly wrong.
You can still use it: for the surrounding scaffolding, the tests, the plumbing. Just not for the part that is actually new.
Where it clearly pays#
For symmetry, the situations where delegating is close to free:
- Volume with a clear pattern. Forty call sites to update the same way.
- Unfamiliar syntax with a known goal. You know what the regex should match.
- Boilerplate you can verify at a glance. Scaffolding, fixtures, plumbing.
- Investigation. Where is X used? What calls this? What changed here and when?
- First drafts of tests, which you then read carefully for the failure modes in lesson 4.
- Explaining code you did not write, with citations.
- Mechanical migrations, file by file, with a check between each.
The pattern: delegate where verification is cheap and the work is large. Keep what needs judgement, or where checking the answer costs as much as producing it.
The honest version#
Nobody gets this calibration right by reasoning about it. You get it by noticing, after the fact, that a task took two hours of back-and-forth and would have taken twenty minutes by hand — and then remembering the shape of that task next time.
Keep the observation. That is the whole skill.
Next, and last in this track: setting up an agent on a repository you have never seen.