When Not to Use AI Coding Tools

AI coding assistants are powerful when you can specify the goal and verify the result. Here is where they are a poor fit, and how to spot it early.

AI coding assistants have gotten good enough that reaching for one by default feels natural for almost any task on the backlog. That default is not always correct. There are problem categories where an assistant burns time, hides risk, or produces code nobody on the team can actually vouch for, and the cost of that only shows up later, usually after it ships and someone else inherits it.

This is not an argument against AI coding tools. It is a map of the boundary. Knowing where that boundary sits, and having a process that catches you when you cross it without noticing, matters more than raw model capability. The rest of this post walks through the situations where an assistant is a poor fit, or at minimum needs extra caution before you trust its output.

Genuinely Novel or Ambiguous Problems

AI coding assistants are pattern matchers trained on an enormous corpus of existing code and convention. They are strong at problems that resemble something in that corpus, even loosely. They are weak at problems where the goal itself is not yet clear, where you are still deciding what "correct" even means. If you cannot write a spec, a test, or an acceptance criterion because the shape of the solution is still forming in your head, an assistant has nothing solid to aim at. It will produce confident, plausible-looking code anyway, which is often worse than producing nothing, because it looks finished when the actual thinking has not happened. This is one reason spec-driven development treats the spec audit as a gate rather than a formality: an underspecified goal is the single most common root cause of AI code that runs fine but solves the wrong problem.

More project context sitting in a persistent, private memory layer like MemX can sharpen a spec, since the assistant has more of the project's history and prior decisions to draw on. That helps when the ambiguity is really a missing-context problem. It does not help when the ambiguity is about the goal itself. Only a decision you make resolves that, and no amount of retrieved context substitutes for making it.

• You keep changing the prompt because the output "isn't quite it," but you can't say what "it" is.
• Two reasonable engineers on the team would design this differently, and neither is wrong.
• The problem requires a judgment call that trades off business priorities, not just technical ones.
• You are exploring options, not implementing a decision that has already been made.

Code You Cannot Verify or Test

The value of AI-generated code is inseparable from your ability to check it. Without automated tests, a staging environment, or some way to observe the code's behavior under real conditions, you are accepting the assistant's confidence as a substitute for evidence, and confidence is not evidence. This is especially risky in domains with a slow feedback loop: firmware you cannot quickly flash and test, reconciliation logic that only reveals bugs at month-end close, or anything touching money movement, health data, or physical hardware. A slow feedback loop turns a wrong assumption into a standing liability that nobody notices until it is expensive to unwind.

The same caution applies to code you technically could test but haven't, because the assistant made the change faster than your test suite could catch up. A green build is not proof of correctness if the tests it ran never exercised the new path. Before trusting a change, confirm the coverage actually touches what changed, not just that the suite passed.

Security-Critical Logic Without a Review Gate

Authentication, authorization, cryptographic operations, and anything that parses untrusted input are places where a subtly wrong implementation looks identical to a correct one until someone exploits it. An assistant can write secure-looking code with a real gap inside it: an off-by-one in a permission check, a missing sanitization step, a race between a check and its use. These are not hypothetical categories; they are exactly the bug classes a security review of AI-generated code exists to catch, because they rarely surface in a normal functional test. Shipping this kind of logic straight from an assistant to production without a dedicated, adversarial review step is one of the riskiest habits a team can build once AI coding starts to feel routine.

Trivial Edits and Domain Blind Spots

Not every poor fit is high-stakes. Sometimes the problem is simple arithmetic: a one-line config change, a rename, a copy edit, or a small style tweak costs more time to prompt, review, and re-prompt than it costs to just make by hand. If you already know exactly what to type, typing it is often faster than explaining it. Save the assistant for work where the ratio of specification effort to typing effort actually favors delegation.

The other blind spot is subtler. If you do not understand the domain well enough to tell correct code from plausible-sounding code, you cannot meaningfully review what the assistant hands you, regardless of how capable the model is. Someone fluent in a domain can spot a subtly wrong calculation on sight; someone unfamiliar with it will approve the same code because it compiles and the variable names sound reasonable. AI coding tools amplify judgment. They do not replace it, and they especially cannot replace judgment you have not built yet. Reviewing AI output in an unfamiliar domain without structured support is close to reviewing nothing; an AI code review checklist built for that domain, or a second reviewer who actually knows it, stops being optional at that point.

This is not a permanent disqualification. Domain knowledge can be built deliberately, by pairing with someone who has it, reading the existing codebase closely before touching it, or scoping the AI-assisted work to the parts you already understand while handling the unfamiliar parts yourself. The point is to be honest about which category you are in before you hit accept, not after.

The Honest Takeaway: Specify and Verify

Every poor fit above traces back to one of two failures: you could not specify the goal precisely enough, or you could not verify the result once you had it. AI coding tools are powerful exactly to the degree that both of those hold. When you can write down what "done" means and you have a fast, trustworthy way to check it, delegate freely; the assistant will often outperform doing it by hand. When either condition breaks down, the risk shifts from the code to you, because you are the one signing off on something you cannot actually evaluate. That is the entire premise behind treating AI coding as a process with gates instead of a single prompt-and-accept step: a spec audit, independent review, and a red-team pass exist specifically to catch the moments where specification or verification quietly failed.