Series: What AI Verification Misses

Putting the checks that verify AI-generated output under measurement to see what they actually miss: a merge audit that mistook a parent concept and its subtype for the same thing, a subagent-driven full audit that skimmed list-heavy files instead of checking item by item, re-verifying only against other cases while never rechecking the original false positive, an ingest step where sibling notes copied paragraphs verbatim and nothing caught it at first, and even the embedding filter built to catch that duplication flipping its verdicts depending on model size (small/large), once that filter was removed, duplication turning up in groups that had been recorded as clean, a merge rule whose wrong example was deleted while the rule that produced it stayed, a real-note test that passed cleanly while the fixed code never ran once, and sentences left pointing at nothing after duplicates were removed, blocked shape by shape in code until I switched to having an LLM reread each edited note and judge it.

한국어로 읽기 →

• 몇 주 뒤, 그 감사 장치가 못 보는 경우를 찾았다

  (Korean only)
  26 Sep, 2026

  예전에 32번 중 32번을 다 맞혔던 병합 감사 장치가, 실전에서 상위 개념 노트와 그 하위 유형 노트를 동일 대상으로 오판했다. 원인은 판단력이 아니라 설계 자체 — 그 감사는 처음부터 이 종류의 오판을 잡도록 만들어진 게 아니었다.

• Of the 4 most list-heavy files, the subagent missed 2

  30 Sep, 2026

  A full audit I delegated to Claude Code subagents reported 2 of 56 files as CLEAN when they weren't. An A/B test on the prompt showed that on files dense with bullet lists, 'I read it all' meant a skim rather than an item-by-item check, and a prompt that forces a checklist fixed it.

• I verified on a different pair and never rechecked the original case

  1 Oct, 2026

  I fixed a false positive in my Obsidian plugin's LLM merge-judgment prompt and even closed the GitHub issues, but never retested the case that caused the false positive in the first place. Rerun days later under the real full-vault conditions, the judgment flipped, and actually performing the merge suggested the original call was likely wrong all along.

• LLM-generated sibling notes were copying the same paragraph word for word

  2 Oct, 2026

  Testing my Obsidian plugin on real articles exposed an LLM bug: sibling notes copied the same paragraph verbatim, and embedding duplicate detection missed it.

• Switching embedding models flipped the ranking

  4 Oct, 2026

  Moving from OpenAI's text-embedding-3-small to large flipped the order of true duplicate paragraphs and look-alike sentences mixed at cosine 0.72-0.80.

• Removing the embedding filter caught more duplicates, not fewer

  6 Oct, 2026

  I swapped an embedding filter plus LLM checks for one LLM review of all sibling notes to catch duplication. One hub-note rule took precision from 55% to 100%.

• I deleted the wrong example from my LLM note-merge rule, but the rule stayed

  25 Oct, 2026

  My Obsidian plugin's LLM rule for merging duplicate notes blocked even same-product notes. I traced it, tested real merges, and adopted Karpathy's LLM Wiki.

• My LLM note-merge test passed, but the fixed code never ran once

  26 Oct, 2026

  I fixed an LLM note-merge bug in my Obsidian plugin and reran it on real notes. It passed, but the fixed code never ran until I restored the pre-merge state.

• When an LLM removed duplicates from my notes, the remaining sentences lost what they pointed to

  27 Oct, 2026

  Removing note duplicates with an LLM left 'this technology stack' and 'also' pointing at nothing. I stopped adding code rules and had an LLM judge each edit.