Verification Asymmetry

Context

You’re maintaining or reviewing code in a regime where the LLM is more able to read and reason about it than you are at any given moment. You ask “does this handle case X?” The LLM responds confidently. You can’t easily verify the answer by skimming the code, because the code is large, dense, or unfamiliar enough that human reading is slow. You accept the answer.

Cost type

Primarily behavioral. The LLM is sometimes wrong — confidently, fluently, in a register that sounds informed. When it’s wrong about a behavioral question (does this handle null inputs, is there a race here, does this validate the auth token), the consequence is a real bug shipped on the strength of a wrong answer that was never independently verified.

What goes wrong

• You ask “does this handle X?” The LLM answers “yes, it does — see how the function checks Y.” It’s a plausible-sounding hallucination; the function doesn’t actually do that. You ship.
• The LLM correctly describes the code’s intended behavior but misses an edge case in execution. The intent is right; the implementation is wrong; the LLM read the intent off the names and missed the bug.
• A code review that should catch the issue defers to the LLM (“the AI says it’s fine”). The reviewer has accepted a verification they didn’t perform.
• The LLM correctly identifies the behavior at the time of asking, but a subsequent change invalidates the answer — and the belief that the code is correct outlasts the verification.

Prospective indicators

• You’re about to ship a change based on an LLM’s affirmative answer to a behavioral question, and you haven’t read the relevant code yourself.
• A code reviewer’s approval cites the LLM’s analysis rather than their own reading.
• “The model says this is safe” is being treated as a sufficient signal for production readiness in a context with real downside.

Retrospective indicators

• Bug investigations reveal “we asked, and the AI said it would handle that.” The asking happened; the verification didn’t.
• Reviewers approve PRs they later, on incident review, admit they didn’t read carefully because they trusted the model.
• The same kind of bug recurs in different forms across different changes — the failure mode is in the verification process, not the individual change.

Prevention

• For behavioral questions (correctness, security, edge cases), independent verification matters. Either read the code yourself, or write a test that pins the answer, or both.
• Treat the LLM’s behavioral claims as hypotheses to verify, not conclusions to ship.
• Automated tests at the application boundary are insurance against this failure mode. The test, not the LLM’s reasoning, is the certification.
• For high-stakes paths (auth, payments, data integrity, anything regulated), explicitly require human reading at PR time. Don’t gate on LLM analysis alone.

When this isn’t a failure mode

• Cognitive questions (“what does this code do?”, “is this code idiomatic?”, “where would you add this feature?”) — the LLM is usually trustworthy here; the cost of wrong answers is rework, not a shipped bug.
• Throwaway code where bugs cost nothing.
• Code where automated tests at the application boundary independently certify behavior. The LLM’s claim is then redundant rather than load-bearing.

Note

This is the failure mode that most distinguishes AI-collaborated work from unaided work. Unaided developers face their own cognitive limits and know they face them; they reach for tests, types, code review, paired reading. AI collaboration introduces a confident-sounding intermediary that can mask the limit without removing it. The discipline is to keep behavioral verification anchored in something other than the model’s answer.