マップが先、レビューは後

プルリクエストの両側には、二つの異なる仕事があります。エージェントが書く前には、これから変更しようとしているツリーのマップが必要です。エージェントがPRを開いた後は、何かがその変更をシステムの残りの部分と照らし合わせて読み、人間が行動に移せるコメントを残す必要があります。

これらの仕事は、どちらも「コードベースを理解すること」を含むため、遠くから見ると似ています。同じ製品ではありません。一方は「この変更はどこに着地すべきか」に答えます。もう一方は「行単位のリンターが見逃す、このdiffが何を壊したか」に答えます。この二つを混同すると、より悪い最初の草稿と、より騒がしいレビューが生まれます。

この記事は、共同ワークフローのガイドです。Maguyvaは、エージェントが最初に問い合わせるマップです。Greptileは、その後でPRにコメントするレビューエージェントです。このペアは構造的に補完的です。Maguyvaはプルリクエストをレビューしませんし、Greptileはエージェントがそれらを書くのに使ったコンテキストレイヤーを置き換えません。

この分業が役立つ理由

訓練事前知識といくつかの貼り付けられたファイルから出発するコーディングエージェントは、もっともらしいパスを捏造して編集します。それが間違ったファイルの失敗であり、検索の問題です。Maguyvaはリモートのmcpコードベース・コンテキストレイヤーです。セマンティック、構造(AST)、グラフ/依存関係、テキストの検索がランク付けされた結果に融合され、加えてシンボル検索とファイル取得もあります。根拠のある答えはpath/file.ext:lineとして返ってくるため、パッチが存在する前に見当違いを拒否できます。主張は控えめなままです。幻覚編集が減ること。モデルはそれでも推測できます。ただ最初のステップが、もう推測ではなくなるだけです。

GreptileはAIコードレビューエージェントです。彼ら自身の言葉によれば、コードベースの完全な理解をもって、すべてのプルリクエストを自動的にレビューし、それをシステム全体ではなくファイルを個別に確認する従来のリンターと対比させています。セットアップは、GitHubまたはGitLabアプリをインストールし、リポジトリを選択することです。あなたが運用すべきローカルインデックスはありません。ホスティングはGreptile Cloudで(要求に応じて提供されるレポートとともにSOC 2 Type II準拠を表明しています)、企業向けにセルフホストのオプションも提供しています。

彼ら自身の番号付きフローはこうです。接続し、すべての関数、クラス、依存関係の依存関係グラフを構築する。すべてのプルリクエストで、そのリポジトリ全体のグラフを使って変更を分析し、約三分で修正案付きのPRコメントとして結果を投稿する。各コメントは、チームがすでに使っているコーディングエージェントに問題を引き渡せる。彼らはまた、チームのコーディング標準を学び、騒がしい提案を減らすために、過去の人間によるPRコメントを時間をかけて読むとも述べています。彼らの学習システムは、適応するのに2〜3週間必要だと述べられています。

これはレビューであって、起草ではありません。Greptileの際立った点は、すでにPRに着地した変更に対する、リポジトリ全体のグラフコンテキストであり、その後、発見をClaude Code、Codex、Conductor、Cursor、あるいはDevinに送る閉じたループです。Maguyvaの際立った点は、その変更が書かれる前にエージェントが問い合わせた、ランク付けされたマップです。両方使ってください。どちらにも相手の仕事をさせないでください。

Maguyva–Greptile間のファーストパーティ製品統合は明言されていません。それも必要ありません。MaguyvaはMCPを通じてエージェントと話します。Greptileは自分たちのアプリを通じてGitHubやGitLabと話します。両者はプルリクエストで出会います。糊付けスクリプトも、一方を他方につなぐcronもありません。それぞれの製品がすでに自分の持ち場に立っているため、このペアはbash不要です。

これが何ではないか

これはGreptileを貶める記事ではありません。「レビュアーを乗り換えろ」という記事でもありません。Greptileは2024年3月5日、Y Combinator W24の企業としてHacker Newsでローンチし、そのスレッドは多くの人がこの製品に初めて出会った方法です。もしそれがあなたの出会い方なら、そのまま使い続けてください。このページは、そのループの欠けている前半部分です。Greptileが見るPRが、すでに正しいファイルを狙っているように、先にエージェントに根拠を持たせることです。

Greptileのマーケティング資料は、レビュー速度とバグ検出の主張を前面に出しています。それらを、独立して検証された数値ではなく、Greptile自身の主張として扱ってください。本稿はそれらを事実として繰り返しません。

言語カバレッジも同じ種類の誠実さです。Greptileは、列挙されたリストではなく、すべてのプログラミング言語をカバーするという枠組みでサポートを表現しており、正確な数は明記されていません。Maguyvaは279以上の言語とテキストベースの技術を公開しており、質問が技術的なものであるときは、サイト上で技術的な区分(パーサー支援のASTかテキストのみか)も公開しています。これらは異なる主張をする異なる製品です。混同しないでください。

Greptileの価格は、本稿が使える資料には明記されていません。有料プランは存在します。彼らの価格ページを参照してください。Maguyvaは席数ではなくワークスペース単位で課金します。プランは無料から始まります。ワークスペースの数値が必要なら、価格ページに公開された階層が載っています。

ワークフロー

名前の付いた三つの段階です。この順序で実行してください。このペアを初めて試すときは、どれも飛ばさないでください。

1. Maguyvaのコンテキスト

すでに知っているリポジトリを一つインデックスしてください。すでにコードを書いているMCPクライアントを接続してください──Claude Code、Cursor、Codex CLI、VS Code、Windsurf、あるいは他のMCP互換クライアント。Maguyvaには24の文書化されたMCPクライアント向けのセットアップガイドがあり、標準MCP設定をサポートする他のクライアントにも接続できます。

誰かが一行でも書く前に、評価できる質問をしてください。「セッションの有効期限はどこで処理されていて、何がそれを呼び出しているか?」は「認証を直して」よりも良い最初の一手です。引用を要求してください。file.ext:lineの結果を開いてください。シンボルをたどってください。今から触れようとしている依存関係を確認してください。

Maguyvaは、検索、シンボル、依存関係分析、ファイル取得、リポジトリコンテキスト、決定論的なユーティリティワークフローにまたがる11の顧客向けMCPツールを提供します。四つの検索モードがランク付けされた結果に融合されます。すでに名前を知っている場合、find_symbolは別のツールです。ドキュメントは最短経路を説明しています。無料で始め、すでに知っているリポジトリをインデックスし、クライアントを接続し、それから確認できる質問を尋ねる。

スナップショットにはタイムスタンプが付いているため、エージェントはどのバージョンのツリーを読んでいるかを判別できます。正直な限界は、同期されていないローカルの作業です。編集が作業ツリーにしか存在せず、プッシュされていない場合、ホスト型マップはまだそれを含んでいません。指示ファイル(CLAUDE.md、AGENTS.md)は、慣習と触れてはいけないもののために、依然としてここに居場所があります。それらは生きたマップではありません。振る舞いにはそれらを使い、事実にはMaguyvaを使ってください。

引用がリポジトリとの接触を生き延びる前に、エージェントにPRを開かせないでください。この関門こそが、この段階の意義のすべてです。

2. エージェントのPR

同じエージェントが今度は、あなたがすでに料金を払っているクライアントの中で変更を書きます。Maguyvaはエディタでもレビュアーでもありません。エージェントは依然としてdiffを生成します。あなたは依然として、すでにやっているようにGitHubやGitLabでプルリクエストを開きます。

違うべきなのは最初のファイルです。PRは、その振る舞いを実際に実装しているハンドラー、壊れることになる呼び出し元、そして変更が間違っていれば失敗するテストを名指しすべきです。第1段階が飛ばされていれば、第3段階は間違ったパッケージに着地した変更に、そのコメントを費やすことになります。Greptileはそれでも体系的な問題を見つけられます。それに加えて、幻覚のパスからも回復しなければならない必要はないはずです。

PRの範囲を絞ってください。根拠のある最初のファイルは、モジュールを書き直すライセンスではありません。この補完的なペアが機能するのは、エージェントがマップを使って一つの仕事をし、その後レビュアーに、範囲を限定したdiffで別の仕事をするよう頼んだときです。

3. Greptileのレビュー

GreptileはすでにGitHubまたはGitLabアプリを通じてリポジトリに接続されています。新しいプルリクエストでは、自ら構築したリポジトリ全体のグラフを使って変更を分析し、修正案付きのコメントとして結果を投稿します。彼ら自身の資料は、この処理を約三分としています。

コメントは、注意深いチームメイトを読むように読んでください。引用された場所を開き、その発見が本物かどうかを判断し、それから行動する。Greptileが「Fix with your Agent」を提供する場所では、ファイルパス、行番号、提案されたコードを含む問題を、Claude Code、Codex、Conductor、Cursor、あるいはDevinに送ります。「Fix All」はレビュー内のすべての問題を一度に送ります。彼らはまた、その引き渡しのためにGreptile MCPとClaude Codeプラグインも提供しています。Maguyvaはその名指しされた対象リストには入っていません。その不在は問題ではありません。Maguyvaはすでに第1段階で自分の仕事を終えています。PRを書いたコーディングエージェントこそが、修正ペイロードを受け取るべき対象です。

Greptileの学習システムがあなたのチームが実際に残すコメントに適応する最初の2〜3週間は、ノイズを覚悟してください。それは彼らが表明したスケジュールであって、このペアの欠陥ではありません。人間によるレビューはループの中に残ります。Greptileは自動化された最初のパスであり、マージボタンではありません。

Greptileのコメントが、エージェントが第1段階で一度も問い合わせなかったファイルを指している場合、それは有用なシグナルです。マップが呼び出し元を見逃したか、エージェントが引用を飛ばしたかのどちらかです。そのコメントに合わせて草稿を直してください。レビュアーを無効化しないでください。

この補完関係を誠実に保つ方法

• Maguyvaが常に先。間違ったファイルのPRをレビューしても、それは依然として間違ったファイルのレビューです。
• Greptileが常に後。よく引用された草稿でも、システム全体レベルでのdiffの通読は依然として必要です。
• MaguyvaにPRコメントを投稿するよう求めないでください。それはしません。
• エージェントがまだパスを選んでいる最中に、Greptileにその最初の検索レイヤーになるよう求めないでください。それは、彼らのGitHubやGitLabアプリが担うよう作られている仕事ではありません。
• 両者を「同期」するbashパイプラインを捏造しないでください。PRがインターフェースです。
• 両側を独立して検証してください。すでに知っているリポジトリをインデックスしてください。確認できる質問を尋ねてください。それから小さなPRを開き、Greptileが実際に何をコメントするかを読んでください。

名前を付けてしまえば、このループはありふれたものです。マップが先。エージェントのPR。レビューが後。それぞれの製品は、自分が得意なプルリクエストの側に留まります。

// map first. review second. in that order.