When Is AI Actually Useful? (And When It Isn't)

• Can I fully describe the input in text? If not, AI probably can't help yet.
• Can I quickly check the output for correctness? If you can't verify it, be careful with it.
• Is a good-enough first draft genuinely useful? Drafting, summarising, reformatting — yes. Sign-offs, diagnoses, final calls — no.
• Is the cost of being wrong low? Embarrassing but recoverable is fine. Legal, medical or financial needs a human.
• Do I have context only I have? If you can supply the real constraints, the answer will be far better than a generic one.

• Confident fabrication. It produces a plausible citation, API name or statistic that does not exist, in exactly the same tone as a true one. There is no tell.
• Recent events. Anything after its training data, and anything specific to your situation, gets invented rather than acknowledged as unknown.
• Quiet degradation on long input. Put a critical instruction in the middle of a long document and it may simply stop attending to it.
• Sycophancy. Asked to check your work, it tends to agree. Ask instead for the three strongest objections to your position.

Most people reach for the largest model available for everything, which is slower, costs more, and is often worse on simple tasks. Use the smallest model that does the job well.

• Small and fast: classification, extraction, reformatting, short rewrites, autocomplete. Bigger models add latency for no gain.
• Mid-tier: drafting, summarising, standard coding help, everyday work. Most of your usage should live here.
• Largest and slowest: multi-step reasoning, long documents, difficult maths, code that has to be correct.
• Search-grounded tools: for anything needing current facts, use a tool that actually retrieves sources rather than recalling them.
• Local models: for private data, high volume, or when the connection is unreliable.

• When you already know the answer and are avoiding it. No tool can make the decision for you.
• When the relationship is the point. Difficult conversations, apologies, saying no — those have to be yours.
• When you need to be the one who understands. Delegate the thinking and you can no longer review the work.
• When it's a small task with a large prompt. Writing the prompt takes longer than doing the job.
• When the data is sensitive and you haven't decided your policy. Decide that first, not after you've uploaded it.

• Give it a role and a real constraint — 'be a sceptical reviewer' produces different work than 'help me with'.
• Show an example of the output you want rather than describing it.
• Iterate on the answer instead of rewriting the prompt; you keep the parts that already worked.
• Ask for the sources or the reasoning, not just the conclusion.
• Ask what information would make its answer better, then supply it.