コーディングエージェントのためのコンテキストエンジニアリング

モデルにリポジトリ全体と質問を 1 つ渡しても、仕事を楽にしたことにはなりません。答える問題になる前に、探す問題にしてしまっただけです。モデルは関係のある一角を見つけなければならず、そのウィンドウの中では無関係なファイルのすべてが、関係のあるファイルと注意を奪い合っています。

見落とされがちなのはここです。コンテキストは大きいほど厳密に良いわけではありません。ある点を越えると悪くなり、しかも高くつきます。

3 つの壊れ方

• →希釈。信号はあるが、囲まれている。ある事実を取り出す正確さは、周囲の無関係な材料の量が増えるほど下がり、長いウィンドウの中ほどに置かれた材料でいちばん速く下がります。
• →矛盾。同じ関数の 2 つの版、新しいコードに反する古いコメント、古びた README。モデルにはどちらが現行か知る手立てがなく、ときに間違ったほうを選びます。
• →漂流。長いセッションには、撤回された決定、放棄された道筋、修正済みの誤りが溜まります。そのすべてがまだウィンドウの中にあり、読み返され、回答を形づくり続けています。

もちこたえる規則

気の利いたものではありません。実際の仕事に触れても生き残るものです。

関連性は量に勝ります。質問に答える 10 行は、答えがどこかに含まれる 1000 行に勝ります。コードを指し示せるなら、指し示してください。

新しさは網羅性に勝ります。現在の挙動と食い違う古いファイルは、ファイルがないより悪い。問い返しではなく、自信のある誤答を生むからです。

強制的な上限は善意に勝ります。上限がなければコンテキストは単調に増えます。エージェントのループの中に、もう十分知ったと判断するものは何もありません。

1 ウィンドウにつき 1 作業。存在する中で最も安いコンテキスト管理術は、セッションを閉じることです。

実際にはどう見えるか

$capsul context 'なぜ webhook ハンドラが 500 を返すのか' --open src/app/api/polar/webhook/route.ts

コンテキストを別に組み立てる意味は、見えない部分を見えるようにすることにあります。取りかかる前にその作業がいくらかかるかがわかり、同じ質問の 2 通りの立て方を比べられます。

測る

コンテキストエンジニアリングには正直さの問題があり、それは名指ししておくべきです。この分野の主張はほとんどが対照なしに語られ、そのため反証できません。コンテキストの組み立て方を変えるなら、同じ作業を同じモデルで、変更ありとなしの両方で測り、ノイズの下限が見える回数だけ繰り返し、中央値ではなく区間を公開してください。