AI generates answers in seconds. That speed is the point — and the trap. Before acting on AI output, ask three questions: how would the AI know this, does it make sense in the real world, and what happens if it's wrong. The most effective AI users are not the ones who trust every answer. They are the ones who know which answers to question.
AI can generate an answer in the time it takes you to finish forming the question.
That speed is genuinely useful. It is also where things go wrong.
The failure mode is not that AI produces bad output. It is that AI produces bad output with the same fluency and confidence as good output. There is no hesitation, no qualifier, no signal that the model is operating outside reliable territory. The answer arrives and it sounds correct.
After two years of using AI tools in engineering workflows — for code generation, architecture advice, debugging, documentation, and specification drafting — I have settled on three questions I ask before I act on any AI-generated response. They take about ten seconds and have saved me more than a few expensive mistakes.
Figure 1: Three questions, each catching a different failure mode — source gaps, plausible-but-wrong reasoning, and insufficient verification for high-stakes decisions.
Question 1: How Would AI Know This?
The first question is mechanical.
LLMs are trained on a snapshot of text from the internet, documentation, and code repositories. The training has a cutoff. The model cannot access information after that date unless it has been given tools to do so. Even within the training window, the model's knowledge is uneven — well-covered topics produce more reliable outputs than niche, recent, or contradictory ones.
There are also classes of knowledge AI simply cannot have: your codebase's specific architecture decisions, your organisation's incident history, the undocumented assumption your team made in 2022 that is still load-bearing in production.
When AI gives me an answer, I ask: what source would the model have learned this from? Is that source reliable? Is it current? Is this the kind of knowledge that requires context the model cannot have?
If the answer touches anything time-sensitive, domain-specific, or dependent on private context, I verify it from a source I can trace.
This is not a criticism of AI. It is just understanding what the tool is. A model that cannot distinguish between what it knows reliably and what it is pattern-matching toward is not being deceptive — it is doing exactly what it was trained to do.
Question 2: Does This Make Sense in the Real World?
The second question is experiential.
AI outputs that look plausible on paper frequently fail against practical judgment. The code snippet compiles and looks clean, but would not perform at the scale the system needs to handle. The architectural suggestion is technically coherent, but ignores a constraint that anyone who has run this kind of system in production would know instinctively.
The shortcut AI takes — predicting likely next tokens — can produce outputs that are statistically plausible but operationally wrong. A senior engineer's reaction to a bad suggestion is immediate: we tried something like this in 2021 and here is what happened. The model has no such memory.
I ask: would an experienced practitioner in this domain look at this recommendation and nod, or would they start asking questions? If I cannot answer that confidently, I need to get a practitioner in the room — a colleague, a reference architecture, a pattern I have seen work before.
This question is also where implicit knowledge earns its keep. Not all expertise is written down. AI is trained on what has been published. What has been learned and not published — in incident post-mortems, in code review threads, in architecture ADRs — is not available to the model. The gap between "the right answer as described in documentation" and "the right answer for this specific system, at this specific scale, given what we know from last year's outage" is where human judgment is irreplaceable.
Question 3: What Happens If This Is Wrong?
The third question is about stakes.
Not every AI answer warrants the same level of scrutiny. I use AI to draft emails, explore approaches, summarise documentation, scaffold boilerplate. For most of that work, if the output is slightly wrong, the cost is negligible — I notice, I correct, I move on.
The threshold shifts sharply for decisions with material consequences.
If I am generating code that will handle financial transactions, security-sensitive data, or production traffic at scale, the cost of a subtle error is high enough to warrant independent verification regardless of how confident the output appears. If I am using AI-generated output to inform an architectural decision the team will live with for three years, the stakes are different from using it to explain a terminal command I will run once.
A simple version of the rule: if I could not quickly recover from this being wrong, I verify before acting.
This maps to the core principle of any quality gate system. The gate is not there because output is always wrong. It is there because the cost of certain failures is high enough that you want structural protection — not willpower, not vigilance, but a gate that does not depend on anyone remembering to check.
Figure 2: The cost of failure determines the level of verification warranted. Reversible, low-blast-radius work flows through readily. Irreversible, high-blast-radius decisions get independent verification.
What This Looks Like in Practice
The three questions take seconds individually. Together they produce a rough risk score for any piece of AI output.
High frequency, low stakes, reversible work — draft emails, code scaffolding, documentation summaries: accept readily, verify lightly.
Low frequency, high stakes, hard-to-reverse decisions — architecture choices, security-sensitive code, anything that shapes how the team works for the next year: verify independently before acting.
The most effective AI users I have worked with do not trust every answer. They have a fast, repeatable habit of asking before acting: how would it know, does it make sense, what happens if it's wrong.
Confidence is not accuracy. That is not a flaw in the tools. It is the nature of probabilistic text generation.
Use AI for acceleration. Apply judgment to the decisions.
The Bottom Line
AI output is fast. That speed is the value. But speed amplifies whatever is already in the process — including errors in judgment if you skip the questions that should be routine.
The three questions — how would AI know this, does this make sense in the real world, what happens if this is wrong — take ten seconds and produce a reliable filter. The most effective AI users are not the ones who trust the most answers. They are the ones who know which answers require a second look.
