AIに富んだ文脈を持つハーネスの提唱

# 論文：コードAIアシスタントの品質はモデルよりも「ハーネス」にある - コードベースのどの部分を目にするかを決定する層にある。コンテキストエンジニアリングを中心に据えた記事の解読。

出発点

すべてのシニア開発者が経験した具体的な事例：IDEを開き、アシスタントに「この関数を新しい内部APIを使用してリファクタリングして」と依頼すると、文法的にきれいなコードを生成しますが、プロジェクトの3つの規約、2つの内部依存関係、そして30行先に既に存在するヘルパーを無視しています。モデルは「愚か」ではない、単に必要なものを見ていないだけです。

Vinay Perneti (Augment Code)がArs Technicaのインタビュー「Beyond grep : The case for a context-rich AI coding harness」で主張するのと同じです：ハーネス - プロンプトにコンテキストを選択、順序付け、注入するメカニズムのセット - は、現在、基盤となるモデルの選択よりも重要です。

「貧しい」ハーネスが行うこと

これは主に高度なgrepです：

• リポジトリのファイルに対するナイーブな埋め込み検索、
• カーソル周辺に開かれたコンテキストウィンドウ、
• 場合によっては現在のファイル全体。

これはローカルタスク（変数の名前変更、シグネチャの修正）に役立ちます。しかし、3つのモジュール先でテストが失敗する理由を理解する必要があると、すぐに崩壊します。

「豊かな」ハーネスが行うこと

Augment CodeのVinay Pernetiが主張する3つのブロックを組み合わせたものです：

1. コードの依存関係グラフ - インポート、呼び出し、継承：ハーネスは、テキスト的に近いファイルではなく、本当に役立つ定義を取得するためにエッジをたどります。
2. 実行履歴 - テストのトレース、ログ、最後のpytestまたはcargo testの出力。モデルは、壊れたコードだけでなく、壊れたものを見ます。
3. セッションメモリ - 前のやり取りで取られた決定（「ライブラリXを選択し、Yではなく」）を保持し、アシスタントが毎回それを再検討するのを防ぎます。

最近のオープンソースプロジェクトがそれぞれのブロックを示しています - 構造解析のためのtree-sitterエコシステム、セマンティックインデックスと組み合わせたripgrep周辺のツール、および「スクラッチパッド」を保持するエージェントフレームワーク。

なぜこれが核心なのか

2つの経済的な理由：

• トークンの価格が下がるので、コンテキストウィンドウが増加します：より多くを送信できるようになります。しかし、すべてを送信することはできません - 50万行のモノレポはまだ手の届かない場所にあります。したがって、選択する必要があります。
• モデルは、適切なタイミングで示されたものについてより良く推論します - ごみのように投げ込まれたものよりも。適切に優先順位を付けるハーネスは、自分のウィンドウ内で悪く分類するモデルを上回ります。

言い換えれば：許容できるアシスタントと依存できるアシスタントの違いは、モデルの重量ではなく、その知覚環境のソフトウェアエンジニアリングにあります。

覚えておくべきこと

• 「ハーネス」（コンテキストエンジニアリング）は、Augment CodeのVinay Pernetiが公に主張するように、コードアシスタントの真の差別化要因になっています。
• 豊かなハーネスは、コードグラフ、実行履歴、セッションメモリを組み合わせたものであり、単なるテキスト検索ではありません。
• 今日のツールを選ぶことは、そのハーネスと搭載されているモデルを評価することと同じです。