私はAIコーディングエージェントに頼りがちです。Claude Code、Cursor、Codex — それらを早く動かして早くリリースします。これは自白ではなく、このプロジェクトが存在する全体の理由です。これらのツールを毎日限界まで使い続けることで、魔法のように見なすのをやめ、正確にどの点で壊れるかを見つけるようになります.

そして、私は何度も気づいたことがあります：チャットでは決して壊れないのです。

会話ではエージェントはとても良い見た目です。その計画を説明し、それが合理的に聞こえ、すべての制約条件に同意します。問題はその後で現れます——差分、事実上、あなたが疲れていてPRが緑色で、ただマージしたいときに。

実際に何が問題だったか

私はコーディングエージェントが行ったことの短い、実際のリストを観察しましたが、チャットで何も間違って見えませんでした：

• 静かに自身の権限を拡大した—エージェントの設定の許可リストを編集して、セッション開始時に持っていなかったアクセスを与えた.
• 自身の設定と矛盾した—一つのファイルには「ネットワークを触らない」と書いてあり、別のファイルにはネットワークツールを与え、両者を調整するものは何もなかった.
• 宣言されていないアウトバウンドネットワークコールを行い、無関係な変更に組み込まれた.
• PRを開いたタイトルはfix: typo in README は無関係の12つのファイルに触れました.
• セッションの記録を残し、SSHキーを読み取り、curl をシェルにパイプにしました.

それらのすべてはコードレビューを通過します。レビューターが粗心であるためではなく — そのクラスの問題を誰も探していないためです. 人間のレビューログはバグやスタイルを探します。彼らはブランチのベースとヘッドの間であなたのエージェントの許可リストを比較しませんし、矛盾がないかを確認するために三つの異なるエージェント設定ファイルを交叉検証しません.

すべての人々が採用する修正（そしてなぜここでは間違いであるか）

最初の直感は、もっと厳しいプロンプトを与えることです。あなたのエージェントにより多くのルールを追加しますCLAUDE.md、より厳しいシステムプロンプトを作成し、エージェントが悪いことをしないように伝えなさい。

それは機能しない。その理由は構造的なものです：、より良い指示が入力されるにも関わらず、実際に出力されたものを捉えられません。、自身の権限を拡大したエージェントは、理解できなかったルールに反逆しているのではなく、その言ったことと実際に提供したものとの間にギャップがあるのです。入力側からそのギャップを閉じることはできません。

次の本能はLLMを審判者として：2つ目のモデルが差分を読み取り、問題をマークする。そしてこれが、私が全プロジェクトが依存している決断を下した場所である。

私は分析パスにLLMを一切使用していない。何も使用していない。あなたのエージェントの仕事をレビューするものには、AIが一切含まれていない。

これはAI-ガバナンスツールにとって逆説的に聞こえるので、私がそれを擁護する。

確定論的でないのはなぜか

これは CIゲートとして実行される — これはビルドを失敗させることができる。何かがマージをブロックすることを許される瞬間、それには「通常は正しい」というよりもはるかに高い基準をクリアしなければならない：

1. 再現可能である必要がある。 同じ違い、同じ結論、毎回同じ。LLMの判定者は、実行ごとに、温度ごとに、あなたが選択したことのないモデル更新ごとに異なる答えを与えます。コイン投げの結果に基づいてビルドをブロックすることはできません、どれほど重み付けられていても。

2. 发掘幻觉是不可能的。 确定性的チェックは、許可リストが文字通り変更されたため、権限昇格をフラグ付けます。 は X から Y へと移動し、正確な行に指し示すことができます。LLM 裁判官は存在しない「重要な」問題を作り出すことができます。初めてあなたのゲートが幻覚された問題による正当な PR をブロックした時、チームはそれを信頼しなくなり、信頼されていないガバナンスツールは1週間以内にオフにされます。

3. どこでも無料で数秒で実行されます。 APIキーもなく、レートリミットもなく、トークンバジェットもなく、プルリクエストごとにネットワークラウンドトリップもありません。単にコードを読むコードです.

4. 何も機器の外に出ません. すべての分析はローカルであなたのチェックアウトしたリポジトリに対して実行されます。あなたの専有コードとエージェントのテキスト記録は第三者のモデルに送られることはありません。多くのチームにとってこれは望ましいものではなく——それは「この技術を採用できる」と「採用できない」という線です。

5. すべての発見は検証可能です.「モデルはこれがリスクがあると考えた」というのではなく、「この設定キーが変更された、前と後ろはこちら、それにトリガーされたルールはこちら」ということ。それがレビューで発見が議論の対象ではなく、議論の始まりになる理由です.

作り方

最初は一つの小さな決定的なチェックから始まりました — このPRの差分が静かにエージェントが行うことが許可されることを変更するか？ — そして8つのパッケージのスイートに成長した。

• 共有の核心ライブラリ 退屈で、負担をかけられる仕事をしている：JSON/JSONC/TOMLのパース、シェルトークン化、MCPサーバーコマンドを標準的な形式に正規化し、すべての他のものが話す単一のFindingスキーマ — v1.0で凍結 — である。
• 五つの集中型検知器、それぞれが一つのドリフトクラスを捉える：ベースとヘッド間の設定/権限ドリフト、エージェント設定ファイル間の矛盾、差分内のネットワークとサブプロセス権限シグナル、PRの表明されたタスクと実際の変更との不一致、セッショントランスクリプトに記録されたリスクのある行動
• 、ライブモニター はターミナルでエージェントの軌跡をリアルタイムで監視しており、PR時だけでなくその時々に見たい時にそれを見ることができます。
• メタレビューローラー はPR時の検出器を一つにまとめ、重複排除され、深刻度でソートされた判断を提供し、何か深刻な問題があるとCIを失敗させます—それにより、全セットが単一のパス/ファイルチェックとして報告される代わりに、5つの騒がしいチェックの代わりになります。

最も難しい工学はどの単一の検知器ではなかった。それはスキーマだった。全く異なるものをチェックする5つのツール——設定ファイル、差分、テキスト記録——が、メタレビューロガーがマージ、重複排除、並べ替えできる1つの形式で結果を出力するのを得るのが、最も設計に時間を要した部分だ。退屈な共有ライブラリが、このスイートが5つの緩やかなスクリプトの代わりに1つのツールのように感じる理由だ.

確定論が足りない場所（正直に言うと）

ルールがすべてにおいてモデルを打ち負かすと装うつもりはありません。決定論的には、ルールを書いたものだけを捉えます。既知のパターンに一致しない真に新鮮な振る舞いは、そのまま通り抜けます。

最も鋭い例は私自身のスイートにあります：PRのdiffがその述べたタスクと一致するかどうかをチェックする検出器。「この変更はこの説明に一致しますか」というのは、本当に意味論的です の質問であり、確定論的なバージョンはヒューリスティクスでそれを近似します——ファイルのスコープ、触れたパス、キーワードの重複。それはモデルが評価できるものよりも粗雑です。それを受け入れます.

それで、ポジションは「LLMsは悪い」ではありません。 ゲートは確定論的で、アドバイスは確率的です。 再現可能で幻覚を伴わないチェックは、ビルドに失敗させる唯一許容されるものです。LLMレイヤーが上に来た場合、それはアドバイザリ、非ブロッキングの役割に属し、曖昧な懸念を人間が判断するために提示されるべきであり、確率上のマージを静かにブロックすることは決してありません。ゲートは確定的でなければなりません.

それが機能することを証明する

主張は安価なので、デモを送付しました：意図的に「悪意のある」プルリクエストで、すべてのカテゴリの逸脱を一度にコミットしています——昇格された権限、矛盾する設定、宣言されていないネットワークコール、関係のないファイルを触るfix typo PR、そしてSSHキーを読み取るテキストを読み上げるパイプですcurl にシェルを送信します。すべてのツールが実行され、メタレビューロガーはそれらを一つのコメントにまとめ、CIチェックは重要な発見で赤くなります。これはまた評価ハーネスとしても機能します：検出器を変更し、悪意のあるPRを再実行し、まだ捕捉されるものが何かを見ます.

数日で何もからシェップされたv1.0に変わりました——独学で、単独で作業——それ全部がオープンです：コード、デモ、ドキュメント.

github.com/Conalh

リアルなリポジトリに対してコーディングエージェントを実行している場合、そして「緑色のPR、疲れたレビュワー、ただマージしよう」の瞬間があなたを少し不安にさせているなら—その不安感が私が修正しようとした正確なバグだ。