Developer & Tech
When Not to Use an AI Coding Assistant
By Jim Vernon, Editor, AI Intelligence International · Published 26 March 2026 · Reviewed against our editorial standards · About the author
Coding assistants are strongly net-positive across most day-to-day work, which makes the exceptions easy to miss. The exceptions are where the largest costs occur.
This article identifies the situations where reaching for the assistant reliably produces a worse outcome than not, and what to do instead in each.
Key takeaways
- When you do not yet understand the problem: Generation resolves an underspecified problem by picking an interpretation.
- In unfamiliar territory you will own: Learning a codebase or a framework by accepting suggestions produces the ability to produce output and not the ability to maintain it.
- Anything security-critical: Cryptography, authentication flows, session handling, permission models and input sanitisation are all areas where the median public example is inadequate and the model reflects the median.
- Debugging something you cannot describe: An assistant can only work from your description.
When you do not yet understand the problem
Generation resolves an underspecified problem by picking an interpretation. That interpretation then anchors your thinking, and you end up debugging a solution to a problem you had not finished defining.
The cost is invisible because the output looks like progress. You will discover it two days later when the design turns out not to fit.
Write the problem statement first, by hand, in prose. Then generate.
In unfamiliar territory you will own
Learning a codebase or a framework by accepting suggestions produces the ability to produce output and not the ability to maintain it.
If you will be on call for this system, the first few weeks of work in it should be slower and more manual than they need to be. That slowness is the investment.
Once the mental model exists, assistance becomes genuinely accelerative in the same area.
Anything security-critical
Cryptography, authentication flows, session handling, permission models and input sanitisation are all areas where the median public example is inadequate and the model reflects the median.
The failure mode is code that looks correct to a non-specialist reviewer. Nothing about it signals danger.
Use published, audited implementations and framework primitives here. This is the one area where writing less original code, generated or otherwise, is the correct answer.
Debugging something you cannot describe
An assistant can only work from your description. If you cannot characterise the failure, you will get plausible suggestions for a different bug, and you will spend an hour ruling them out.
Reduce first. Get to a minimal reproduction by bisection, and only then describe it. At that point assistance becomes very effective.
The reduction is the actual debugging work, and it does not delegate.
Performance work
Optimisation without measurement is guessing, and a model asked to make something faster will apply plausible general optimisations to code whose bottleneck is somewhere else.
Profile first. Once you know which function accounts for the time, generated suggestions for that specific function are useful.
Be particularly wary of suggestions that increase complexity for a theoretical gain. Those are the hardest to revert later.
When the code will outlive your attention
Code you will hand over, or return to in a year, needs to be more conventional and less clever than code you are actively maintaining.
Generated code is often idiomatic in the abstract and inconsistent with the specific codebase, which is exactly the combination that makes future maintenance harder.
Spend the extra time aligning it. The alignment is what makes it maintainable, not the correctness.
Worked example: three tasks, three decisions
Task one, a data transformation between two known formats with tests already written. Fully delegated, verified in four minutes, no issues. This is the ideal case.
Task two, an intermittent failure in a background job with no reliable reproduction. Two attempts at describing it produced three plausible and irrelevant suggestions. Abandoned assistance, spent ninety minutes bisecting to a race condition in a lock acquisition, then used the assistant to write the fix in five minutes.
Task three, a password reset flow. Generated version used a predictable token derived from a timestamp and stored it unhashed. Discarded entirely and used the framework's built-in flow.
The pattern across all three: delegate the specified and verifiable, retain the exploratory and the dangerous.
Four situations where they cost more than they save
Security-critical code — authentication, authorisation, cryptography, payment handling — where a plausible-looking mistake is expensive and hard to spot in review. Use vetted libraries and human review here.
Unfamiliar territory you need to genuinely learn. Accepting working code you do not understand leaves you unable to debug it at the worst possible moment, and the learning never happens.
Novel architecture, where the model's pull towards conventional patterns actively works against the reason you are deviating. And subtle concurrency, where correctness depends on invariants that are invisible in any single file.
The signal to switch modes
When you are on the fourth round of corrections, stop. Long correction loops mean the problem needs a decision rather than more generation, and the decision is yours.
When you cannot explain the produced code to a colleague, do not merge it. That test is more reliable than any review checklist, and it costs one minute.
When the task is under ten lines and you know exactly what to write, just write it. Prompting, reading and correcting is slower than typing for small, well-understood changes.
Frequently asked questions
Do these exceptions shrink as models improve?
Some do — invented APIs and simple correctness have improved substantially. The exceptions rooted in your own understanding, like unfamiliar territory and undescribed bugs, do not, because the limiting factor is on your side.
Is it worth writing code manually to stay sharp?
For skills you rely on, yes, periodically. Reading and debugging unfamiliar code matters more than writing it from scratch, and both decay without practice.
How should teams handle security-critical code?
Require human authorship or explicit specialist review for a defined list of areas, and prefer audited library implementations over any original code in those areas.
What about generated code in prototypes?
Ideal use, with one caveat: prototypes become production more often than anyone plans for. Label them clearly and assume the code will need a rewrite rather than a promotion.
Do assistants slow down experienced developers?
Sometimes, on unfamiliar or subtle work, because review of plausible-but-wrong code takes longer than writing it. Notice the pattern and switch modes.