AIに嘘をつかせない完璧な方法 - leceipts
(github.com/0oooooooo0)AIコーディングツールを使っていると、妙に繰り返される状況があります。
バグを説明すると
→ 「問題を修正しました」
→ 実行してみると、まだ壊れている
これは単なるAIの問題というより、
人間のコードレビューでもおなじみのパターンでもあります。
• 「たぶんこれでいけるはず」
• 「ローカルでは問題なく動く」
• 「テストは回していないけど問題なさそう」
leceiptsは、これを態度や文化ではなく、
プロセスで解決しようとするアプローチです。
コードを変更するたびに、次の内容を構造的に残すことを強制します:
• Root cause: なぜ問題が発生したのか
• Change: 実際にどのような修正を加えたのか
• Recurrence prevention: 同じ問題が繰り返されないようにする方法
• Verification: どのように検証し、結果がどうだったか
• Remaining risk: まだ確認できていない部分
ここで重要なのは「Verification」です。
単に「テストした」ではなく、
どのような方法で確認し、結果がどうだったかまで記録させます。
この構造ができると、いくつかの変化が生まれます
- AIの虚偽報告を防げる
「fixed」と言う代わりに、実際の実行結果を残さなければならない
→ 実行していなければすぐに露見する - 人間のコードレビューの品質向上
PRの説明が「勘」ではなく「根拠」中心に変わる - デバッグ履歴が資産になる
なぜ壊れ、どう直したのかが蓄積される
→ 同じ問題の再発防止につながる - 「Done」の基準が明確になる
修正 ≠ 完了
検証まで終えて初めて完了
興味深いのは、これが新しいテストフレームワークや
複雑なツールではないということです。
単に
「説明の仕方を強制するだけで開発プロセスを変える」
というアプローチです。
AIコーディングがますます増えるほど、
こうした「検証中心のワークフロー」がデフォルトになるかもしれないと感じます.
まだコメントはありません。