When not to use an agent

Most writing about agents assumes you should use one. Knowing when not to is what separates people who get value from people who spend their day supervising.

When the task is smaller than the explanation

If describing the change takes longer than making it, make it. Renaming a variable, fixing a typo, bumping a version number. The round trip costs more than the edit.

A rough test: if you could do it in under two minutes and you know exactly what to type, type it.

When you cannot check the answer

Agents are most useful where verification is cheap and fast. Code with tests is ideal, because the test either passes or it does not.

Where verification is expensive, the agent shifts work rather than removing it. A generated migration script for a database you cannot easily restore means you now have to read every line as carefully as if you had written it, without the understanding that comes from having written it.

When the problem is underspecified on purpose

Some work is thinking, and the output is a decision rather than code. Choosing an architecture, deciding what to build next, working out why users are unhappy.

An agent will produce a confident, well formatted answer to any of these. That answer is a plausible average of similar discussions in its training data, not a judgement about your situation. Use it to enumerate options, not to pick one.

When the context does not fit

If doing the task properly needs more of your codebase than fits in the context window, the agent works from a partial picture and will not tell you which part it is missing.

You can sometimes fix this by narrowing the task. If you cannot, you are asking for a guess.

When you are the bottleneck anyway

If every change needs your review before it lands, an agent producing five changes an hour when you can review two an hour has not helped. It has built a queue.

The honest signal

Notice when you are rewriting the agent's output rather than accepting it. Once you are doing that more often than not, for that kind of task, stop asking. You have learned something specific about where the tool works for you, and that is worth more than any general rule.

What this is not

None of this argues that agents do not work. It argues for using them where verification is cheap, the task is well specified, and the context fits. That is a large space, and it is where nearly all the value is.