この記事は、HumanLayer が常に使っていると著者が言うパターンを説明している。テスト、ビルド、lint の出力をすべて握りつぶし、その段階が成功したら 1 つの ✓ に置き換え、終了コードが非ゼロのときにだけ退避しておいた出力を表示する、というものである。その理由はコストではなくコンテキストにある。テストの実行は数百行を吐き出すことがあり、エージェントは必要な 1 つの失敗を見つけるためにそれを解析しなければならない。そしてすべてが成功した場合には、10 トークン未満に収まる「問題なし」のためにコンテキストウィンドウの 2〜3% が費やされたことになる。著者は、Claude モデルについて彼がおよそ 75k トークンの「スマートゾーン」と呼ぶ範囲の中にとどまるよう強く勧め、「ダムゾーン」でエージェントと格闘して失われる人間の時間は、トークンよりもおそらく 10 倍以上高くつくと論じている。
記事はまた、最近のモデル自身による節約の試み（出力を /dev/null に捨てたり、長いテストスイートを head にパイプしてから再実行する羽目になったりすること）にも反論しており、それは結局、より多くのトークン、人間の時間、精神的なエネルギーを消費することになると述べている。記事は、モデルの振る舞いがこのように調整されたのは、バックプレッシャーの仕組みがコンテキスト効率の良くないコードベースで役立つようにするためではないかと推測し、決定論的なほうが非決定論的なものより良いと結論づけている。何が重要かがすでにわかっているなら、それを判断するために不要なトークンをモデルにかき回させるべきではない。
要点
- 何を切り詰めるかをモデルに決めさせるのではなく、出力を決定論的に制御する。
run_silentというシェルラッパーは、成功時には✓ <description>を、失敗時には✗ <description>とそれに続く完全な出力を表示する。 - 次に改善を重ねる。フェイルファストのフラグ（
pytest -x、jest --bail、go test -failfast）を有効にしてエージェントが一度に 1 つの失敗を扱うようにし、汎用的なスタックフレームやタイミング情報を除外し、フレームワーク固有の解析を加えて、ノイズなしにテスト件数が見えるようにする。 - 著者は、このパターンを顧客の Maven や Gradle のプロジェクトで多用していると報告し、xcodebuild、cargo、その他の冗長なツールでも同様に機能すると述べている。HumanLayer はモノレポのチェックを pre-push フックの中で、また計画の各フェーズごとにこの方法で実行しており、記事によれば、そうしなければその出力はコンテキストウィンドウの約半分を埋めてしまうという。
- 出力をラップしたら、残る仕事はモデルに自前の切り詰めをさせないよう説得することであり、そのために記事はプロジェクトの CLAUDE.md に指示を書くことを提案している（良い CLAUDE.md の書き方 を参照）。
- これらはすべて著者自身の実践に基づくものとして提示されている。記事が示すトークン数の比較は非公式のトークナイザーを使っており、記事自身がそれはおそらく古くなっていると述べている。
背景
この記事は、バックプレッシャー（エージェントの出力を押し返すチェック）に、コンテキストエンジニアリングの制約を加えて適用している。すなわち、そうしたチェックは、コンテキストウィンドウをあふれさせることなく悪い成果物を差し戻すべきだということである。関連するページには コンテキストエンジニアリング、コンテキストロット、Skill Issue：コーディングエージェントのためのハーネスエンジニアリング がある。