AI assistants work best on familiar patterns whose results are easy to check. Examples include:
boilerplate
simple data transformations
unit-test drafts
documentation
configuration
common framework code
translations between similar languages
They can also summarize code or explain a stack trace quickly.
These tasks have many public examples, so the model has strong patterns to follow. A compiler, test, or short review can usually verify the result.
Assistants are less reliable for new architecture, subtle concurrency, hidden business rules, and performance work that needs real measurements. Use them when the cost of checking the answer is low. Keep human judgment in charge when a mistake would be expensive or when correctness cannot be demonstrated with clear evidence.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Even on boilerplate, an assistant can call an API that doesn't exist. How would you catch that?Compile or type-check it and run it. Confirm every API and package in the official docs or the registry before installing anything.
Would you let an assistant fix a suspected race condition? How would you use it safely?Use it to explain the code and suggest causes. Prove the fix with a failing test, stress runs or a race detector, and have a human sign off.
A data transform looks routine but touches billing. Does that change how much you trust the assistant?Yes. A hidden rule makes a mistake costly. Pin the behavior with tests built from real cases and have someone who knows the rule review it.
What you can say
AI assistants do best on familiar patterns where I can check the result cheaply.
That means boilerplate, simple data transformations, first drafts of unit tests, docs, config, common framework code, and translating between similar languages.
They're also quick at summarizing code or explaining a stack trace.
They work because the model has seen many public examples of these tasks, and a compiler, a test or a short review can confirm the output.
They're less reliable on new architecture, subtle concurrency, hidden business rules, and performance work that needs real measurements.
So my rule is to use them when checking is cheap, and keep human judgment in charge when a mistake would be expensive or I can't show correctness with clear evidence.
Weak answers to avoid
Lists tasks with no reason whyA bare list sounds memorized. Give the reason first. The pattern is common in public code and the result is cheap to check, and the list follows from that.
Claims AI is good at everything nowOverselling suggests you haven't shipped with it. Name where it fails, like concurrency, hidden business rules and performance work, and say how you guard it.
Rates tasks by difficulty, not checkabilityEasy-looking code can hide a costly business rule. Tie trust to how cheaply you can prove the output and what a mistake would cost.
Treats AI-drafted tests as proofTests from the same model can carry the same wrong assumption. Say you review the tests too and check them against the real requirement.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
