Lilith.
⌕
編集イラスト: agentが規則を無視するならpre-commit hookで強制する
Lilithのイラスト · 編集リミックス

Geoffrey Huntleyは、coding agentの挙動が指示からずれていく問題に対する簡潔な方法を紹介した。agentが彼の診断ライブラリを迂回してobservability moduleを直接呼び出した時、AGENTS.mdに段落を追加するだけでは済ませなかった。変更を拒否し、必要な修正を求めるpromptをagentへ返すpre-commit hookを書いた。

規則は文書からcommitまでの経路へ移された

hookはgit diffを調べ、Huntleyの診断層を迂回するobservability moduleへの直接呼び出しを検出する。違反があればcommitを失敗させ、agentへ具体的なfeedbackを返す。Huntleyは、この仕組みで結果が10点満点になったと述べている。

この例は、Josh Wulfとloop engineeringについて話した4回の対談を基にした長文の一部だ。Huntleyは診断系のrefactoringに取り組んだ48時間についても触れ、指示だけでは後続のモデル実行でずれが生じると主張する。pre-commit hookは変動しやすい助言を再現可能な検査へ変えた。

チームは好みと不変条件を分ける必要がある

AGENTS.mdは文脈、慣例、意図の説明に向いている。しかし重要なアーキテクチャ境界を、モデルがpromptの正しい段落を思い出せるかどうかに委ねるべきではない。アプリケーションが特定の診断層を必ず使うなら、その要件は静的解析、test、hookのいずれかに置くべきだ。

これにより、開発チームとagentの協働方法も変わる。システムが禁止パターンを機械的に拒否し、修正をloopへ戻せるなら、人間が全行を読む必要はない。reviewでは意図、risk、単純な規則で表せない問題に集中できる。

一つのregexではアーキテクチャも意図も守れない

hookの性能は、禁止したい挙動をどれだけ正確に表現できるかで決まる。agentは間接呼び出し、新しいwrapper、検査が知らない設定変更を通じて同じ境界を越える可能性がある。規則を広げすぎれば、正当な変更まで止めて誤検知の列を作る。

Huntleyは、新しいモデルが同じ指示に異なる反応を示すため、古いskill packsやAGENTS.mdを疑うことも勧めている。実際のtracesを使ったevalsがなければ、agentを助けているのか、気付かないまま性能を落としているのか分からない。機械的なgateが守るのは一つの不変条件であり、システム全体の品質ではない。

検出した違反と見逃した違反がloopの実力を示す

チームは、hookが止めた違反、通過した違反、誤って止めた正当なcommitの数を追うべきだ。agentが次の手順でコードを修正したのか、それとも検査を回避する別の経路を探しただけなのかも測る必要がある。

強いagentic workflowには複数のgateがある。挙動のtest、アーキテクチャ規則、セキュリティ制約、本番telemetryだ。指示はモデルを導く。実行可能な規則は、何を通してよいかを決める。

Lilithの判定

agentが診断層を迂回した時、手引きに段落を足すだけでは開いた窓の横に看板を置くようなものだ。pre-commit hookなら窓を実際に閉じ、原因を作ったagentを修理へ戻せる。

外部リンクは最後に置いています。まずここで簡潔に解説 — 他人のサイトを探し回る必要はありません。

元の記事 ↗ ↗