GitHubで公開された個人的な実験によると、モデルとハーネスの組み合わせは、AIが生成するフロントエンドコードの品質に大きく影響し得る。出来事の日付である2026年9月8日、Hangar Harness / Model Testsページの著者は、どの組み合わせが最良の結果を生むのかを調べるため、同じプロンプトを異なるモデルとハーネスの構成でテストしてきたと述べた。

プロンプト自体は範囲が狭く、視覚面を重視していた。ホバリングするドローン、警告灯、発光する滑走路の帯、霧の平面を備えた単一ページのThree.js製SF格納庫を構築し、続いてドローン編隊の切り替え機能と映画的なカメラ経路を追加するというものだ。出力はインラインJavaScriptを含む自己完結型のHTMLファイルでなければならなかった。この設定は、タスクを制約しながらも、モデルが設計と実装を選択する余地を十分に残すため有用だ。

ページによると、著者は10通りのモデル／ハーネスの組み合わせを比較した。テストマトリックスにはGLM 5.3 Flash Maxと表記されたGLMの実行が含まれ、ページでは、報告されるトークン数と推論数は各ハーネスがテレメトリーをどのように公開するかによって異なると説明している。また、一部のハーネスは推論数を別個に報告しないこと、一部の所要時間には2回のターンが合算される一方で、その間の休止時間は除外されることも記している。こうした詳細が重要なのは、この比較が整然とした研究室のベンチマークというより、開発者が実際に行う雑然とした現実世界の実験に近いものとなるからだ。

より大きな教訓は、ハーネスの挙動が単なる記録処理ではないということだ。ある構成は推論を個別に表示し、別の構成は出力トークンへ組み込み、3番目の構成はツールエラーを異なる方法で報告するなら、モデルの見かけ上の性能は測定対象によって変わり得る。つまり、ハーネス自体を理解していなければ、モデルの実行結果同士の比較は誤解を招きかねない。

著者はツールエラーも失敗イベントとして記録している。これは、コーディングエージェントの評価が最終的なHTMLファイルだけの問題ではないことを改めて示している。モデルは、タスクについて推論できないために失敗することもあれば、ハーネスに中断されるため、あるいはツールチェーンが摩擦を生むために失敗することもある。実際には、開発者が重視するのは最後に出力されるコードだけではなく、パイプライン全体だ。

この実験は、どのモデルが最良かを決着させたとは主張していない。むしろ、より限定的な問いに答えようとする人物による実用的なメモとして読める。その問いとは、同じプロンプトを異なるオーケストレーション層で実行したとき、実際に何が変わるのかというものだ。AIコーディングツールが増えるにつれ、この問いはますます重要になっている。プロンプトの結果は、もはやモデルだけの関数ではない。周囲の足場、テレメトリー、再試行の挙動にも左右される。

エージェント型コーディングツールを使って開発する人にとって、教訓は明快だ。出力品質がハーネスごとに異なるなら、ベンチマーク結果と日々の開発者体験は、見落としやすい形で食い違う可能性がある。ある環境では弱く見えるモデルが、制御フロー、エラー処理、ログ記録を変更すると、より強く見えるかもしれない。同様に、洗練されたユーザーインターフェースでは安定しているように見えるプロンプトが、最低限の構成ではうまく機能しなくなる可能性もある。

このページは小規模だが、AI開発におけるより大きな傾向を示している。オーケストレーションが製品の一部になりつつあるということだ。モデルは一つの構成要素にすぎない。モデルがどれほどのフィードバックを受け取るか、失敗がどのように記録されるか、目に見える推論が利用者のもとに届くまでにどれほど残るかは、ハーネスが決める。コーディングエージェントを本格的に評価するなら、こうした層はもはや任意の細部ではない。それ自体が結果の一部だ。