The debate about AI coding assistants is often framed as all-or-nothing: either they are the future and you should let them write everything, or they are dangerous and you should avoid them. The useful truth is boring and in between. Assistants are excellent at a well-defined set of tasks and poor at another, and the skilled move is knowing which is which so you delegate deliberately instead of by habit.
The organising question is not "can the AI do this?" — it usually can produce something — but "is this a task where its strengths help and its weaknesses are cheap?"
Where assistants shine
AI is strong when the task is common, well-specified and easy to verify. Boilerplate and scaffolding, translating code between languages, writing the tedious first draft of tests, explaining unfamiliar code, generating regexes and configuration, and answering "how do I do X in this language" all play to its strengths: patterns it has seen thousands of times, with output you can immediately run and check. Here it genuinely saves hours and reduces the friction that makes developers cut corners.
It also excels as a thinking partner — rubber-ducking a design, suggesting approaches, catching an obvious oversight — precisely because in that mode you remain the one deciding, and its confident wrongness is caught by your judgement rather than shipped.
Where it quietly costs you
The danger zone is code that is novel, subtle, security-sensitive, or hard to verify. Core business logic that encodes rules only your team knows, tricky concurrency, cryptography and authentication, anything touching money or safety, and deep architectural decisions all reward understanding that the assistant does not have and cannot fake. Here its fluent-but-shallow output can introduce defects that pass a casual read and surface in production.
There is also a subtler cost: leaning on AI for the parts you most need to understand erodes the very expertise that lets you catch its mistakes. If you cannot review it competently, generating it is borrowing against your future judgement.
Delegating on purpose
A practical rule: let the assistant handle the tedious-but-verifiable, and reserve for yourself the novel, the security-critical, and the code you must deeply understand. When you do delegate, stay able to review — never ship what you cannot explain. When you write it yourself, do so because the understanding is the point, not out of pride.
Used this way, the assistant is neither oracle nor threat; it is a fast, tireless, occasionally-wrong tool whose value depends entirely on the judgement of the person driving it. The most productive developers are not the ones who delegate everything or nothing — they are the ones who know, task by task, which is which.