ちょっと胸の内を話させてください。@cursor_ai の面接を受ける前、実は一度も Cursor を使ったことがなかったんです。
Meta では、Claude Code が爆発的に広がっていました。サイドプロジェクトのために、個人で月額 200 ドルのプランにも課金していました。そのシンプルさと、すぐに生産性を実感できる点が気に入っていました。ただ、自分にとっての課題は、cc をほぼ思い通りに操れる独自のスキルセットを開発することでした。その上に、独自のエージェントオーケストレーターツールまで作り始めていました。
オンサイト面接では、2 日間かけて Cursor を使い、面接用のプロジェクトを構築しました。Cursor 3 のリリース前だったので、エディターウィンドウを使っていました。長年 vscode を使ってきたので、ほとんどのキーボードショートカットはまだ頭に入っており、IDE に戻るのはそれほど難しくありませんでした。でも、正直に言うと、最初の 1、2 時間は CLI が恋しくなりました。何かをクリックするのは、ほとんど野蛮に感じられました。しかし、いくつか本当に印象的な点がありました。
まず、当時使っていたモデル（Opus と Codex）が、なぜか賢く感じられました。そして、モデルをその場で切り替えたり、プロジェクトの異なる部分で両方を同時に使える（フロントエンドに Opus、システムに Codex）のが素晴らしかったです。面接前から、私はマルチモデルによる adversarial review について熱く語っていたので、これを UI 上でネイティブに実行できるのは非常に自然に感じられました。さらに良かったのは、異なるモデルのサブエージェントを生成でき、1 つの会話の中で両方の長所を活かせたことです。
次に、コンパクションが信じられないほど速かったことです。cc ユーザーとして、コンパクションに何分もかかるのが当たり前で、常にコンテキストとプランの使用量を監視していました。そのため、Cursor での速さには本当に驚きました。あまりに速いので、コンテキストの使用量を気にする必要がほとんどありませんでした。ただ、cc でコンパクションした後は、モデルが極端にバカになったように感じることがよくありました。
そして 3 つ目に気づいたのは、GUI が TUI よりも提供できるものが多いということです。Cursor のブラウザでアプリを直接開き、Design Mode でデザイン変更できるのは直感的で、専用 UI がエージェントによるコーディングをいかに効果的にできるかについて考えさせられました。
Cursor を Cursor で作る
3 月末に入社して以来、主に Cursor 3 の Agent Window に取り組み、それを日常的に使っています。今でも cc は優れたチームが作ったクールな製品だと思っていますが、そのシンプルさゆえに、人々はそれをラップする独自の抽象化レイヤーを作りたがる傾向があることに気づきました。前職では、cc 上に構築された新しい内部オーケストレーターツールが毎週発表されているように感じました。
@bcherny は、この「潜在的需要」というアイデアについてよく語っています：
「製品には『潜在的需要』という非常に古い概念があります…製品をハッキング可能で、人々が他のユースケースに悪用できるほどオープンエンドな方法で作るのです。そして、人々がどのように悪用するかを観察し、それに合わせて製品を作るのです。」
まさにこれでした！人々がオーケストレーションツールに集まるのは、CLI を使うと人間自身がオーケストレーターになるという潜在的需要を露呈しているのです。
しかし、私が使ってきたエージェントワークフローはすべて、間違ったことに焦点を当てていました。GUI で複数の CLI を実行するのは、本質を見失っていました。私が興味を持っていたアプローチは、エージェントへの信頼を構築することでした。
元エンジニアリングマネージャーとして、エージェントの管理は人間のエンジニアチームを構築するのと似ているとすぐに気づきました。新入社員は、コードベースを理解するためにオンボーディングが必要ですが、同時に仕事の進め方も学ぶ必要があります。彼らは過去の経験から得たスキル（デバッグ方法、高品質なコードとテストの書き方、コミュニケーションの仕方など）をすでに持って入社してきます。
エージェントは、常に記憶喪失と愚かさの状態にある新入社員のようなものです。あなたが言ったことを覚えておらず、新しいことを本当に学ぶこともありません。しかし、ルール、スキル、ツール、長期記憶を装備することで、それを近似できます。彼らは有能でありながら愚かで、とても教えやすい存在です。そして、彼らの失敗モードを、深く厳密なエンジニアリングについて私が知っているすべてを教える機会と捉えました。
なぜなら、厳密さがなければ、エージェントはあなたが依頼したコードを書くためなら、お世辞にも何でもやろうとするからです。そして、それは大量のコードを書くことができます。単純な並列化は、彼らが粗悪なコードをより速く書くだけです。
速く進みたければ、まず深く進め
エージェントオーケストレーションは生産的に行えると私は考えています。しかし、まず深さを追求する必要があります。
私は pstack をオープンソース化します。これは、@cursor_ai を構築するために毎日使っている、私個人のスキルとエンジニアリング原則のセットです。これらのスキルの初期の反復をサイドプロジェクトで開発し始め、それ以来ずっと洗練させてきました。
こちらから入手してください：https://cursor.com/marketplace/cursor/pstack
これらのスキルは Cursor チームで最も使われるスキルの一部になったので、皆さんと共有できることを嬉しく思います。
pstack は、複数のモデルを使用してエージェントをより厳密にすることを教えます。私が観察したすべての失敗モードをスキルに変換しました。プラグインの核心は /poteto-mode で、これは与えられたタスクに対してエージェントが従うべき正しいプレイブックを提供する高次のスキルです。目標は最大の LOC ではなく、その逆、つまり最小のコードで最大のインパクトを生み出すことです。
厳密さは、経験豊富なエンジニアと同じ方法で問題にアプローチすることで適用されます。例えば、デバッグに優れた方法は、問題空間を二分探索することです。何が起こっているかについての仮説をいくつか立て、それらを体系的に排除していき、真の根本原因に近づきます。再現が難しい場合は、バグを合成的に強制的に発生させてみるかもしれません。または、プログラムの実行中の状態を確認するために、インストルメンテーションやコンソールログを追加してみるかもしれません。
これらのステップは、エージェントが推測する代わりに（放っておくと喜んで推測します）、徹底的にデバッグするために使用できるプレイブックを形成します。pstack には、同じレベルの厳密さでソフトウェアエンジニアリングに取り組むための多くのスキルとプレイブックが含まれています。現在、以下のプレイブックがあります：
- スキル作成と評価
- 自律的な作業
- バグ修正とランタイムフォレンジック
- 機能開発
- ビジュアルパリティとプロトタイピング
- その他
厳密さが必要なときはいつでも、プロンプトの前に /poteto-mode を付けてください。例：
必要に応じて、他のスキルをオンデマンドで呼び出すこともできます：
- /how：サブシステムが実際にどのように動作するかのウォークスルーが欲しいとき。
- /why：なぜ何かがこのように構築されたのかを知りたいとき。利用可能な MCP を使用して、各証拠カテゴリ（ソース管理、課題トラッカー、長文ドキュメント、リアルタイムチャット、インフラ監視、エラー追跡、分析ウェアハウス）を並行して照会します。
- /architect：関数の境界を越えるコードを書こうとしていて、最初に型とデータ構造を確定させたいとき。
- /arena：同じことに対して N 回の並行試行を行い、それぞれの最良の部分を取得したいとき。
- /interrogate：異なるモデルに何かを adversarially review させたいとき。
- /tdd：バグを修正しているとき。最初に失敗するテストを書き、次に修正を書きます。
- /unslop：あらゆる種類の AI による文章をクリーンアップするとき。簡潔に話すようにさせます。
- /reflect：長い会話の後、継続的にスキルを向上させたいとき。
- /figure-it-out：何か変わったことをしているとき。タスクのための厳密で監査可能なプレイブックを設計します。
- /show-me-your-work：レビュー可能な決定の軌跡が欲しいとき。決定を tsv に記録してコミットできます。
そして最後に、/automate-me で独自のモードスキルを作成できます。最近のトランスクリプトをマイニングし、あなたの作業方法から your-mode スキルをドラフトし、内部で pstack を経由します。
pstack はあらゆるエージェンティックコーディングツールで動作しますが、Cursor のようなマルチモデルツールで特に効果的です。多くのスキルは、各モデルのユニークな強みと弱みを活用するためにマルチモデルワークフローを使用します。これはエージェントオーケストレーションですが、幅優先ではなく深さ優先で適用されます。
エージェントのボトルネックは検証です。エージェントは大量のコードを迅速に書くことができます。それがすべて正しいことを確認するのは非常に困難です。そこに到達できれば、ソフトウェアのダークファクトリーのような、真のエージェント並列化が可能になるかもしれません。
しかし、まずは深く進み、厳密になる必要があります。信頼を高めることでそこに到達できると思います。
pstack を試して、感想を聞かせてください。
禅とソフトウェアメンテナンスの技術
これらのスキルは、コードを書く際により自信を持って動くのに役立ちます。しかし、エージェントがすべてのコードを書く今、コードのメンテナンスは悪夢です。バグ、パフォーマンス問題、機能リクエストには依然として時間がかかります。そして、コードは以前よりずっと多くなっています！
私は Cursor で Cursor の自動化を広範囲に活用しています。これらはクラウドエージェントで、スケジュール設定したり、Slack チャンネルへの新しいメッセージなどのイベントに応じて実行できます。その一例が、私のボット Benny です。彼には pstack と同じスキルを与えています。
Benny はまだ開発中ですが、私のビジョンはソフトウェアメンテナンスプロセスを可能な限り自動化することです。考え方はこうです：もし pstack を使って問題をほとんど「一発」で解決でき、PR の品質が高いという確信が十分にあるなら、フィードバックも自動化できるはずです。
このファクトリーは、トリアージから始まります：従業員からバグレポートに関する情報を収集します。私たちは Cursor を頻繁にドッグフーディングしているため、リリース候補について従業員から多くのフィードバックを得ます。Benny は画像やビデオの添付ファイルを理解し、pstack スキルを使用してコードベースを探索し、再現手順が不明な場合はレポーターとチャットして情報を収集します。
これはバグ報告プロセスの重要な部分です。明確な再現手順と何が壊れているかの理解がなければ、エージェントは解決策を推測することしかできません。どこで、どのように壊れているのかを正確に理解させる必要があります。
トリアージ後、Benny はコードの調査、最近のバグ回帰のための git 履歴、同じバグに関する他のメッセージのための Slack、機能がどのように動作すべきかについての設計や製品決定のための Notion などから得た調査結果を含むチケットを作成します：それはバグなのか、それともこのように動作するように設計されたのか？
チケットが提出された後、別の Benny ボットが、私が作成した別のスキル /orchestrate を使用してそれを引き継ぎます。
まず、コンピュータ操作を通じて問題の再現を試みます。Cursor の Cloud Agents は、クラウド上で Cursor 自体を実行でき、デスクトップと対話し、クリックし、キーボード入力を送信します。内部的には、CDP または同等のプロトコルを使用して製品をプログラム的に制御するために私が作成した、より多くのスキルを使用しています。
これにより、バグレポートが再現可能かどうかを実証できます。バグが一貫して再現される場合、彼は修正を試みます。パフォーマンス問題の場合は、Benny は修正前後の CPU トレースとヒープスナップショットを取得できます。サブプランナーは、pstack スキルを使用して修正を検証し、修正された場合はチケットに対して作業をチェックするために、より多くのワーカーを生成します。
この実行では、修正前後のビデオを撮影するために追加のワーカーが生成され、最後にワーカーが説明にビデオを添付してレビュー用の PR を開きます。
これはすべてまだ開発中であり、やるべきことはまだたくさんありますが、私が寝ている間や他のことをしている間に、自信を持ってバグを修正してくれるエージェントチームを持つことに興奮しています。コードレビューをスケーラブルにすることも大きな分野であり、Cursor にはそれを支援するクールな新機能が近日中に登場すると思います。
しかし、独自のソフトウェアファクトリーを構築するための鍵は信頼です。検証を含め、エージェントが問題をエンドツーエンドで所有できると信頼できなければ、プロセスを自動化することはできません。pstack のようなプラグインを使用してエージェントにより多くのエンジニアリングの深みを与え、信頼を高めるにつれて、より野心的な問題に取り組めるようになります。まだ信頼していないエージェントを並列化しようとすることは、トークンの大きな無駄であり、コードベースにさらに多くの粗悪なコードをもたらします。
お読みいただきありがとうございます！
