When not to hand it to the agent
The cases where delegating costs more than doing it yourself — and the one that quietly costs the most.
Almost everything written about coding agents is about getting more out of them. This page is the other half, because knowing when not to reach for the tool is a large part of using it well, and it is the part that nobody has an incentive to publish.
When you cannot check the answer#
This is the real criterion, and it subsumes most of the others.
An agent's output is only as trustworthy as your ability to verify it. If you can run a test, read a diff, or reason about the result, you are fine. If you cannot — if it is a numerical method whose correctness you would have to take on faith, a concurrency change whose failure mode is a race you cannot reproduce, a security control you are not qualified to review — then delegating does not save you work. It converts work you understand into risk you cannot see.
The test
Before handing something over, ask: if this comes back subtly wrong, what would tell me? If the honest answer is "nothing until production", do it yourself, or get a second human.
When the requirements are genuinely unclear#
An agent will not tell you that your requirements are contradictory. It will pick an interpretation and implement it beautifully, and you will discover the contradiction at review — having burned the time twice.
Ambiguity is resolved by thinking, or by asking a person who knows. That work is not delegable, and dressing it up as a prompt does not change that. Write the paragraph from issue to pull request first; if you cannot, that is your signal.
When the problem is genuinely novel#
Models are strongest where the training data is dense. On the well-trodden — a FastAPI endpoint, a pandas transformation, a retry decorator — they are excellent and faster than you.
On the genuinely unusual — a scheduling algorithm specific to your domain, an optimisation with constraints nobody else has, a protocol you invented — output quality drops sharply and, more dangerously, confidence does not. You get the same fluent, well-structured, plausible code, and it is wrong in ways that take a long time to find.
A useful heuristic: if you cannot find three similar things on GitHub, expect the agent to struggle too.
When the change is smaller than the explanation#
If you can make the change in two minutes, making it takes two minutes. Writing a prompt precise enough to get it right, waiting, and reviewing the diff takes five, and the diff will contain a tidy-up you did not ask for.
This sounds obvious and is nevertheless the most common waste. The habit of reaching for the agent for everything is easy to form and expensive.
When you are the one who needs to learn it#
This is the one that costs most, and the cost is invisible for about six months.
Delegating everything you are unfamiliar with means you stay unfamiliar with it. Then a production incident lands in that area, the agent's suggestion does not work, and you are debugging a system you have never actually reasoned about — under time pressure, at the worst possible moment.
The people getting the most out of these tools are not the ones delegating the most. They are the ones who can tell, in about four seconds, whether a diff is right — and that judgement was built by writing the code, repeatedly, before they had a choice.
When the code is load-bearing and rarely touched#
Auth, billing, migrations, permissions, anything with money or personal data in it. Not because an agent writes these badly, but because the cost asymmetry is extreme: a small mistake in a payment path costs more than the entire time saving across a year of delegation.
Use the agent to review these. Have it read the diff, list what could go wrong, check for the failure modes. That direction of use — agent as second reader rather than first author — is undervalued and it is exactly right for high-stakes code.
When you are tired#
Not a joke. Reviewing generated code well takes more attention than writing code, because fluent wrong code triggers none of the friction that unfamiliar wrong code does. Late in the day, the reviewing gets worse while the generating stays exactly as good, and the ratio is against you.
Writing code tired produces obvious bugs. Approving code tired produces subtle ones.
What this adds up to#
Not "use it less". Use it for volume, boilerplate, translation, unfamiliar API surface, test generation, refactoring under a green suite, and reading unfamiliar code — where it is genuinely excellent and you would be silly not to.
Keep for yourself: the ambiguity, the novel, the unverifiable, the high-stakes, and the things you are still learning. That is a smaller list than it used to be, and it is also, not coincidentally, the list of things that were always the actual job.
Common questions#
Is this just gatekeeping about learning to code properly?#
No. The argument is narrower and practical: you cannot review what you have never understood, and reviewing is now the bottleneck. If you never build the judgement, the tool's ceiling becomes your ceiling — and it gets worse rather than better as the volume of generated code grows.
Should juniors use coding agents?#
Yes, with the same rule: delegate what you have done before, do what you have not. The risk is not that a junior uses the tool, it is that they use it to skip the repetitions that build pattern recognition. Using it to explain unfamiliar code, or to review their own, is unambiguously good.
How do I tell if I have got the balance wrong?#
Two symptoms. You approve diffs you could not have written, and you find yourself unable to debug your own codebase without the agent. Either one means pulling more work back for a while.
Get the Python agent pack
A battle-tested AGENTS.md, the review checklist, and the failure-mode cheat sheet for Python. One email, then occasional updates when the tooling shifts. No course pitch.
AGENTS.md now — no email needed.