コーディングエージェントが失敗したとき、原因が「考え方を間違えた」のか「書き方を知らなかった」のかで、打つ手が正反対になります。Aid-Onでgolemideを作って計測したところ、失敗した試行はすべてコンパイルエラーで、答えそのものが間違っていたことは一度もありませんでした。
モデルは何をすべきかは分かっていて、その言語での書き方を推測して外していた、という結果です。
推測させない
対策は単純で、書き方を先に渡すことになります。golemideは三段階で言語リファレンスを探します。環境変数で明示された場所、プロジェクトに同梱された CHEATSHEET.md、ツールチェーンが自分で出力できるもの。
見つからない言語には何も渡さず、渡さなかったことを実行結果に書きます。48KBを超えるリファレンスは切り詰めて、切り詰めたと記録します。黙って半分だけ渡すと、無かった部分を推測で埋められてしまうためです。
四段のループ
Observe はプロジェクトを調べ、検証コマンドを実行します。ここではモデルを一切呼びません。Read で関連ファイルを選びます（小さなプロジェクトであれば、ここもモデルを使いません）。Edit はファイル全体を書かせて、書き込む前に構文チェッカへ通します。Verify は検証コマンドを再実行し、その終了ステータスで成否を決めます。失敗したら、実際の差分と拒否された編集を次の試行へ渡します。
検証コマンドが指定されていなければ、一回だけ書いて止まります。二回目が良くなったかを確かめる手段がないためです。
構文チェックの限界も明示されています。言語によっては括弧とリテラルの釣り合いしか見られません。検査できなかったものは報告され、最終的な判定はプロジェクトの検証コマンドが持ちます。
遅い応答を、二重に投げる
モデルの応答が120秒以内に返らないと、同じ要求をもう一本投げて、先に返ったほうを使います。ここで報告するのは、二重に投げた回数だけでなくそれが実際に役立った回数のほうです。役立たなかった分は、払って捨てた二重請求になります。
こうした仕掛けが要るのは、止め方が難しいためです。喋り続けるモデルは待機状態にならないので、無応答の検出では捕まりません。観測された中には、12分かけて1.7MBを出力し続け、手で止めた呼び出しがあります。
数字は、留保ごと持ち歩く
このリポジトリの演習では、23問中23問を0.19ドルで解いています。ただしREADMEには、これは小さな開発用ベンチマークであって一般的な修復成功率でも順位でもなく、モデルの学習データにどれだけ含まれていたかも分からない、と明記しています。
自社の数字を出すときは、この留保ごと出すほうが安全です。数字だけを抜き出すと、別の条件で測った相手と話が噛み合わなくなります。
他の仕組みから呼べる形
編集の結果はJSONで返せます。状態、終了コード、費用、各試行、実行全体の差分、最後の検証出力。編集だけを頼む場合は、書けたら0、理由つきで拒否したら1、入力が編集でなければ2を返します。
エージェントを人が使う道具としてではなく、他の仕組みから呼ばれる部品として置く形です。導入を検討される際は、エージェントが「何を根拠に編集したか」と「書き込む前に何を検査したか」を後から確認できるかどうかを見ると、任せられる範囲が判断しやすくなります。
