Evaluating AI Output

The foundational habit of AI-assisted design is simple to state and hard to live by: treat every AI output as a draft from a fast, confident, and occasionally wrong assistant - never as a finished, verified fact. An LLM does not know things the way a reference book does; it generates the most plausible-sounding continuation of your prompt. Most of the time that plausible answer is also correct, which is exactly what makes the wrong ones dangerous - they arrive wearing the same confident clothes.

The practical consequence is that you close the loop, every time. In the human-in-the-loop pattern from Module 0, evaluation is step three, and it is not optional. Skip it and you are not saving time; you are shipping unreviewed output and hoping. The good news is that evaluation gets fast with practice. You are not re-deriving everything from scratch - you are running a quick, disciplined triage: is this the kind of claim that could be wrong, does it matter here, and what is the cheapest way to confirm it? Build that triage into muscle memory and AI becomes a genuine accelerator instead of a quiet source of embarrassing errors in front of a client or on a drawing that goes to site.

It helps to name the psychology working against you, because the failure is rarely laziness - it is trust that arrives too easily. Fluent prose feels authoritative; a well-formatted table looks verified; an instant answer carries none of the friction that, with a human colleague, would signal 'this is a guess.' Automation bias is the documented tendency to over-trust a machine precisely because it is a machine, and it is strongest when you are busy, tired, or working at speed - which is most of the time. The counter is not suspicion of everything but a deliberate pause at the point of use: before an AI output becomes your output, you consciously decide it has earned that promotion. That single habit - a beat of judgement between generation and use - is what this whole lesson is teaching you to make automatic.

The strongest verification move is also the most under-used: go back to the primary source. If the AI quotes a building-code clause, open the code and read the clause. If it names a product's fire rating, check the manufacturer's datasheet. If it summarises a long document you gave it, spot-check the summary against the passages it claims to compress. This turns the AI from an oracle you must trust into a research assistant that points you at where to look - which is a far safer and more honest use of it.

This is why grounding matters so much (Module 9.2 goes deeper). A model answering from its training data alone is guessing from memory; a model given the actual document to work from, or one that retrieves and cites sources, can be checked because it tells you where its claim came from. So prefer workflows that surface sources: paste the real clause and ask the model to interpret it, rather than asking it to recall the clause. Use tools that link citations. And when a model gives you a reference, open it - fabricated or misattributed citations are one of the most common failure modes, and one of the easiest to catch. A claim you cannot trace to a source you trust is not yet a fact; it is a lead.

Instead of:  "What does the fire code say about travel distance?"
Do:          "Here is Clause 4.3 of the code [pasted]. In plain English,
              what travel-distance limit does it set for this occupancy,
              and quote the exact sentence you based that on."

Not every claim can be traced to a document on the spot, so you need two faster filters. The first is the sanity check: does this even make sense? Bring your own domain knowledge and rough numbers. If the AI says a 3-metre span needs a 600mm-deep beam, or that a room 'comfortably seats 40' at 2 square metres per person, your trained instinct should twitch before you reach for a calculator. Order-of-magnitude thinking catches a surprising share of nonsense. AI has no common sense and no feel for the physical world; you do, and that is exactly the check it cannot perform on itself.

The second filter is cross-verification: ask the same question a different way, or ask a different model. If ChatGPT, Claude, and Gemini independently agree on a factual answer, your confidence should rise (though shared training data means they can share the same wrong belief). Re-asking with the framing changed - 'are you sure? what would make that wrong?' - often surfaces a model quietly correcting itself, which tells you the first answer was shaky. For anything numeric, have the model show its working so you can follow the logic rather than trust the total. None of these is proof; together they are a cheap, fast triage that flags what deserves the slower, source-based check.

A useful discipline is to separate the two things an LLM does well and badly. It is genuinely strong at reasoning and structure - laying out how to approach a calculation, what factors matter, what a good spec section contains - and genuinely unreliable at recalling specific facts from memory. So lean on it for the shape of an answer and supply or verify the facts yourself. If you ask it to size a beam, do not trust its number; ask it to explain the method, then run the numbers against a real standard or a calculator. If you ask it to interpret a clause, give it the clause. Used this way, the model amplifies your reasoning without your inheriting its unreliable memory - and the sanity-check and cross-verify filters become a fast second line rather than your only defence.

With practice you learn to feel when an answer is unsafe before you have fully checked it. Watch for over-specific precision - a suspiciously exact clause number, statistic, or date offered without a source is a classic hallucination signature. Watch for citations you cannot find, plausible-looking references to papers, standards, or products that evaporate when you search for them. Watch for answers that are too neat - real codes and real practice are full of exceptions, and an answer with no caveats is often an answer that skipped the hard parts.

Be extra alert when you are outside your own expertise, because that is exactly where you cannot sanity-check and where a confident-wrong answer does the most damage. Be alert when the topic is recent - models have training cut-offs and may confidently describe a superseded code or a discontinued product as current (this course notes that NBC references in India, for example, have moved; always confirm the live edition). And be alert to your own wishful thinking: when the AI tells you exactly what you hoped to hear, that is the moment to check hardest, not least. A wrong answer that confirms your bias is the one most likely to slip through.

You cannot forensically verify everything, and you should not try. The organising principle of professional AI use is that how hard you check should scale with what a wrong answer would cost. Think of it as a verification budget you spend where it matters.

At the low-stakes, divergent end - brainstorming mood directions, generating rough concept variations, drafting an internal note - light scrutiny is fine, because you are going to curate and rework everything anyway and an error costs you nothing. In the middle - a client-facing email, a first-pass area schedule, a précis of a report - a quick sanity-check and a source spot-check are enough. At the high-stakes, convergent end - a fire-code compliance claim, a structural figure, a specification that goes to site, a legal or contractual statement - the standard is near-total verification against primary sources, or you do not use the AI output at all. The cost of a confident-wrong answer there is measured in safety, money, and your professional name.

The mistake to avoid is uniform trust in either direction: paranoid double-checking of a throwaway moodboard wastes the time AI was meant to save, while a breezy copy-paste of a code clause into a drawing is how AI-assisted work becomes AI-assisted liability. Calibrate. Match the rigour to the risk, make that calibration a conscious step, and you get the speed of AI without inheriting its unreliability.