When I delegate a task to an AI system, I use the same basics I would use with a colleague. I define the job, supply the relevant context, and state how I will review the result.
The comparison stops at the review boundary. Fluent output is still generated text, not evidence. Important claims need sources, calculations need checking, and code needs tests.
Why the colleague metaphor helps
People were applying social rules to computers long before large language models existed.
In their 1994 paper Computers are Social Actors, Clifford Nass, Jonathan Steuer, and Ellen Tauber found that people responded socially to computers even when they knew they were dealing with a machine. Language and role cues were enough to prompt those habits.
Modern assistants use the same conversational signals. Their training also reflects human preferences. The InstructGPT research, for example, used demonstrations and rankings written by people to train a model to follow instructions more closely.
Thinking in terms of delegation gives me a useful checklist:
- define the job and its boundaries
- provide the context needed to do it
- ask which assumptions affect the answer
- request sources, tests, or other working artefacts
- review the result against an agreed standard
- increase autonomy only after repeated success
The metaphor is a way to organise the work. It does not require the model to be conscious or sentient.
Fluency is not evidence
A model can sound calm and certain whether its answer is correct or not. A 2025 study of what language models know and what people think they know found that default explanations did little to help participants distinguish correct answers from incorrect ones. Longer explanations also raised confidence without improving that judgement.
Tone can compound the problem. In a 2026 study, fine-tuning five models to sound warmer increased the average probability of an incorrect answer by 7.43 percentage points across four question-answering benchmarks. It also made the models more likely to agree when users expressed incorrect beliefs. The result is specific to the study’s models, training method, and benchmarks, but it is a useful warning against treating warmth as competence.
Treat a confident explanation like an unreviewed pull request. Inspect the change, run the checks, and test the assumptions.
Ask for evidence, not inner reasoning
“How did you reach that answer?” can produce a useful explanation, but it cannot reliably reveal the model’s private reasoning.
Research on unfaithful chain-of-thought explanations showed that biased prompt features could influence a model while its explanation omitted that influence. The model could instead produce a plausible justification for its answer.
Ask for artefacts you can inspect:
- a restatement of the task and success criteria
- assumptions that materially affect the result
- factual claims separated from inference
- primary sources for material claims
- reproducible calculations
- the diff, test, query, or command used for verification
- the weakest part of the answer and evidence that would change it
This resembles a code or design review. The useful part is the evidence, not the performance of confidence.
Self-review has limits
Treat the first output as a draft. Structured self-review can improve it.
The Self-Refine study used the same model to generate, critique, and revise output across seven tasks. The refined outputs improved by about 20 percentage points on average under the study’s human and automated evaluations.
Chain-of-Verification used a more structured sequence. The model drafted an answer, wrote verification questions, answered them independently, and then revised the answer. This reduced hallucinations across the tasks tested.
Independent verification matters because the original claim can anchor a review. Even so, self-review does not make an answer true. An ICLR 2024 study found that models could not reliably correct reasoning without external feedback. A broader TACL review of self-correction research also found that correction worked best with feedback such as tool output, retrieved evidence, test results, or human review.
“Check your answer” may catch an obvious mistake. “Check these claims against the linked primary sources, run this test suite, and report discrepancies before revising” gives the model something concrete to do.
Use another model as a reviewer
The model that made an error may repeat it during review. A second model can expose a different failure, particularly when it comes from another model family or provider.
The SAC3 hallucination-detection study found cases where a model was internally consistent but wrong. Rephrasing questions and comparing responses across models improved error detection on its benchmarks.
Disagreement is a reason to investigate. Agreement is not proof because models may share training data and common misconceptions. Nor does adding more simulated reviewers guarantee a better result. One ICML 2024 comparison found that multi-agent debate did not reliably beat simpler methods, including self-consistency and ensembling.
I use a modest review loop:
- One model produces the draft and supporting artefacts.
- A second model receives the original task, the draft, and a review checklist.
- The reviewer looks for incorrect claims, missed requirements, unsafe assumptions, and weak evidence.
- Tests, tools, or primary sources settle material disagreements.
- The first model revises the work and lists what changed.
The second model is another reviewer, not an appeal court.
Build trust by task
Trust in AI output should be specific to the task and its checks. A model may reliably transform a well-defined data structure when a schema and tests cover the result. That says nothing about its ability to name the current version of a dependency or interpret a contract.
For repeated tasks, increase autonomy in stages:
- Unproven. Inspect every material claim and change. Record the failures.
- Assisted. Let the model produce a draft, but require sources, tests, or detailed review.
- Trusted with guardrails. Let it complete the task inside a defined boundary, with automated checks and sampled human review.
- Reset after a material change. Reduce autonomy when the model, prompt, tools, data, or task changes.
Some work should remain assisted. High-impact decisions still need accountable human judgement and independent evidence, however good the model’s recent record looks.
Two practical review prompts
After a model produces important work, I use a prompt along these lines:
Review your answer as if you were reviewing a colleague's work.
1. Restate the task and success criteria.
2. Extract every material factual claim.
3. For each claim, provide a primary source or mark it unverified.
4. Check calculations independently from the original working.
5. Identify assumptions, omissions, and plausible counterexamples.
6. Run any available tests or validation tools.
7. Revise the answer only after completing those checks.
8. Summarise what changed and what remains uncertain.For a second model, make the independent review explicit:
You are reviewing work produced by another model.
Do not continue its argument by default. Start from the original task and success
criteria. Find unsupported claims, missed requirements, incorrect calculations,
unsafe assumptions, and tests that should have been run. Use primary sources or
tool output to resolve factual questions. Agreement is not evidence.Match the review cost to the consequence of an error. A disposable outline may need a quick read. A production change needs the same tests and accountable approval whether a person or a model wrote it.