When NOT to Use an AI Coding Assistant

// In plain English

An AI coding assistant is fantastic at a huge range of tasks — scaffolding a new component, writing tests, explaining unfamiliar code, churning out boilerplate. But it is not free. Every line it writes is a line you have to read, understand, and trust before it ships. For some tasks that review cost is tiny and the speed-up is enormous. For others, reviewing the AI's output carefully takes longer than just writing the code yourself — and if you skip the review, you ship bugs you didn't even know were there.

Here's the everyday analogy. Imagine you have a brilliant but overconfident intern. Ask them to draft a long, repetitive report and they save you an afternoon. Ask them to fix the one specific number on page three that you already know is wrong, and you'll spend more time explaining the context, checking their edit, and undoing their 'helpful' extra changes than if you'd just fixed it yourself. The intern isn't bad — they're just the wrong tool for that particular five-second job.

This article draws the line most tutorials skip. Almost every guide sells you on what AI coding tools can do. This one is about the situations where reaching for the assistant actively hurts: where it slows you down, hides bugs, or produces code you can't safely review. Knowing when not to use the tool is what separates people who are faster with AI from people who only feel faster.

// Why it matters

The core idea is a single trade: the time you save writing versus the time you spend reviewing. An AI assistant shifts work from authoring to verifying. That's a great trade when authoring was the expensive part (lots of repetitive code) and verifying is cheap (you can eyeball it). It's a terrible trade when the reverse is true — when the code is short but the correctness is subtle, contextual, or dangerous to get wrong.

Why does a builder care? Because the failure mode is quiet. A bad AI suggestion rarely looks bad. It is fluent, plausible, well-formatted, and confidently wrong. Plain-looking code that compiles and seems fine is exactly the code humans rubber-stamp. The danger isn't that the AI obviously fails — it's that it subtly fails while looking like success, and you accept it because reviewing carefully felt like wasted effort on 'such a small change.'

• Review debt is invisible. Accepting a suggestion takes one keystroke; truly understanding it takes minutes. People pay the keystroke and skip the minutes, then inherit bugs nobody chose to write.
• Plausible ≠ correct. The model is optimized to produce text that looks like working code, not text that is correct for your specific, unstated context. Those two goals usually overlap — until they don't.
• The cost lands later. Time 'saved' by skipping review reappears as a production incident, a security hole, or an afternoon of debugging a one-line change you never properly read.

So the question for any task isn't 'can the AI do this?' (it usually can produce something). It's: 'will checking its answer cost me less than writing the answer myself?' When the honest answer is no, you should write it yourself — and this article is a catalog of when the answer is reliably no.

// How it works: the review-cost trade

To decide whether a task is a good fit, picture every coding task on two axes. One axis is how expensive it is to write by hand (effort, volume, tedium). The other is how expensive it is to verify the AI got it right (subtlety, blast radius, how much hidden context the correct answer depends on). The AI wins cleanly only in one corner.

Walk a task through a quick mental pipeline before you reach for the assistant. The decision isn't 'AI or not' in the abstract — it's a per-task call you make in a few seconds once you've internalized the trade.

The middle question is the one people skip: can you even review the output? If the AI writes code in a domain you don't understand — an unfamiliar language, a security protocol, a numerical algorithm — you can't tell correct output from confident nonsense. In that case the AI hasn't saved you work; it has handed you code you must now learn the domain to verify, which is strictly worse than learning the domain and writing it yourself.

// Concrete categories where AI underperforms

Abstract advice is easy to nod along to and hard to apply. Here are the specific, recurring categories where reaching for the assistant tends to cost more than it saves. None of these are absolute bans — they're the situations where you should default to writing it yourself and only invoke the AI deliberately.

1. Tiny, obvious edits you already know

Changing a default value, renaming a variable, flipping a boolean, fixing a typo in a string. You already hold the entire correct answer in your head. Prompting the AI, waiting, and reading its diff is pure overhead — and the assistant loves to 'tidy up' nearby code you didn't ask it to touch, turning a one-line change into a diff you now have to audit. Just type it.

2. Security-critical and cryptographic code

Auth flows, password hashing, token handling, anything cryptographic. This code is short, looks simple, and is catastrophic when subtly wrong — the exact worst-case quadrant. Models happily emit plausible security code (a homemade encryption routine, a flawed comparison, a missing constant-time check) that passes a casual read and fails in production. Security code should come from vetted libraries and careful humans, not generated and skimmed.

3. Unfamiliar domains you can't review

A language, framework, or problem space you don't know well enough to spot a wrong answer. The AI will confidently produce something, but you've lost your only safety net: your own judgment. If you can't tell good output from bad, the generated code is a liability, not a shortcut. (Using the AI to learn the domain — asking it to explain, with you verifying against docs — is fine. Shipping its code unread is not.)

4. Deeply contextual one-line fixes

The hardest bugs are one-character fixes that depend on context spread across the whole system — a race condition, an off-by-one tied to a specific data invariant, a fix that's correct only because of something three files away. The model can't see that hidden context, so it pattern-matches to a fix that looks right and breaks the invariant. You'd spend longer explaining the situation than fixing it.

5. Brittle config and infrastructure

YAML pipelines, Terraform, Kubernetes manifests, Dockerfiles, regexes for production. These are dense, unforgiving, version-sensitive, and full of subtle keys that look valid but silently do nothing or the wrong thing. The AI can't run your cluster to check, and a wrong config often fails far from where the mistake lives. Generate a draft to learn the shape if you must, but never paste it unverified.

// A quick decision checklist

You won't run a formal analysis on every edit — that would be slower than just coding. Instead, internalize a five-second gut check. Lean toward AI when the boxes on the left are true; lean toward writing it yourself when the boxes on the right are.

One more heuristic that catches most bad cases: if explaining the task to the AI would take longer than doing it, do it. A deeply contextual fix often fails this test — by the time you've written the prompt that carries all the hidden context, you've basically written the fix. The prompt is the hard part.

And a mode note. The risk shifts with how you use the assistant. Inline autocomplete suggests small, reviewable bites you accept one at a time. A full agent mode can rewrite many files at once, which multiplies both the upside and the review burden — and makes 'I'll just trust it' far more tempting and far more dangerous. The riskier the task, the more you want small, inspectable steps over a sweeping autonomous change.

// Going deeper

Once the basics click, a few subtler points separate people who use AI coding tools well from people who get burned by them.

Automation bias is the real enemy. Humans systematically over-trust confident, automated output — and code that compiles and reads cleanly is the most trustworthy-looking output there is. The fix isn't more willpower; it's structure. Keep the AI's blast radius small (small diffs, small steps), keep yourself in the review loop, and treat every generated line as a proposal you must approve, never a fact you inherit. The moment you stop reading is the moment the tool starts writing bugs on your behalf.

The line moves with your skill and the model. A task that's a bad AI fit for a beginner — who can't review the output — may be a great fit for an expert who can verify it in seconds. As models improve, some tasks migrate from the 'write it yourself' column to the 'reach for AI' column. The framework (verify-cost vs. write-cost) stays constant even as the boundary shifts; re-evaluate the boundary, not the framework.

Tests are the great unlocker. Many 'too risky for AI' tasks become safe when you have strong tests, because a good test suite makes verification cheap and automatic — it converts 'I have to read every line' into 'I run the tests.' If you want to expand where AI is safe to use, invest in tests first; they turn silent failures into loud, caught ones and move tasks leftward into AI-friendly territory.

Know your specific tool. Different assistants make different trade-offs in how much they change at once and how easy they are to keep on a leash — compare, for example, Claude Code vs. Cursor or weigh whether GitHub Copilot is worth it for your workflow. The 'when not to use it' rules in this article apply to all of them; the how of staying in control differs by tool.

The durable lesson: an AI coding assistant doesn't remove the need to understand your code — it relocates the effort from typing to reviewing. Use it where that relocation is a win, refuse it where it's a trap, and you'll be genuinely, not just apparently, faster.