ハーネス・エンジニアリングはサイバネティクスである

OpenAIのハーネス・エンジニアリングに関する記事[1]を読みながら、言葉にできない感覚を覚えていた。そして突然、ピンときた。このパターンは以前にも見たことがある——一度ならず、三度も。

最初は1780年代、ワットの遠心調速機[2]だ。それが登場する前は、作業員が蒸気機関のそばに立ち、手動でバルブを調整しなければならなかった。それが登場すると、重り付きのフライボールを持つ機械装置が速度を感知し、自動的にバルブを調整できるようになった。作業員は消え去ったわけではないが、その仕事は変わった。バルブを手で回すことから、調速機を設計することへ。

二度目はKubernetes[3]だ。望ましい状態——レプリカ3つ、このイメージ、これらのリソース制限——を宣言する。コントローラーが実際の状態を継続的に監視する。不一致が生じると、コントローラーは調整を行う。クラッシュしたポッドを再起動し、レプリカをスケーリングし、問題のあるデプロイメントをロールバックする。エンジニアの仕事は、サービスを再起動することから、システムが調整に使用する仕様を書くことへと移行した。

三度目が今だ。OpenAIは、もはやコードを書かないエンジニアのグループを説明している。代わりに、彼らは環境を設計し、フィードバックループを構築し、アーキテクチャ上の制約をルールとしてエンコードする——そしてAIエージェントがコードを書く。5ヶ月、100万行のコード[1]、手書きのコードは一行もない。彼らはこれを「ハーネス・エンジニアリング」（AIエージェントのための「手綱」や「ハーネス」のような制約フレームワークを構築すること）と呼んでいる。

三度、同じパターンだ。ノーバート・ウィーナー[4]は1948年にこれに名前をつけた。ギリシャ語のκυβερνήτης（舵取り）に由来するサイバネティクスだ。もはや手でバルブを回すのではなく、船を操縦するのだ。

このパターンが現れるたびに、そのレベルでフィードバックループを閉じるのに十分な強力なセンサーとアクチュエーターを誰かが作り出したからだ。

なぜコードベースが最後の砦なのか

コードベースにはフィードバックループがないわけではない。ただ、より低いレベルに存在するだけだ。コンパイラは構文レベルでループを閉じる。テストスイートは振る舞いレベルでループを閉じる。リンターはスタイルレベルでループを閉じる。これらは本物のサイバネティックな制御装置だ——しかし、機械的に検証可能な特性しかチェックできない。コンパイルは通るか？テストは合格するか？ルールに従っているか？

それより上のすべて——この変更はシステムアーキテクチャに沿っているか？このアプローチは正しいか？この抽象化はコードベースが成長するにつれて隠れた問題を生み出すか？——には、センサーもアクチュエーターもなかった。人間だけがそのレベルで操作でき、しかも両側を同時に処理しなければならなかった。品質を判断し、修正を書くことを。

大規模言語モデルは両端を同時に変える。人間にのみ許されていたレベルで知覚できるようになり、同じレベルで行動もできるようになる。モジュールをリファクタリングし、一貫性のないインターフェースを再設計し、本当に重要な契約を中心にテストスイート全体を書き直す。初めて、重要な意思決定が行われるレベルでフィードバックループを閉じることができる。

しかし、ループを閉じることは必要条件であって、十分条件ではない。ワットの調速機には調整が必要だった。Kubernetesコントローラーには正しい仕様が必要だ。そしてLLMにあなたのコードベースで作業させるには、さらに難しい何かが必要になる。

センサーとアクチュエーターの較正

基本的なフィードバックループを動かすこと——エージェントが実行できるテスト、解析可能な結果を出力するCI、修正への道筋を示すエラーメッセージ——は、単なるベースラインに過ぎない。カリーニはすでにこれを実証している[5]。彼は驚くほどシンプルなプロンプト[6]を使って16の並列エージェントにCコンパイラを構築させたが、テストインフラは細心の注意を払って設計されていた。「私の努力のほとんどは、Claudeの周りの環境——テスト、環境、フィードバックメカニズム——の設計に費やされた。」

より難しい問題は、あなたのシステムに固有の知識でセンサーとアクチュエーターを較正することだ。ほとんどの人はここで行き詰まり、その後エージェントを責める。

「何度やっても間違える。私たちのコードベースを理解していない。」この診断はほぼ間違っている。エージェントが失敗するのは、能力不足ではなく、必要な知識——「良い」状態がどのようなものか、あなたのアーキテクチャがどのパターンを推奨し、どのパターンを避けるか——があなたの頭の中に閉じ込められ、外部化されていないからだ。エージェントは浸透作用で学ばない。書き留めなければ、100回目の実行でも1回目と同じ間違いを犯す。

この仕事の本質は、あなたの判断を機械可読にすることだ。実際のレイヤーと依存関係の方向を記述したアーキテクチャ文書。修正ガイダンスが組み込まれたカスタムリンタールール。チームの美的基準をエンコードしたゴールデンサンプル。OpenAIもこれに気づいた[1]。彼らは金曜日の20%を「AIが生成したゴミコード」の掃除に費やしていた——その後、基準をハーネス自体にエンコードした。

唯一の出口

これらの実践が要求するすべてのこと——ドキュメンテーション、自動化テスト、成文化されたアーキテクチャ上の決定、高速なフィードバックループ——は、常に正しかった。過去30年間に出版されたすべてのソフトウェア工学の本がこれらを推奨している。ほとんどの人はこれらのステップを飛ばす。なぜなら、飛ばすことのコストは遅く、拡散するからだ。品質の徐々の低下、新規参入者の苦痛なオンボーディング、静かに蓄積する技術的負債。

エージェント工学はそのコストを極限まで高める。ドキュメンテーションを飛ばせば、エージェントはあなたの仕様を無視する——1つのPRだけでなく、すべてのPRで、機械の速度で、24時間体制で。テストを飛ばせば、フィードバックループは単に閉じることができない。アーキテクチャ上の制約を飛ばせば、ドリフトはあなたが修正する能力を上回る。そして罠はこうだ。エージェントが「クリーン」な状態がどのようなものかを知らなければ、エージェントを使ってその混乱を片付けることはできない。較正なしでは、問題を作り出す機械は、それを解決することも同様にできない。

実践は変わっていない。それを無視するコストが耐えられなくなっただけだ。

生成-検証の非対称性——P対NP問題[7]の背後にある直感であり、CobbeらによってLLMで実証的に検証された[8]——が前進の道を示している。正しい解決策を生成することは、それを検証することよりも難しい。あなたは実装能力で機械を凌駕する必要はない。判断能力で機械を凌駕する必要がある。「正しい」状態がどのようなものかを定義し、出力のどこが間違っているかを特定し、方向性が正しいかどうかを判断する能力だ。

ワットの調速機を設計した労働者たちは、二度とバルブを回す仕事には戻らなかった。できなかったからではなく、もはや意味がなかったからだ。

参考リンク [1] ハーネス・エンジニアリング記事: https://t.co/jzMo4arK5s [2] ワットの遠心調速機: https://t.co/ctRxZYFXeZ [3] Kubernetes: https://t.co/D7NdAdi8tV [4] ノーバート・ウィーナー: https://t.co/LGPwF5eL0u [5] カリーニによる実証: https://t.co/2C8va2j7tE [6] 驚くほどシンプルなプロンプト: https://t.co/deEuA0EPtz [7] P対NP問題: https://t.co/i5fKjcuDd0 [8] LLMによる実証的検証: https://t.co/ekSHhMP6zK

> 著者: George (@odysseus0z) > URL: https://x.com/odysseus0z/status/2030416758138634583 > > https://t.co/GqhyL4KRJw