Geoffrey Huntley が説明する自律的なコーディングループにおいて、バックプレッシャーとは、無効なコード生成を拒否するためにループに組み込まれたもののことである。彼の前提は、コードを生成すること自体は今や安価であり、難しいのはエージェントが正しいものを生成したことを確かめることだ、というものである。そのため、悪い出力を押し返すチェックこそがエンジニアリングの労力を注ぐ場所になる。プログラミング言語によっては、その型システムによってバックプレッシャーが本来的に備わっている。それ以外にも、テスト、静的解析ツール、セキュリティスキャナーなど、無効な出力を拒否し、全体としてループを速く回せるものであれば何でもバックプレッシャーになりうる。
用法
ここで説明する用法は 「ソフトウェアエンジニア」としての Ralph Wiggum によるもので、そこではバックプレッシャーは Ralph Loop において生成に続く第二のフェーズである。そこで著者が常に与えている指示は、機能を実装したり問題を修正したりした後に、エージェントが変更したコードの単位のテストを実行することである。彼は言語の選択も同じ軸に沿ったトレードオフとして扱っている。Rust の型システムは、彼がコンパイラに求めた極めて高い正確性をもたらすが、コンパイルが遅く、モデルが一度で正しい Rust を書くのが難しいため、変更一つあたりの試行回数が増える。彼の言葉で言えば「車輪が回る速さ」が、正確性と天秤にかけられるのである。同じ投稿はこの用語を失敗の説明にも使っている。ビルドとテストを何百もの並列サブエージェントに展開すると悪いバックプレッシャーが生じる。そのため、その投稿のプロンプトでは、検索やファイルの書き込みには多数のサブエージェントを許可する一方で、ビルドとテストには一つしか許可していない。
Addy Osmani は エージェント時代のコード品質 で、この用語をデリバリーパイプライン全体の規模で使っている。そこでは、バックプレッシャーは多くのツールで実装できる。無効なコードを拒否するコンパイラ、失敗するテスト、悪い慣行をブロックするセキュリティポリシー、デプロイを拒否する CI などであり、生産を品質基準に沿って流し続けるためのあらゆる制約が、パイプラインにバックプレッシャーを生み出す。彼は、バックプレッシャーは理想的には最後の一回のレビューとしてではなくループ全体を通じて存在すべきであり、CI がデプロイを拒否するのを待つのではなく、シグナルをできるだけ早く活用すべきだと主張している。
HumanLayer の コーディングエージェントのためのコンテキスト効率の良いバックプレッシャー は、それらのチェックがエージェントに結果を返す方法について、コンテキスト効率が良くあるべきだという制約を加えている。この投稿のパターンは、テスト、ビルド、lint の出力を握りつぶし、ステージが成功したときにはエージェントに ✓ だけを見せ、失敗したときにだけ完全な出力を表示するというものである。そうしないと、成功した実行がエージェントには不要な何百行もの出力でコンテキストを消費してしまうからである。これに加えて、エージェントが一度に一つの失敗だけを見るようにする fail-fast フラグ、スタックフレームやタイミングのノイズの除去、フレームワーク固有のテスト件数の解析を組み合わせている。そして、この判断はモデル自身による切り詰めに任せるのではなく、ラッパーによって決定論的に行うべきだと主張している。
適用される場面
バックプレッシャーは、無人のループでコードを生成するエージェントに当てはまる。そこでは人間が各イテレーションをレビューすることはなく、悪い変更の上にさらに積み上げられるのを防ぐのはチェックである。この概念は、そうしたチェックが存在し、ループを止めてしまわない程度に速く実行されることを前提としている。著者は、動的型付け言語で静的解析ツールや型チェッカーなしにループを回すと「結果の焚き火（a bonfire of outcomes）」になると述べており、さらにもう一つの実践と組み合わせている。各ループは新しいコンテキストで始まるため、エージェントに各テストがなぜ重要なのかを記録させ、後のループが、失敗したテストを修正すべきか、変更すべきか、削除すべきかを判断できるようにするのである。この枠組みは一人の実務者によるものであり、測定された比較ではなく、コンパイラを作った彼自身の経験から論じられている。
Osmani は、パイプラインの規模でこれが破綻するケースを挙げている。変更の量がチェックの処理能力を超えると、人間の速度で進む検証の後ろに作業が滞留する。彼が挙げる選択肢は、検証システムをスケールさせること、エージェントが変更を生成する速度を下げること、品質の基準を下げることであり、最も重要なところには強い制約を適用し、何の役にも立たない制約は緩めることを推奨している。これも測定された結果ではなく、一人の著者の主張として提示されている。
HumanLayer の投稿は、独自の失敗モードを付け加えている。コンテキストウィンドウをあふれさせる検証である。コンテキストの上限近くで作業するエージェントは成果が悪くなるため、成功しても何百行も出力するチェックには依然としてコストがかかり、モデル自身の回避策、つまり出力を捨てたり head にパイプしたりしてから遅いテストスイートを再実行することは、さらに多くのトークンと人間の時間を浪費すると主張している。その推奨は、HumanLayer 自身のモノレポと顧客の Maven および Gradle プロジェクトでの著者の実践に基づくものであり、測定された比較に基づくものではない。