When not to use AI coding tools — five situations where they cost you time

1. You do not understand the problem yet

An assistant will happily produce a confident implementation of a problem you have not finished specifying. The code looks like progress and commits you to a shape you had not chosen. When the requirements are still unclear, writing prose about the problem beats generating code about it.

2. Security-critical code you cannot review properly

Authentication, cryptography, permission checks, anything handling payment. The failure mode is subtle and the generated version usually looks correct. If you are not able to review it line by line with real understanding, generating it is worse than writing it slowly.

3. You are learning the language or framework

The fastest way to not learn something is to have it written for you at the moment you would otherwise have struggled. The struggle is the mechanism. Use the assistant to explain, not to produce, while you are building the mental model.

4. Debugging something you cannot reproduce

Assistants are strong at explaining a stack trace and weak at reasoning about a bug that appears once a day on one machine. Those need instrumentation, logs and a hypothesis, and asking a model for a plausible cause mostly generates plausible causes.

5. The codebase has conventions the model cannot see

Every mature codebase has rules that live in people's heads — this module is being deprecated, that pattern caused an incident, this abstraction is load-bearing. Repository context helps, but it does not capture institutional memory. In those areas, generated code is syntactically fine and organisationally wrong.

What this is not an argument for

None of this is a case against the tools. For boilerplate, tests, refactors, unfamiliar APIs and the first seventy percent of almost anything, they are a straightforward win. Knowing the five cases above is what lets you use them aggressively everywhere else.