Three common kinds of work, three different risk profiles. The amount of checking each needs is not the same, and treating them identically is how people either waste time or ship mistakes.
Writing
The strong case is structure and starting. A blank page is expensive; an outline you disagree with is cheap and useful, because disagreeing with it is faster than generating one.
The weak case is voice. Default AI prose has a recognisable texture — balanced, slightly hedged, fond of tricolons and of "it's not just X, it's Y". Readers notice, even when they cannot name what they noticed.
What works in practice:
- Draft the structure with AI, write the sentences yourself
- Give it your own previous writing as an example if you want your register back
- Use it as an editor rather than an author: "where is this unclear?", "what did I not answer?"
- Ask for specific critique. "Make it better" returns a rewrite in its voice, not yours
Coding
Genuinely strong: boilerplate, unfamiliar syntax, translating between languages, explaining code you did not write, and producing a first draft of tests.
Genuinely risky, in a specific way: generated code is almost always syntactically valid and plausible-looking, and wrong at the boundaries. Off-by-one, unhandled null, the empty-list case, the assumption that input is well-formed. It looks like working code because it is shaped like working code.
The rules that matter:
- Read it before you run it. If you cannot follow it, you cannot maintain it.
- Test the edges — empty, one item, huge, malformed, wrong type.
- Never paste secrets into a prompt.
- Be suspicious of APIs you do not recognise. Invented function names and parameters that do not exist are common. Check the documentation.
- Do not ask the model to confirm its own code is correct. It will say yes. That is not evidence.
Analysis
The important distinction: models predict plausible text, and digits are text. Asking for a mean, a percentage change or a total from numbers in a prompt can produce a confident, well-formatted, wrong figure.
Split the job:
- Calculation → a spreadsheet, code, or a tool the model can call
- Interpretation → the model, given the computed result
That division is reliable. The other way round is not.
The second analysis failure is subtler: ask "what does this data show?" and you will get patterns, because patterns are what the question implies exist. Ask instead "what would have to be true for this reading to be wrong?" — that question produces the caveats the first one hides.