LLM Reliability on Programmer.ie: Modern AI programming

When Models Make Things Up

Sat, 29 Aug 2026 22:10:00 +0100

A language model can produce an answer that is fluent, grammatical, detailed, confident, and wrong.

That combination is what makes hallucination interesting.

Ordinary software failures usually leave evidence. A parser throws an exception. A database rejects an invalid constraint. A test fails. A network call times out. The failure changes the shape of the result.

A hallucinating language model can do something more difficult to handle: it can fail without looking broken.

Hallucination Is Not One Thing

Sat, 29 Aug 2026 22:45:00 +0100

Chapter 1 began with a familiar failure: a language model says something fluent that it cannot justify.

That description is useful until we try to build a detector.

Consider six outputs:

A. The model invents a person who does not exist.

B. The model names two real companies but reverses which acquired which.

C. The model cites a real paper that does not support the claim.

D. The model says it inspected a file that it never received.

E. The model answers a question even though the available evidence is insufficient.

F. The model gives the same generic recommendation after the decisive facts
   of the problem have been reversed.

All six can produce plausible text.

Evidence, Truth, and Verifiability

Sat, 29 Aug 2026 23:20:00 +0100

Chapter 2 gave us a rule for talking about hallucination precisely:

Relative to what reference did the output fail?

That question immediately creates another one.

What counts as a reference strong enough to constrain the answer?

Suppose a model says:

Company A acquired Company B in 2024.

There are several different things we might mean when we ask whether this is acceptable:

What exact proposition has been asserted?

Is that proposition true at the relevant time?

Do we possess evidence for it?

Does that evidence actually support this exact relationship?

Can we identify the source and passage that support it?

Where did that source come from?

Is the source sufficiently reliable and current for this claim?

Is the evidence package sufficient for the action we want to authorize?

Could the claim be verified by this system now?

Has the verification actually been performed?

Would the active policy allow the claim to be published or acted upon?

Those questions are related.

Knowing When Not to Answer

Sun, 30 Aug 2026 11:15:00 +0100

Chapter 10 ended with an ambiguity.

A model gave weak, generic advice.

Perhaps it ignored decisive evidence.

But perhaps the evidence never justified a decisive answer in the first place.

Those are not the same failure.

Consider this question:

What was Company A's Q3 revenue?

and this evidence:

Q1 revenue was $41.2 million.
Q2 revenue was $43.8 million.
The company expects second-half demand to improve.

A language model can easily produce something that sounds reasonable:

Appendix: The Evidence Ledger

Mon, 31 Aug 2026 09:00:00 +0100

The book argues that a claim should be governed by its provenance, its evidential support, and an explicit statement of what it does not establish. This appendix applies that discipline to the book itself.

Every original empirical number produced for this book is listed here with three things: where it was measured, what its provenance status is, and what it does not establish.

Two facts are visible immediately from the ledger: