Graft - Context layer for coding agents
Show HN: Graft – Claude Code hooks that cut grep tokens by 42%
Graftは、Claude Code、Cursor、Codex、Geminiなどのコーディングエージェント向けのオープンソースのコンテキストレイヤーです。コードベースの構造を解析し、リンクされたマークダウンファイルのグラフとして理解を構築します。これにより、エージェントは毎回ゼロからコードを探索する代わりに、事前に構築されたマップを利用できます。ベンチマークでは、トークン使用量を最大42%削減し、処理速度を最大3倍高速化し、SWE-bench Verifiedでの正解率を54%から66%に向上させました。セットアップは簡単で、`npm install -g @nanonets/graft`と`graft init`を実行するだけです。
エージェントは毎回ゼロからコードベースを探索するのではなく、一度理解を構築すれば、それを共有して再利用できます。
HNでの議論
44- seizethecheese
これはクールに見えるし、メカニズムももっともらしい。ただ、ここでの主張が正当かどうかを理解しようとする体験が、いらだたしいものだと感じた。
まず、ベンチマークに関するREADMEのセクション全体が、Claude/Codexが書いたように見える。読むのが本当にうんざりする。
次に、SWE-Bench Verifiedでの成功を主張しているが、それは50タスクだけであり、タスクがどのように選ばれたかは明確にされていない。経験上、結果が出るまでタスクのセットを選び続けることができるのは知っている。また、これは1回だけ実行され、示されている改善のp値は実際には0.22しかない。
「統計で嘘をつく方法」という有名な本がある。ここでのベンチマーク結果に関する継続的な投稿が意図的な嘘だとは思わないが、自分自身を欺くのはとても簡単だと思う（そして私自身も、最近http://pellmell.ai を構築する際に痛い目にあった）。また、この投稿が最もひどい例だとも思わない。
- anotherhue
Claudeがこんなに特徴的で良かった。空疎な言葉の羅列をすぐに避けられるから。
もしかしたらこれは素晴らしいものかもしれないが、このプレゼンテーションでは判断できない。
- icodestuff
アイデアは気に入った。数週間前にこの問題について考えていたが、どこにも到達できなかった。特にレイテンシの削減に興味を引かれた。それは素晴らしいと思う。
一つ懸念があるのは、今のところ各セッションが問題に対して新しい「目」を持っていることだ。現在、私は長期実行セッションと新しいセッションの組み合わせから多くの利益を得ている。単一の生成されたコンセプトグラフが増分更新のみを受ける場合、ゆっくりと、そして検出が難しい微妙な方法で古くなるのではないかと心配している。それはグラフの現実からの意味的ドリフトにつながり、新しいセッションはすべてドリフトした形式を正として受け取るだろう。これが起こらないことを確認するために、長期間（数週間以上）のテストを実行したか？ SWE Benchは一時点の評価に過ぎないと理解している。
また、グラフはリポジトリに保存されるのだろう？ マージ可能性はどうか？ 私は自分でコンフリクト解決をしたくないし、Opusでさえ、B->C、A->Bのシンボルリネームがある場合（特にコメントが関わるとき）、すべての参照を正しく保つのに苦労する。
- peter_d_sherman
>「問題：
すべてのタスクで、コーディングエージェントは盲目的に始まる。何かを変更する前に、リポジトリを再探索する：用語をgrepし、ファイルを開き、インポートを辿り、戻り、再試行する。1時間前にマッピングして捨てたコードベースの絵を再構築している。
その再発見が、実行のツールコール、トークン、レイテンシのほとんどを消費し、それは純粋なオーバーヘッドである」
この記事の著者は非常に興味深い問題を提起している——LLMをコーダー/コーディングアシスタントとして使う限り、いずれコンテキストが尽き、基礎となるコードベースに関連するコンテキストも尽きるということだ。これはトークンを消費し、ひいてはエネルギー資源を浪費する。
歴史的に（いや、ここ数年で！）、この問題に対処するための多くの解決策が提案されてきた（コードの抽象/サブセット/マップを取り、それらを異なるデータベースや永続ストレージ方法に書き込み、LLMが必要とするときに戻す、などなど）...
しかし、この問題に対する本当に良い解決策はない（Graftが過去のツールよりはるかに進んでおり、その点は称賛に値するが！）。なぜなら、この問題はいくつかの問題領域にまたがって、別々の部分にあるように思えるからだ：
1) LLMのコンテキストウィンドウサイズ——限られている。将来のLLMがコンテキストウィンドウを大きくするために行うことは、この問題を改善するのに役立つだろう。
2) テキスト以外でコードベースをLLMに表現する良い方法の欠如。
言い換えれば、まずコードベースをテキストではなくテンソルにマッピングする何らかの方法が必要だ（つまり、より高レベルの「マップ」...
- xhrpost
直感的に、そしておそらく素朴に、ClaudeがLSPサーバーを使うことでgrepの使用の多くを不要にすると思っていた。このツールは同じ問題を解決しているのか、それとも別の何かか？