Adopt the three reflexes of the practitioner - cross-check against official documentation, test it yourself, hunt for hallucination signals - before integrating anything.
Open this lesson in KodokonA hallucination isn't an absurd answer: it's a plausible and wrong answer - a method that ought to exist but doesn't, an option renamed two versions ago, a default behavior flipped around. That's precisely what makes competent developers vulnerable: hallucinated code is idiomatic, well-named, consistent with the ecosystem. It looks right. Three non-negotiable reflexes before integrating anything: cross-check against the official documentation for the version you use, test the code yourself in a minimal context, and have the answer audited - including by the model itself.
Take your previous answer and audit it as if it came from someone else.
1. List every verifiable technical claim: API or function name, described behavior, default value, version number.
2. For each, give your confidence level: certain / likely / to verify.
3. For each "to verify," state exactly what to look up in the official documentation: the name of the page, function, or module concerned.
4. Flag anything that might depend on the version or platform, specifying from which version it holds if you know.
Be harder on yourself than I would be: a claim over-rated as "certain" costs me more than one under-rated.This self-audit proves nothing - a model can be confident and wrong - but it turns fluent prose into a list of verifiable facts, each with its entry point into the docs. You're the one who verifies; the AI just prepared the ground. Learn too to spot the red flags: an API cut exactly to fit your need (too good to be true), a mix of conventions from different versions in the same snippet, a perfectly uniform confidence - real expertise says "it depends"; hallucination never does - and the absence of any mention of a limit or edge case. No single signal is proof, but each should trigger a verification.
You just claimed that [precise claim to verify].
1. Help me design the shortest possible test to verify it myself: the minimal file to create, the exact command to run, the precise result I should observe if you're right - and what I'll observe instead if you're wrong.
2. Then play devil's advocate: in which cases would your claim be false? Version, platform, configuration, strict mode or not - go through it all.
I'll run the test myself: don't ask me to take your word for it, give me the means to contradict you.This prompt applies a scientific principle to daily work: a claim is worth something if it's falsifiable - if you know what you'd observe should it turn out false. Ten lines in a throwaway file and one run beat every declared confidence level. For cross-checking the docs, three habits: verify in the docs for your version (models cheerfully mix eras of an API), check the changelog when a behavior seems to have changed, and keep a REPL or scratch file open at all times - the cost of verifying should be so low that you never have an excuse to skip the step.