カーソルのエンジニア、月2,000件のPR検証フローを公開

カーソルのエンジニア、ローレン・タン(Lauren Tan)は2026年9月22日、Xに投稿した動画で、先月の1カ月間にPR（コード変更の取り込みを求める申請）を2,000件本番環境に反映したと話しました。Xの投稿タイトルには2,500件とありますが、動画の冒頭画面と発言は2,000件で食い違っています。38分の動画は1カ月で再生数が400万回を超え、タンはエージェントが自分のPRを直接マージするため、人によるレビューはないと答えました。ただし、PRの平均変更量、取り消し率、障害件数、費用は明らかにされておらず、すべてのPRに人がまったく関与していないかも確認できません。

タンが公開したpstackリポジトリは、文書ガイドやスキル、状況別のプレイブックで作業の流れを整理しています。筆者は動画とリポジトリを確認し、自身のエージェント・アカデミーのリポジトリにも同様の仕組みを導入しました。狙いはレビューをなくすことではなく、レビューが担ってきた役割をPR前の検証、作成者とは別の判定エージェント、コード構造、自動チェックに移すことです。

タンは、エージェントを増やす前に、結果を信頼できる検証手段を整える必要があると話しました。結果を信頼できなければ人が再確認しなければならず、監督が必要な状態でエージェントだけを増やせば、質の低いPRや回帰（修正後に以前の機能が損なわれること）も増えるという説明です。性能問題を追っていた時期を振り返り、「ボトルネックは自分自身だ」と述べました。スタイルガイドだけでは、規則を覚えてレビューで指摘する作業が人に残ります。同じ指摘を繰り返すのではなく、コードや自動チェックに反映すべきだとタンは説明しました。

タンが示した修正内容の適用先は、コードベース、リンター・コンパイラー・CIなどの静的解析（実行せずにコードの問題を調べる方法）、規則とバグボット、スキル、スタイルガイドの5段階です。下の段階ほど強制力が弱く、スタイルガイドは人がレビューで指摘しなければ守られません。pstackの検証ガイドは、作業開始前に完了条件を決め、アプリごとの検証スキルを作るよう案内しています。スキルには、アプリの起動、状態確認、ユーザーのような操作、証拠の記録と後片付けの手順を含めます。動画では、機能マップが機能の場所と使い方を示し、CLI（コマンドラインからアプリを操作するツール）によってエージェントがアプリを起動・操作します。PRを開く前に、動作を示す証拠を用意する流れです。

デプロイ用プレイブックでは、コードを書いていない検証エージェントを各PRに割り当て、変更をユーザーのように操作させて、PASS・PASS+NOTES・FAILのいずれかを記録します。作成者のエージェントは自分が意図した内容を確認するだけだとして、その判定を認めません。CIが緑色であることや、承認済みのボットレビューも、ユーザーが実際に試した結果ではないため、判定とは見なしません。マージは最も下のPRから進め、未検証のPRがあれば、その上のPRは待機します。リベース（変更を新しい基点に適用し直すこと）でコミットが変わった場合はgit patch-idを比較し、以前の判定が新しいコードにも有効かを確かめます。

pstackのinterrogateスキルは、同じ変更内容、意図、評価基準を異なる系列のモデルに送り、レビューを受けます。2つのモデルが独立して同じ問題を指摘すれば、信頼できる兆候と見なし、指摘をすぐ修正する、確認する、記録だけする、退ける、のいずれかに分類します。退ける理由を記録し、指摘を自動で反映することはありません。バグボットのコメントも、修正、却下、人に相談、に分けます。セキュリティ、個人情報、データに関する指摘や、内容が曖昧な指摘は人に相談する設定です。細かなコード品質の指摘を見送る損失より、実際のデータ・セキュリティ上のバグを見逃す損失のほうが大きいという理由です。

タンによると、コードベースではエージェントが周囲のコメントを根拠に問題を直さず、場当たり的な対処を正当化することが繰り返されました。回避用のコードが複数のエージェントにコピーされると、数日で事実上の標準になり得ると説明しています。タンはGrokボットのコードベースでエージェント用フレームワーク「Dune」を作り、コメントを禁止しました。また、誤ったインポート、定められた契約を通さないRPCの直接呼び出し、ファイルサイズの増加を、レビュー前のリンターとビルドで検出するようにしました。コメント禁止は同チームの選択として示されています。

pstackのcorrectスキルは、最近のコミット、取り消されたコミット、レビューコメントを読み、2回以上繰り返されたミスをまとめ、可能な限り上位の段階で防ぐ仕組みです。まずコード構造でミスを起こせなくし、次に型・リンター・CI、テストの順にチェックし、文書化は最後に行います。新しいチェックは、過去に実際に起きたミスを検出できるか確かめます。同じコメントを繰り返す代わりに規則へ移し、悪いパターンを早期に見つける「庭師」の役割が必要だとタンは話しました。

最終的な責任は人に残ります。タンは最終結果への責任は人にあるとし、pstackはセキュリティやデータのように取り消しにくい判断を人に尋ねます。リンターの例外には理由と期限、人の承認を記録します。show-me-your-workスキルは、エージェントの判断根拠を表に残し、人や別のモデルが後から確認できるようにします。人はすべてのコードを読むのではなく、検証基準を定め、繰り返すミスを仕組みで防ぎ、最終結果に責任を持つ役割を担います。

筆者のリポジトリでは、コミットフックがメッセージ形式と判断記録の番号を確認し、プッシュ直前の別のフックがテストとビルドを実行して、mainブランチへの直接プッシュを拒否します。PRが開かれるとクラウドビルドがプレビューを作り、別サーバーのエージェントが読み取り専用で変更を調べ、本来の目的と関係ない変更があればコメントで知らせます。ビルドが失敗すると別のエージェントが原因を修正し、PRブランチに再度プッシュします。マージは筆者自身が行います。

ハッカソン課題の評価機能を直すPRでは、ビルドとテストは通りましたが、変更確認エージェントが、遅刻提出の判定だけを記した判断記録と異なり、順位の並べ替えコードも変更されていると指摘しました。筆者が調べると、コードを書いたエージェントが周辺コードを整理する際に順位変更も加えていました。筆者はその変更を別のPRに分けて再確認し、同様のことがもう一度起きた後、判断記録と変更内容の一致を調べる規則の一部をスクリプトに移しました。夜間に壊れたビルドが朝には修正コミットを受けている日が増え、レビューは判断記録とエージェントのコメントを確認してマージを決める作業に変わりました。

筆者は、一人で運営する小規模リポジトリでは、変更確認エージェントは警告を出すだけでマージを止めず、問題のない変更にも警告して再確認が必要になる場合があると明らかにしました。タンはGrokボットのコードベースに多くの時間をかけ、検証スキル、機能マップ、リンター規則、フレームワークを整えた後、エージェントにより大きな裁量を与えました。カーソル社内ではクラウドエージェント、オートメーション、バグボットを自由に使えますが、費用、障害率、取り消したPRの割合、セキュリティレビューや権限分離の方法は公表されていません。そのため、PRの件数だけから生産性が何倍に増えたかを計算することはできないと筆者は指摘しています。

カーソルのエンジニア、ローレン・タン(Lauren Tan)は2026年9月22日、Xに投稿した動画で、先月の1カ月間にPR（コード変更の取り込みを求める申請）を2,000件本番環境に反映したと話しました。Xの投稿タイトルには2,500件とありますが、動画の冒頭画面と発言は2,000件で食い違っています。38分の動画は1カ月で再生数が400万回を超え、タンはエージェントが自分のPRを直接マージするため、人によるレビューはないと答えました。ただし、PRの平均変更量、取り消し率、障害件数、費用は明らかにされておらず、すべてのPRに人がまったく関与していないかも確認できません。

タンが公開したpstackリポジトリは、文書ガイドやスキル、状況別のプレイブックで作業の流れを整理しています。筆者は動画とリポジトリを確認し、自身のエージェント・アカデミーのリポジトリにも同様の仕組みを導入しました。狙いはレビューをなくすことではなく、レビューが担ってきた役割をPR前の検証、作成者とは別の判定エージェント、コード構造、自動チェックに移すことです。

タンは、エージェントを増やす前に、結果を信頼できる検証手段を整える必要があると話しました。結果を信頼できなければ人が再確認しなければならず、監督が必要な状態でエージェントだけを増やせば、質の低いPRや回帰（修正後に以前の機能が損なわれること）も増えるという説明です。性能問題を追っていた時期を振り返り、「ボトルネックは自分自身だ」と述べました。スタイルガイドだけでは、規則を覚えてレビューで指摘する作業が人に残ります。同じ指摘を繰り返すのではなく、コードや自動チェックに反映すべきだとタンは説明しました。

タンが示した修正内容の適用先は、コードベース、リンター・コンパイラー・CIなどの静的解析（実行せずにコードの問題を調べる方法）、規則とバグボット、スキル、スタイルガイドの5段階です。下の段階ほど強制力が弱く、スタイルガイドは人がレビューで指摘しなければ守られません。pstackの検証ガイドは、作業開始前に完了条件を決め、アプリごとの検証スキルを作るよう案内しています。スキルには、アプリの起動、状態確認、ユーザーのような操作、証拠の記録と後片付けの手順を含めます。動画では、機能マップが機能の場所と使い方を示し、CLI（コマンドラインからアプリを操作するツール）によってエージェントがアプリを起動・操作します。PRを開く前に、動作を示す証拠を用意する流れです。

デプロイ用プレイブックでは、コードを書いていない検証エージェントを各PRに割り当て、変更をユーザーのように操作させて、PASS・PASS+NOTES・FAILのいずれかを記録します。作成者のエージェントは自分が意図した内容を確認するだけだとして、その判定を認めません。CIが緑色であることや、承認済みのボットレビューも、ユーザーが実際に試した結果ではないため、判定とは見なしません。マージは最も下のPRから進め、未検証のPRがあれば、その上のPRは待機します。リベース（変更を新しい基点に適用し直すこと）でコミットが変わった場合はgit patch-idを比較し、以前の判定が新しいコードにも有効かを確かめます。

pstackのinterrogateスキルは、同じ変更内容、意図、評価基準を異なる系列のモデルに送り、レビューを受けます。2つのモデルが独立して同じ問題を指摘すれば、信頼できる兆候と見なし、指摘をすぐ修正する、確認する、記録だけする、退ける、のいずれかに分類します。退ける理由を記録し、指摘を自動で反映することはありません。バグボットのコメントも、修正、却下、人に相談、に分けます。セキュリティ、個人情報、データに関する指摘や、内容が曖昧な指摘は人に相談する設定です。細かなコード品質の指摘を見送る損失より、実際のデータ・セキュリティ上のバグを見逃す損失のほうが大きいという理由です。

タンによると、コードベースではエージェントが周囲のコメントを根拠に問題を直さず、場当たり的な対処を正当化することが繰り返されました。回避用のコードが複数のエージェントにコピーされると、数日で事実上の標準になり得ると説明しています。タンはGrokボットのコードベースでエージェント用フレームワーク「Dune」を作り、コメントを禁止しました。また、誤ったインポート、定められた契約を通さないRPCの直接呼び出し、ファイルサイズの増加を、レビュー前のリンターとビルドで検出するようにしました。コメント禁止は同チームの選択として示されています。

pstackのcorrectスキルは、最近のコミット、取り消されたコミット、レビューコメントを読み、2回以上繰り返されたミスをまとめ、可能な限り上位の段階で防ぐ仕組みです。まずコード構造でミスを起こせなくし、次に型・リンター・CI、テストの順にチェックし、文書化は最後に行います。新しいチェックは、過去に実際に起きたミスを検出できるか確かめます。同じコメントを繰り返す代わりに規則へ移し、悪いパターンを早期に見つける「庭師」の役割が必要だとタンは話しました。

最終的な責任は人に残ります。タンは最終結果への責任は人にあるとし、pstackはセキュリティやデータのように取り消しにくい判断を人に尋ねます。リンターの例外には理由と期限、人の承認を記録します。show-me-your-workスキルは、エージェントの判断根拠を表に残し、人や別のモデルが後から確認できるようにします。人はすべてのコードを読むのではなく、検証基準を定め、繰り返すミスを仕組みで防ぎ、最終結果に責任を持つ役割を担います。

筆者のリポジトリでは、コミットフックがメッセージ形式と判断記録の番号を確認し、プッシュ直前の別のフックがテストとビルドを実行して、mainブランチへの直接プッシュを拒否します。PRが開かれるとクラウドビルドがプレビューを作り、別サーバーのエージェントが読み取り専用で変更を調べ、本来の目的と関係ない変更があればコメントで知らせます。ビルドが失敗すると別のエージェントが原因を修正し、PRブランチに再度プッシュします。マージは筆者自身が行います。

ハッカソン課題の評価機能を直すPRでは、ビルドとテストは通りましたが、変更確認エージェントが、遅刻提出の判定だけを記した判断記録と異なり、順位の並べ替えコードも変更されていると指摘しました。筆者が調べると、コードを書いたエージェントが周辺コードを整理する際に順位変更も加えていました。筆者はその変更を別のPRに分けて再確認し、同様のことがもう一度起きた後、判断記録と変更内容の一致を調べる規則の一部をスクリプトに移しました。夜間に壊れたビルドが朝には修正コミットを受けている日が増え、レビューは判断記録とエージェントのコメントを確認してマージを決める作業に変わりました。

筆者は、一人で運営する小規模リポジトリでは、変更確認エージェントは警告を出すだけでマージを止めず、問題のない変更にも警告して再確認が必要になる場合があると明らかにしました。タンはGrokボットのコードベースに多くの時間をかけ、検証スキル、機能マップ、リンター規則、フレームワークを整えた後、エージェントにより大きな裁量を与えました。カーソル社内ではクラウドエージェント、オートメーション、バグボットを自由に使えますが、費用、障害率、取り消したPRの割合、セキュリティレビューや権限分離の方法は公表されていません。そのため、PRの件数だけから生産性が何倍に増えたかを計算することはできないと筆者は指摘しています。