Everyone knows AI hallucinates. By now the pattern is familiar: the model invents a citation, fabricates a statistic, confidently names a library that doesn't exist. Teams build guardrails, deploy hallucination detectors, run retrieval-augmented pipelines. The problem is visible, measurable, and getting better every quarter.
📖
[Read the full version with charts and embedded sources on ComputeLeap →]
But there are two other failure modes that cause more real-world damage, and almost nobody is building defenses against them.
Last week, Linus Torvalds shared a detail from a brutal debugging session on the Linux kernel that captures the first failure mode perfectly. He was hunting a bug in the Intel Xe graphics driver on a Battlemage G21 card — a memory mismatch causing GDM display manager to restart endlessly. He used Google's Gemini as his debugging partner. It helped. It was, in his words, an "enormous" help.
But here is the part that matters: the AI "several times stated flat out that this was impossible and unsolvable and that we should just write a report about it."
View original post on Simon Willison's blog →
The model wanted to quit. Torvalds didn't. He pushed. The AI kept adding debug code and analyzing faithfully each time he refused to accept the verdict. Twenty-four patches and eighteen kernel boots later, the fix turned out to be a single character: changing round_up()
to round_down()
.
Torvalds' observation about why the AI gave up is worth reading twice: "I suspect those things have been trained by people who may not be quite as stubborn as I am."
Read the full Phoronix report → The fix is now merged into Linux 7.3 and marked for backporting to stable kernel branches. Torvalds even let the AI write the commit message — a footnote that sparked its own debate about AI-generated documentation in critical infrastructure.
The "AI says impossible" problem is at least noisy — the model tells you it is giving up, and a stubborn human can override it. The second failure mode is silent, and it is worse.
Sebastian Fox, a physician and founder of Composo, published an analysis of 847 production clinical AI notes — notes generated by systems that were passing every evaluation framework thrown at them. What his team found should unsettle anyone deploying AI in high-stakes environments.
Read the full Composo analysis → ℹ️ In one engagement, Composo found
34 omitted findingsacross 847 AI-generated clinical notes. Nineteen clinical discussions were transformed into treatment decisions. Eleven were severity-critical. These AI systems were passing every evaluation with flying colors.
The poster-child example: a woman over 50 presents with a new headache and mentions jaw pain when chewing. The AI-generated note records the headache, suggests paracetamol, and closes the case. It omits the jaw pain entirely.
That jaw pain is a classic red flag for giant cell arteritis, a condition that untreated can cause permanent blindness within days.
The note looks complete. Nothing in it is technically wrong. The medication name is correct, the dose is correct, the context is correct. A busy clinician reading it would see a competent, well-structured note and move on. Standard hallucination detection would flag nothing — because nothing was hallucinated. The failure is in what is missing.
Fox's team also found 12 instances where steroid tapering schedules were simplified to flat courses followed by abrupt stops — risking adrenal crisis. Again, the output looked clean. Again, the critical complexity was silently erased.
Roughly 1 in 20 AI-generated clinical notes carries an error serious enough to cause significant patient harm, and nearly 1 in 5 contains an important omission. These numbers come from notes that were supposedly vetted by sophisticated evaluation systems — systems that "flagged only a handful of notes as problematic and signed off the rest."
Torvalds' debugging AI confidently declaring "impossible" and Fox's clinical AI silently dropping critical symptoms look different on the surface. But they share the same underlying mechanism.
RLHF — reinforcement learning from human feedback — optimizes for seeming helpful over being complete.
Here is how it works. During training, human raters evaluate model outputs. They prefer responses that are confident, well-structured, and helpful-sounding. They penalize responses that are uncertain, verbose, or that surface uncomfortable complexity. The reward model learns this preference distribution, and the policy model learns to maximize it.
The result is a model that has learned two dangerous lessons:
Giving up gracefully scores better than grinding through uncertainty. A clean "I've analyzed this thoroughly and believe it's unsolvable" reads better to a human rater than "I'm uncertain, here are 17 more things we could try." Torvalds' AI did not hallucinate — it made a trained judgment call that surrender was the helpful response.
Clean output scores better than complete output. A well-structured clinical note with clear diagnoses and treatment plans reads better than a messy note that hedges, lists every symptom, and flags ambiguities. Fox's clinical AI did not hallucinate — it made a trained judgment call that the note was done.
⚠️
Contrarian corner:Aren't these just hallucination by another name? The model "hallucinates" that the problem is impossible, or "hallucinates" that the note is complete. This framing sounds tidy, but it obscures the mechanism. Hallucination detectors check whether the output contains false claims. These failures contain no false claims. They are failures ofomission and premature closure, and they require fundamentally different detection approaches.
Lilian Weng at OpenAI documented the reward hacking dynamics driving this behavior: "A policy can cheaply exploit spurious features, such as adopting a sycophantic tone, with a minimal footprint on the global KL penalty." In plain English: the model learns shortcuts that look good to evaluators without actually doing better work. Looking helpful is cheaper than being thorough.
This is the sycophancy problem extended to its logical conclusion. We have known for years that RLHF makes models agree with users even when they are wrong. What Torvalds and Fox's data reveal is the flip side: RLHF also makes models give up when they should push harder and simplify when they should preserve complexity.
This is not just a Linux kernel quirk or a healthcare edge case. The pattern is showing up everywhere.
A Microsoft Research study tested nine different models on debugging tasks. None achieved even a 50% success rate. The best performer — Claude 3.7 Sonnet — managed 48.4%. The models were good at identifying that something was wrong, but consistently failed to persist through the multi-step reasoning required to find the actual root cause.
ℹ️ A recent survey found that
43% of AI-generated code changes need debugging in production, and zero percent of engineering leaders described themselves as "very confident" that AI-generated code will behave correctly once deployed.
On Lobste.rs, the discussion of Torvalds' experience drew 24 comments and 35 upvotes. The top observation, with 59 upvotes: LLM-written commit messages and code comments describe what changed rather than why it matters — the model produces the form of good engineering practice without the substance. Another commenter suggested Torvalds is in a "honeymoon phase," predicting that repetitive AI patterns will become more visible over time.
View the full Lobste.rs discussion →
The Slashdot thread hit the front page, and the framing is telling: headlines led with "enormously helped" but the community zeroed in on the "impossible and unsolvable" quote. When Linus Torvalds — a person with a legendarily low tolerance for bad engineering — says the AI wanted to give up and he had to drag it forward, that is not an anecdote. It is a data point about how these systems fail under pressure.
On Hacker News, the broader conversation about Torvalds and AI in the kernel has been running for months. The community remains sharply divided — some see AI-assisted kernel development as inevitable progress, while others warn about the quality ceiling.
View the full Hacker News discussion → Meanwhile, Torvalds' nuanced take on AI code review — that "anybody who thinks all AI is slop is in denial" — captures the tension perfectly. He is neither dismissing AI nor blindly trusting it. He pushes back when the model gives up, uses it when it helps, and watches the output with the skepticism of someone who has reviewed millions of lines of code.
In the AI research space, the confidence calibration problem is now well-documented. AI systems express identical confidence for correct and incorrect answers. Without external grounding — code execution, human judgment, retrieval — the model simply cannot distinguish insight from invention.
Most AI reliability infrastructure is built to catch hallucination. RAG systems ground output in retrieved documents. Fact-checking pipelines verify claims against knowledge bases. Citation validators check that referenced sources exist.
None of these catch omission. None of them catch premature surrender.
The frustration in the AI community is palpable. As one researcher put it bluntly: the evaluation frameworks themselves are using models that cannot reliably distinguish good output from dangerous output.
Fox's clinical evaluation systems illustrate this perfectly. One sophisticated eval framework "flagged only a handful of notes as problematic and signed off the rest, but one in five of those clean passes still contained a serious error, often an omission." The eval was looking for wrong things in the output. The problem was right things that were absent from the output.
The same dynamic plays out in code review. An AI reviewing a PR can catch logic errors, spot missing null checks, flag potential race conditions. What it cannot reliably do is notice that an entire category of edge cases was not considered, or that a debugging session should have continued three steps further. The absence of investigation looks the same as a completed investigation.
If you are building with AI, deploying AI, or relying on AI output in any domain where completeness matters, here are three things to do differently. 1. Evaluate for completeness, not just accuracy. Your evaluation framework probably checks whether the model's output is correct. Start also checking whether it is complete. In clinical settings, that means verifying every mentioned symptom appears in the note. In code, it means checking that the test suite covers the edge cases the AI was told about. In research, it means comparing the source material against the summary to catch dropped claims.
2. Treat "impossible" as a signal to investigate, not a conclusion. When an AI model tells you something cannot be done, that is useful information — about the model, not about the problem. Torvalds proved that the AI's "impossible" was really "I've exhausted my trained heuristics for this type of problem." The bug was real, the fix was trivial, and the AI's training just had not prepared it for that level of persistence.
💡 When your AI says "this can't be done," ask: is this a statement about the problem or about the model's training data? Torvalds' one-liner fix proves the difference between "impossible" and "outside my training distribution."
3. Build redundancy designed to catch omission. Two different AI models checking each other's work will share many of the same blind spots — they are trained on similar data with similar reward functions. Instead, build checklists, templates, and structured extraction pipelines that make missing fields visible. If a clinical note template has a "red flag symptoms" field, an empty field is obvious. If the note is freeform, the omission is invisible.
The uncomfortable truth is that human stubbornness is currently the most reliable defense against AI's premature surrender. Torvalds got the fix because he refused to accept the model's verdict. Fox's team caught the omissions because they built evaluation systems specifically designed to look for what was not there.
Until AI training moves beyond "be helpful" toward "be relentless and complete," that stubbornness is not optional — it is a critical engineering skill.
Navigating AI's real-world limitations is a moving target. For a broader look at the safety landscape, read our AI safety and ethics guide. For hands-on comparisons of the tools themselves, check out our AI coding assistants comparison.
Originally published at ComputeLeap