Dev.toにSeptember 21, 2026掲載された投稿で、Info InletはAI生成コードについて、別文脈の第2読者が壊そうとして失敗するまでマージすべきではないと主張した。根拠は、AIに本番想定のアプリケーションロジックを100%書かせた30日間の経験だ。Info Inletによると、「お金がかかっている」状況では、普通のプロンプト、通過したテスト、整った差分があっても危険なバグはすり抜けた。提案されたルールはRefutation Gateと呼ばれ、レビュー担当の唯一の仕事は、コードを失敗させる具体的な入力、順序、状態を見つけることだ。

投稿は、LLMに「このコードをレビューして正しいか教えて」と頼む方法は、自分の出力を確認させるため効果が薄いとする。Info Inletは確認と反証を別の仕事として位置づける。確認はモデルに自分自身への同意を求め、反証は具体的な失敗の提示を求める。推奨されるレビュー担当は、コード作成の過程を見ていない新しい文脈であり、著者は30日間の実験で「単一で最もレバレッジの高い変更」は、レビュー担当に別のモデル系統を使うことだったと述べた。似たモデルは同じ盲点を共有しうるからだ。

投稿内のbreak-it briefは、レビュー担当に厳しい失敗モードを仮定させる。最悪の瞬間にネットワークがパケットを落とす、2つのプロセスが同時に走る、外部呼び出しの成功後にデータベース書き込みが失敗する、ユーザーが予想外の行動を取る、といった場面だ。レビュー担当は、データや顧客の金銭を失わせる正確なシナリオを特定するよう求められる。そうしたシナリオが存在しないなら、何が真でなければならないかを説明する必要がある。投稿によると、この指示はモデルの目的を、きれいに見えるコードの承認から特定の失敗探しへ変える。

中心例は、Stripeのwebhookハンドラーだ。イベントを検証し、すぐStripeにHTTP 200を返し、その後で`db.savePayment(event)`を呼ぶ。Info Inletによると、すべてのテストは通過し、コードが正しいか尋ねられたAIレビュー担当は低遅延の応答を評価した。Refutation Gateの下では失敗は明白だった。200応答後にデータベース書き込みが失敗すれば、Stripeは支払いイベントが配送済みだと判断するが、データベースには記録がない。支払った顧客はアクセス権や支払い履歴を持たない状態になる。

投稿は、修正策として先に支払いを永続化し、その後でwebhookに応答すべきだと述べた。ただし、より広い教訓は、テストと読みやすさが本番での正しさを証明しないという点にある。Info Inletは、強いbreak-it briefを与えられた第2のAIでも、著者と同じモデル系統の場合は同じwebhookを承認することがあったと報告した。提示された説明は、両モデルが同じ「きれいなwebhookコード」パターンを学習しており、同じ誤りをより強い確信とともに再現しうるというものだった。

投稿によると、あるシニアエンジニアはwebhookの問題を5分で見抜いた。彼女は2021年に同じack-before-write障害で呼び出された経験があったためだ。Info Inletは、人間の役割は機械より多くコードを書くことではなく、マージ判断を所有し、モデルの文脈ウィンドウ内で常に利用できるとは限らない過去の本番障害を記憶することだとする。最終パターンは4手順だ。AIに自分のコードを確認させない。クリーンな文脈の第2読者を加える。承認用ではなく破壊用のbriefを渡す。本番インシデント経験者が望ましい人間をマージ判断に残す。

Dev.toにSeptember 21, 2026掲載された投稿で、Info InletはAI生成コードについて、別文脈の第2読者が壊そうとして失敗するまでマージすべきではないと主張した。根拠は、AIに本番想定のアプリケーションロジックを100%書かせた30日間の経験だ。Info Inletによると、「お金がかかっている」状況では、普通のプロンプト、通過したテスト、整った差分があっても危険なバグはすり抜けた。提案されたルールはRefutation Gateと呼ばれ、レビュー担当の唯一の仕事は、コードを失敗させる具体的な入力、順序、状態を見つけることだ。

投稿は、LLMに「このコードをレビューして正しいか教えて」と頼む方法は、自分の出力を確認させるため効果が薄いとする。Info Inletは確認と反証を別の仕事として位置づける。確認はモデルに自分自身への同意を求め、反証は具体的な失敗の提示を求める。推奨されるレビュー担当は、コード作成の過程を見ていない新しい文脈であり、著者は30日間の実験で「単一で最もレバレッジの高い変更」は、レビュー担当に別のモデル系統を使うことだったと述べた。似たモデルは同じ盲点を共有しうるからだ。

投稿内のbreak-it briefは、レビュー担当に厳しい失敗モードを仮定させる。最悪の瞬間にネットワークがパケットを落とす、2つのプロセスが同時に走る、外部呼び出しの成功後にデータベース書き込みが失敗する、ユーザーが予想外の行動を取る、といった場面だ。レビュー担当は、データや顧客の金銭を失わせる正確なシナリオを特定するよう求められる。そうしたシナリオが存在しないなら、何が真でなければならないかを説明する必要がある。投稿によると、この指示はモデルの目的を、きれいに見えるコードの承認から特定の失敗探しへ変える。

中心例は、Stripeのwebhookハンドラーだ。イベントを検証し、すぐStripeにHTTP 200を返し、その後で`db.savePayment(event)`を呼ぶ。Info Inletによると、すべてのテストは通過し、コードが正しいか尋ねられたAIレビュー担当は低遅延の応答を評価した。Refutation Gateの下では失敗は明白だった。200応答後にデータベース書き込みが失敗すれば、Stripeは支払いイベントが配送済みだと判断するが、データベースには記録がない。支払った顧客はアクセス権や支払い履歴を持たない状態になる。

投稿は、修正策として先に支払いを永続化し、その後でwebhookに応答すべきだと述べた。ただし、より広い教訓は、テストと読みやすさが本番での正しさを証明しないという点にある。Info Inletは、強いbreak-it briefを与えられた第2のAIでも、著者と同じモデル系統の場合は同じwebhookを承認することがあったと報告した。提示された説明は、両モデルが同じ「きれいなwebhookコード」パターンを学習しており、同じ誤りをより強い確信とともに再現しうるというものだった。

投稿によると、あるシニアエンジニアはwebhookの問題を5分で見抜いた。彼女は2021年に同じack-before-write障害で呼び出された経験があったためだ。Info Inletは、人間の役割は機械より多くコードを書くことではなく、マージ判断を所有し、モデルの文脈ウィンドウ内で常に利用できるとは限らない過去の本番障害を記憶することだとする。最終パターンは4手順だ。AIに自分のコードを確認させない。クリーンな文脈の第2読者を加える。承認用ではなく破壊用のbriefを渡す。本番インシデント経験者が望ましい人間をマージ判断に残す。