When not to use AI coding agents

You should not use AI coding agents for work whose constraints live outside the repository, changes where reviewing takes longer than writing, or anything where being subtly wrong is expensive.

Work whose constraints live outside the repository

Agents work best when the problem is described in code and tests. When the real constraints sit in spreadsheets, compliance documents, or a colleague’s head, the agent lacks the context it needs to do useful work. You end up reviewing outputs that look plausible but miss an external rule or dependency, which is harder to spot than an obvious bug because the agent did not know the rule existed in the first place.

A common example is a database schema migration that must satisfy a legal retention schedule stored in a PDF. The agent can write the SQL to add the column, but it cannot infer the retention policy from the PDF, so the migration may drop data that must be kept or keep data that must be deleted. Reviewing the SQL alone will not reveal the error until an auditor flags it weeks later.

Another case is a deployment process that requires sign-off from a security team whose approval matrix lives in a Confluence page. The agent can propose the change, but it cannot verify the sign-off chain, so the change stalls in review while someone manually checks the matrix. The agent saved you typing, but it did not save time.

Changes where reviewing takes longer than writing

If the agent’s output requires more effort to verify than to write, the agent is not saving effort. This happens when correctness must be provable, not merely plausible. Cryptographic code is the canonical example: a one-line change to a hash function can silently break security, and proving it correct requires a formal analysis that takes hours. The agent wrote the change in seconds, but the review took days.

Performance-sensitive systems also fall into this category. An agent can suggest a loop optimization that looks faster in a microbenchmark but degrades real workloads due to cache effects. Profiling the change to confirm it meets the SLA can take longer than writing the original loop, especially if the performance regression only appears under load. The agent did not make you faster; it made you slower to validate.

Regulated environments where every change must be traceable to a requirement are another example. If the agent writes a change that must be linked to a specific clause in a standards document, reviewers must manually trace the code to the clause. That tracing often takes longer than writing the change, because the agent cannot embed the trace automatically. The agent produced code, but the compliance work is yours.

Anything where being subtly wrong is expensive

Subtle errors are expensive when they propagate to many users before detection. Security vulnerabilities in widely used libraries are the clearest case. An agent can introduce a subtle timing side channel in a serialization routine, and the bug may not be noticed until an attacker exploits it. The cost of fixing it is high because the change affects every downstream user and requires coordinated patching. The agent did not create the bug on purpose, but it did not prevent the bug either.

Data loss is another example. An agent can rewrite a batch job to run faster, but if the rewrite silently drops records that do not match the new schema, the data loss may go undetected until the next quarterly report. The agent optimized for speed, but the business paid for lost data. In domains like finance or healthcare, such errors can trigger fines or legal exposure, which dwarfs the agent’s time savings.

API contracts that change across major versions are also risky. If an agent rewrites a client to use a new endpoint but gets the pagination parameters subtly wrong, the client may fetch only half the data. The bug appears as missing records in production, not as a test failure. Catching it requires integration tests that cover the full contract, which the agent did not write. The agent moved faster, but the system moved slower to recover.

The strongest objection

You might argue that agents should improve over time and eventually handle these cases. That is true in principle, but it ignores the cost of being wrong today. If the agent introduces a subtle bug in a critical system, the immediate cost of fixing it can exceed the cumulative time saved by using the agent for years. The objection assumes the agent will eventually pay for itself, but it does not account for the risk that the first mistake is unrecoverable.

Another objection is that you can mitigate the risk with better tooling or stricter prompts. Better tooling helps, but it does not eliminate the fundamental gap: the agent lacks the tacit knowledge that lives outside the repository. Stricter prompts can reduce obvious mistakes, but they cannot inject the missing context. The objection treats the symptom, not the cause.

The final objection is that human review catches these issues anyway, so why not let the agent try. The problem is that human review is already a bottleneck. If an agent’s output routinely requires more review effort than writing the change yourself, you have not reduced your workload; you have redistributed it. The agent did not make you more productive; it made you review more.

What to use instead

For work with external constraints, pair the agent with a human who owns the context. The human provides the missing rules, the agent writes the code, and the human verifies the constraints are met. This removes the gap without giving the agent responsibility it cannot handle.

For changes where review time dominates, write the change yourself and let the agent assist with isolated tasks like refactoring or test generation. The agent’s output is smaller and easier to review, so the total time can go down even if the agent does less work. The agent complements your effort instead of replacing it.

For cases where subtle errors are expensive, add formal verification or property-based testing before the change ships. These techniques catch classes of bugs that review alone cannot, and they are not something an agent can automate today. The verification step is your insurance policy against the agent’s blind spots.

If you still want an agent to handle these cases, limit its scope to parts of the change where correctness is less critical. Let it write the boilerplate or the happy path, and keep the sensitive parts for yourself. The agent reduces typing without increasing risk, which is the best trade-off you can ask for.

When the agent’s cost exceeds its value

Agents shine when the problem is self-contained in code and tests, and when the cost of being wrong is low. Outside that zone, the agent’s outputs become a liability. The decision to use an agent should be made case by case, not as a blanket policy. If the constraints, review time, or error cost exceed the agent’s savings, do the work yourself or find a different tool.

The most reliable signal is whether the agent’s output can be reviewed in less time than it took to write. If the answer is no, the agent is not helping. Reconsider its role before it becomes an obstacle.

The agent’s output should be reviewable faster than it was produced, or the agent is not saving time.