設想一位資深工程師看一眼錯誤日誌，就說「這是連線池被耗盡了」，而且多半是對的。她說不太清楚自己是怎麼看出來的，只知道這種日誌她看過很多次，其中幾次讓她熬了整夜。這種說不清楚、卻能可靠地引導判斷的知識，是工程組織最重要也最難傳遞的資產之一。本文討論的是：當這種知識的養成途徑，以及它所依賴的公共知識來源，都因為模型生成而改變時，組織會在哪裡失去發現自己錯誤的能力。
設想一位郵局分局長某天結帳，終端機顯示帳上短少 3,000 英鎊。她確定自己沒有拿錢，也找不到錯在哪裡。她能怎麼證明？她看不到系統的原始碼，看不到資料庫的交易紀錄，也不知道遠在另一個城市的工程師能不能從後台改動她的帳。她手上唯一的證據是自己的證詞，而對方手上的證據是一張由電腦印出來的帳表。
一家製造複雜系統的公司，要靠許多看不見的東西維持安全：多一顆感測器、多一輪測試、資深工程師可以對時程說不、品質人員的異議能一路送到董事會。這些東西有個共同點：它們的成本每一季都看得到，它們的價值只有在事故沒發生時才存在，而沒發生的事故不會出現在財報上。本文把這類為了吸收錯誤而保留、平時看似閒置的能力稱為糾錯緩衝（Slack）。
設想一個團隊用 agent 完成一個功能：agent 寫規格，依規格寫程式，再寫測試，最後替自己的修改做 review。每一步的輸出都格式完整、語氣專業，測試全綠，review 意見也列得有條有理。團隊按下合併。這是設想，不是事故紀錄，它標出一個常見的形狀：流程上每一道關都過了，但所有關卡的判斷都來自同一個產生內容的來源，沒有任何一關有能力說「不」。
一個離現場很遠的決策者，判斷「沒事」時依賴的通常是三種東西：規則檢查通過了、層級報告說風險可接受、沒有人回報問題。設想一次會議結束前，主持人問：有沒有人有任何限制事項或疑慮？沒有人開口，會議紀錄寫下「無」。這個「無」可以由兩個完全不同的世界生成：真的沒有問題，或有問題但知道的人沒有把它送進這個房間。紀錄本身分不出兩者。
設想一個團隊把各模組的開發速度提高了。每次合併都通過該模組的測試，每個小組的交付指標都在上升。半年後，整合階段的缺陷與返工越來越多，回頭逐項檢查，卻找不到任何一個「錯誤的決定」。這是設想，不是統計；它用來標出一種常見的形狀：每個局部的檢查都為真，整體卻在劣化。
使用規格工作流的工程師、產品負責人與審查者，需要防範一種不容易被符合性測試發現的錯誤：程式忠實實作了要求，要求卻沒有足以支持它的理由。AI 能迅速把一句需求展成提案、規格、設計與工作清單；若團隊只檢查這些產物是否相符，最早的誤解也可能被忠實地傳到部署環境。