← AI for Professionals: Using LLMs at Work
Lesson
Lesson 3: Verify facts, numbers and code — and own the result
Verify an LLM's factual, numeric, and code output and articulate that the human remains responsible for what is shipped.
A practical verification routine — and why accountability stays with you
A practical verification routine — and why accountability stays with you
Catching a hallucination is only half the job. You also need a repeatable routine so that verification becomes a habit, not an afterthought. For facts: find the primary source (the original study, the official report, the authoritative website) and confirm the claim there — not in another article that cites the same LLM-era source. For numbers: recompute them independently or use a dedicated tool (a spreadsheet, a calculator, a data query) rather than trusting the model's arithmetic. For code: run it in a safe test environment, write at least a basic test case, and read through the logic — syntactically valid code can do precisely the wrong thing.
A key mindset shift: the model can be confidently wrong. It does not hedge because it is uncertain — it generates the most statistically plausible continuation of your prompt. A confidently stated answer is not evidence of accuracy.
Accountability always stays with the human. If you ship a report with a fabricated statistic, or deploy code that was never tested, the professional and legal responsibility is yours — not the model's. This is not a reason to avoid LLMs; it is a reason to use them with a clear verification step before anything consequential goes out.
The practical takeaway: build a short checklist into your workflow. Before you use any LLM output professionally, ask: Did I verify the facts against primary sources? Did I recompute or tool-check the numbers? Did I run and read the code? If any answer is no, finish the verification before you ship.
Lesson notes
A practical verification routine — and why accountability stays with you
Catching a hallucination is only half the job. You also need a repeatable routine so that verification becomes a habit, not an afterthought. For facts: find the primary source (the original study, the official report, the authoritative website) and confirm the claim there — not in another article that cites the same LLM-era source. For numbers: recompute them independently or use a dedicated tool (a spreadsheet, a calculator, a data query) rather than trusting the model's arithmetic. For code: run it in a safe test environment, write at least a basic test case, and read through the logic — syntactically valid code can do precisely the wrong thing.
A key mindset shift: the model can be confidently wrong. It does not hedge because it is uncertain — it generates the most statistically plausible continuation of your prompt. A confidently stated answer is not evidence of accuracy.
Accountability always stays with the human. If you ship a report with a fabricated statistic, or deploy code that was never tested, the professional and legal responsibility is yours — not the model's. This is not a reason to avoid LLMs; it is a reason to use them with a clear verification step before anything consequential goes out.
The practical takeaway: build a short checklist into your workflow. Before you use any LLM output professionally, ask: Did I verify the facts against primary sources? Did I recompute or tool-check the numbers? Did I run and read the code? If any answer is no, finish the verification before you ship.