Most discussion of AI assistants focuses on how to use them. Equally important, and less discussed, is when not to. These tools are genuinely useful, but reaching for them reflexively in every situation can undermine your learning, your judgement and sometimes your security. Knowing when to hold back is part of using them maturely.
A few situations especially reward restraint.
When you’re still learning the fundamentals
If your goal is to genuinely understand a concept, leaning on an assistant to produce the answer can short-circuit the productive struggle that builds real skill. Wrestling with a problem yourself first, and using the tool to check or extend your understanding afterward, keeps you learning. Outsourcing the thinking every time can leave you dependent and shallow.
The struggle is not wasted time; it is often where the learning actually happens.
When you can’t verify the result
It is unwise to use generated output in areas where you lack the knowledge to judge whether it is correct, because the confident-but-wrong failure mode is exactly where you are least equipped to catch it. If you cannot evaluate the answer, you cannot safely rely on it, and the tool becomes a source of risk rather than help.
This is a strong argument for building your own understanding, so that you remain able to verify what any tool produces.
When context is sensitive
Care is also warranted when the problem involves confidential code, private data or security-critical logic, where sharing context or trusting generated solutions carries real consequences. Sensitive material and high-stakes decisions deserve extra caution about what you feed a tool and how much you trust it back.
None of this argues against AI assistants — it argues for judgement about when they help and when they hinder. The skilled user knows both when to reach for the tool and when to set it down.
Genuinely novel algorithmic work, where there is no existing pattern to draw from
A model's output is fundamentally shaped by patterns present in its training data, which makes it excellent at well-established, widely-documented patterns and considerably less reliable for a genuinely novel algorithm or a problem with no strong precedent to draw from — for this category of work, the model is more likely to produce something that superficially resembles a solution without actually solving the specific, novel problem at hand, which is exactly the situation where relying on it costs more time in verification and correction than writing the logic by hand from first principles would have.
Security-critical code, where a subtle, confidently-wrong suggestion is unusually costly
Authentication logic, cryptographic code, and access-control checks are all areas where a subtly wrong but plausible-looking suggestion can introduce a genuine vulnerability that passes casual review specifically because it looks reasonable — the cost asymmetry here is severe enough that this category of code warrants writing and reviewing by hand with extra rigor regardless of how much time an AI assistant might save elsewhere, since the downside of a security bug slipping through vastly outweighs any time saved generating the code faster.
Learning fundamentals as a junior developer, where the struggle itself is the point
A junior developer working through learning core concepts — recursion, algorithmic complexity, how a specific data structure actually behaves — benefits from the genuine struggle of working through a problem themselves, since that struggle is what actually builds the underlying intuition and mental models discussed at length elsewhere in this library; reaching for an assistant to skip past that struggle produces a shortcut to code that works without the understanding that would let the same developer debug or extend it confidently later, which defeats the actual purpose of the learning exercise.
Deeply domain-specific business logic that lives only in institutional knowledge
Business logic that depends on specific, undocumented institutional rules — an unusual tax calculation particular to one jurisdiction, a legacy pricing rule nobody wrote down anywhere — is exactly the kind of knowledge a model has no way to know, since it exists only in the heads of people at a specific organization rather than in any training data; asking for this kind of code without providing that specific institutional context produces a plausible-looking but almost certainly wrong implementation, since the model will confidently fill the gap with a generic, statistically common assumption rather than the actual specific rule that applies.
Debugging a problem whose root cause is not yet understood at all
Asking a model to fix a bug before the actual root cause is understood tends to produce a plausible-looking patch that treats a symptom rather than the underlying problem, since the model pattern-matches toward a common fix for the visible symptom described rather than genuinely diagnosing the specific, possibly unusual cause — using the rubber-duck technique discussed elsewhere in this library to actually understand the root cause first, before ever asking for a fix, produces a considerably more reliable result than asking for a fix based on symptoms alone.
Situations where the actual bottleneck is a decision, not a lack of code
Some tasks are blocked on a genuine design or product decision — which of two architectures to commit to, what the actual business requirement even is — rather than on the mechanical effort of writing code once that decision is made, and reaching for an assistant to generate code before that underlying decision has actually been made just produces plausible-looking code for the wrong choice, which then has to be discarded once the real decision is finally settled.
Code review of another human's pull request, where judgment is the actual deliverable
Delegating the substantive judgment calls of reviewing a colleague's pull request entirely to an assistant — rather than using it as a supplementary first pass, discussed in more depth elsewhere in this library — skips the actual value a human reviewer provides: judging whether an approach fits the team's specific context and priorities, which is exactly the kind of contextual judgment a model summarizing surface-level issues does not replace.
Situations where the actual constraint is trust with a client or stakeholder, not code quality
Some client relationships or contractual situations specifically require that certain code be written and attested to by a named, accountable human, regardless of how capable an assistant might be at the underlying technical task — in these cases, the actual constraint being satisfied is about accountability and trust, not about whether the resulting code would technically be correct, which is a genuinely different consideration than the technical risk factors covered elsewhere in this cluster of articles.
Any task where the actual value is the thinking process, not the artifact it produces
Some tasks are valuable specifically because working through them builds understanding that gets used repeatedly afterward — designing a system's core architecture, working out a tricky algorithm's correctness proof — and outsourcing the actual thinking to an assistant, even if the resulting artifact looks fine, forfeits exactly the understanding that made the exercise worth doing in the first place, which is a cost that does not show up in the artifact itself at all.
Situations already covered by strict regulatory or compliance sign-off requirements
Some regulated industries require a specific, accountable, credentialed human to have directly authored or explicitly attested to certain code or documentation, independent of whether an assistant could technically produce equivalent output — in these specific, regulated contexts, the constraint is a compliance and legal one rather than a technical-risk judgment call, and no amount of AI capability changes what the actual regulatory requirement demands.
Why recognizing these situations is itself a skill that improves with deliberate practice
Correctly judging in the moment whether a given task belongs in this article's list of exceptions is not an instinct every developer starts with; it sharpens specifically through noticing, after the fact, the cases where reaching for an assistant produced more rework than it saved, and deliberately reflecting on what those cases actually had in common — building this judgment explicitly, rather than assuming it develops automatically, is itself worth treating as a skill.
Why this article is not an argument against the tool, only against its misuse in specific contexts
Nothing in this article argues these tools lack genuine value; the specific exceptions covered here are precisely that — exceptions to an otherwise broadly useful default, worth naming explicitly because they are exactly the situations where the tool's ordinary strengths do not apply, rather than evidence the tool itself is generally unreliable.
Why the cost of a wrong decision here is asymmetric between the two failure directions
Wrongly avoiding AI assistance for a task that would have been perfectly safe to delegate costs some avoidable extra time; wrongly delegating a task that actually needed a human's full attention can cost considerably more once a subtle mistake reaches production — given this asymmetry, a reasonable default leans toward caution in genuinely ambiguous cases, treating an unnecessary bit of manual effort as the cheaper mistake to risk making.
Why this list will keep needing revision as the underlying tools genuinely improve
Some items on this list reflect current, real limitations that may narrow as tools improve at handling novelty, security-sensitive reasoning, or long-context understanding, while others, like the value of struggling through fundamentals as a learning exercise, reflect a more durable, tool-independent truth about how understanding is actually built — distinguishing which category a given item on this list belongs to is worth reconsidering periodically rather than treating the whole list as permanently fixed.
Why naming these exceptions explicitly protects the tool's broader reputation, not just these specific tasks
A team that applies AI assistance indiscriminately, including to exactly the situations covered in this article, and then experiences a bad outcome, risks concluding the tool itself is unreliable rather than recognizing the mismatch was in how it was applied — being explicit about where it does not fit protects the tool's legitimate, broader usefulness from being unfairly blamed for a mismatch that was actually about applying it to the wrong kind of task.
Why a short, explicit list like this one is more useful than a vague general caution
A vague instruction to 'use judgment' provides little concrete guidance in the actual moment a decision needs to be made, while a short, specific, named list of situations worth treating differently gives something concrete to actually check against — this is exactly why this article named specific categories rather than simply advising general caution throughout.
Why revisiting this list with a team, rather than reading it alone, produces better calibration
Discussing this list directly with a team surfaces genuine disagreement about where specific team tasks actually fall, which is far more useful than each person silently applying their own private interpretation — a team that has explicitly talked through where its own real work falls on this list ends up with meaningfully more consistent, shared judgment than one relying on each individual's private reading alone.