The Worst Tasks to Give an AI Coding Agent

Anything without a checkable definition of done

Agents rely heavily on feedback, such as tests passing, types checking, or a lint rule being satisfied, to steer toward a correct answer. Tasks with no objective success criterion, like improve the architecture or make this code cleaner, give the agent nothing to converge against, so it optimizes for looking reasonable rather than being correct.

The result is often a confident rewrite that changes style without improving substance, or introduces a new set of problems while removing an old, familiar set. Vague instructions produce vague, unverifiable results almost by definition.

High-stakes, low-visibility decisions

Security-sensitive code, authentication logic, payment handling, and anything involving access control deserve extra caution, because the failure mode is not a crash you notice immediately but a subtle gap an attacker finds later. An agent trained on general code has no special ability to reason about your specific threat model.

The same caution applies to database migrations and anything touching production data directly, since those operations are hard or impossible to reverse. A bug here is not caught by a code review that only reads the diff; it is caught by someone who understands the operational consequences of running it.

• Vague, unmeasurable requests like 'clean this up'
• Authentication, authorization, and payment logic
• Irreversible database migrations against production data
• Architecture decisions with long-term organizational consequences
• Anything requiring context that lives outside the repository

Tasks that need context that isn't written down

A surprising amount of engineering judgment depends on knowledge that never made it into the codebase, like a conversation with legal about a data retention rule or an incident postmortem that led to an unusual defensive check. An agent cannot infer any of that from source files alone.

For these tasks, the agent is not the wrong tool because it is incapable, but because the information it would need to succeed simply is not available to it. Recognizing that gap in advance saves a review cycle spent catching a mistake that was predictable from the start.