The counter-narrative
Most AI tooling content argues for more AI involvement, not less. The incentives behind that content are obvious. The honest account is different.
AI assistance has negative ROI for a specific set of engineering tasks — tasks where the overhead of AI involvement exceeds the benefit, or where the output quality is reliably worse than what you produce unaided.
Knowing which tasks these are is as important as knowing which tasks benefit from AI assistance. Using the wrong tool costs time even when the tool is powerful.
Deep domain work
When a task requires deep familiarity with a system that you understand and the model does not — your specific production database schema, the quirks of an internal API that was never documented publicly, the subtle invariants of a codebase you have maintained for three years — the model is working with an incomplete map.
It generates plausible-looking code that misses the thing you would have caught immediately. You spend more time reviewing for the subtle error than you would have spent writing the code.
The threshold: if the primary value you bring to a task is specific knowledge that the model cannot have, write it yourself. Use the model for the surrounding work — the tests, the documentation, the boilerplate — but not for the core logic where your domain knowledge is the differentiating factor.
Learning new technology
When you are deliberately learning a new framework, language, or system, having Claude write the code defeats the purpose.
The resistance you feel when writing unfamiliar code — looking things up, making mistakes, figuring out why things fail — is the learning process. AI assistance bypasses it efficiently. You get working code and no understanding.
This is a real cost. An engineer who has used Claude to build three Next.js projects without writing the routing logic themselves knows less about Next.js than one who struggled through it. The knowledge gap surfaces when something non-standard is required.
Reserve AI assistance for applying knowledge you already have. Learn by doing, manually.
Ambiguous or exploratory problems
Problems where you do not yet know what you want are bad candidates for AI assistance.
If you cannot specify the success criterion clearly, the model will generate something — it is always willing to generate something. That something gives the problem a false concreteness. You start iterating on the wrong thing because the model gave you an answer to a question you had not actually decided to ask.
Exploratory thinking is better done in your own head, on a whiteboard, or in a conversation where the goal is to clarify what you want — not to get an implementation of an unclear idea.
The rule: specify before you delegate. If you cannot write a clear specification, do not delegate yet.
Debugging unfamiliar systems
When you are debugging a system you do not understand, AI assistance has a specific failure mode: it produces confident-sounding hypotheses about what is wrong. Some of these hypotheses are plausible. Most are not specific to your system.
Following a plausible hypothesis about an unfamiliar system without the judgment to evaluate it is a path to hours of wasted work. You cannot tell the difference between a correct hypothesis and an authoritative-sounding incorrect one without understanding the system.
Debugging unfamiliar systems requires building understanding first. That understanding comes from reading documentation, reading the code, running it and observing behavior. The model is useful at the end of this process — when you have a hypothesis and want to stress-test it — not at the beginning.
Security-critical code
Security code is a domain where the cost of subtle errors is disproportionate and where subtle errors are exactly what AI-generated code is likely to contain.
Authentication flows, authorization logic, cryptographic implementations, input sanitization — these should be written by an engineer who understands the failure modes, reviewed by someone who can evaluate the implementation against the threat model, and tested against explicit attack scenarios.
AI-generated security code is not obviously wrong. It passes tests. It looks correct. The error is in the edge case that was not specified, the assumption that was not stated, the interaction with another part of the system that was not in context when the code was generated.
Use AI for the non-security-critical surrounding code. Keep the security-critical path under direct human authorship.
When the specification cost exceeds the generation benefit
For small, well-understood tasks — a three-line function, a minor configuration change, a rename across ten files — the overhead of writing a clear AI task specification often exceeds the time savings from not writing the code yourself.
The breakeven is roughly: if writing the specification takes longer than doing the task, do the task. Experienced engineers develop an intuition for this quickly.
The meta-lesson
AI assistance is leverage. Leverage amplifies what you bring to it. For tasks where you bring domain knowledge, clear specifications, and strong judgment about the output — the leverage is high.
For tasks where you bring uncertainty, incomplete understanding, or an unclear goal — the leverage amplifies the uncertainty. The output is confidently wrong in ways that cost more time to unwind than the generation saved.
Use AI where you are strong. Keep the tasks where you are still building strength. The discipline to stay in the right quadrant is what separates engineers who compound with AI tooling from engineers who stagnate at mediocre results across all use cases.