After a few months with agents, it’s easy to fall into the trap of throwing everything at it.

But some tasks really shouldn’t be delegated — not because the agent isn’t capable, but because the risk/reward ratio is wrong.

One: anything touching production data

Running SQL against a production database — even SELECT — I won’t trust an agent with. Claude won’t intentionally break things, but it might scan a full table because it misunderstood the query.

Production config changes, deployment tweaks — I do those myself. The time it takes to roll back one mistake is more than the time I saved by automating.

Two: security-sensitive changes

Auth logic, permission checks, encryption — I never hand these to an agent. Not because Claude writes bad code, but because when this kind of code fails, it fails big, and the vulnerability is often invisible.

My approach: let the agent write a draft, but I review every line myself. Then I get a second reviewer. Trust doesn’t stack — two pairs of eyes are better than one.

Three: decisions that need human judgment

“Should this button go on the left or right?” “Would users understand this error message?” “Should this API response include an extra field?” — these don’t have right or wrong answers. They have appropriate ones.

Agents don’t have product sense. They don’t have user context. When I ask it to choose between two approaches, it picks the one that looks best technically, not the one that works best for my users.

Four: vague “take a look”

“See what can be improved in this project” — no scope, no criteria, no stopping condition. Claude reads hundreds of files, fills its context, and hands me a generic report.

When I want a code review, I give it a scope: “Look at error handling in src/api/ and find potential null pointer risks.”

Five: cross-system coordination

Change service A, wait for B to deploy, then check C’s response — agents can’t handle this flow. Not because they lack technical ability, but because each step has unpredictable dependencies. The agent doesn’t know when to wait and when to proceed.

That said, the boundary of “unsuitable” isn’t fixed. As I learn my agent’s limits, some tasks I previously kept to myself become fair game.

One piece of advice I follow: err on the side of caution. I started with low-risk refactoring, built trust slowly, and didn’t let it touch production config on day one.

Article Link: