カーソルを間違って使っています

ほとんどの開発者はCursorを開き、エージェントモードに入って、段落の長さのフィーチャーリクエストを入力し、Enterキーを押します。「認証、役割ベースのアクセス、チャートを備えたAI駆動のダッシュボードを作成して」と言い、モデルがリポジトリ全体のファイルを書き換え始めるのを見ながらくつろぎます。最初の30秒間は魔法のように感じますが、差分を読んでしまうまでは。

その単一のプロンプトの背後で、AIはあなたが残したすべての隙間を静かに埋めていきます。それは、プロジェクトの制約ではなく、自らの先入観に基づいてフォルダ構造、状態管理、APIの境界、さらにはUIパターンを決定します。あなたは、技術的にはコンパイルできるコードを手に入れますが、しばしばあなたのデザインシステムを無視したり、既存の抽象を壊したり、他のファイルに既に存在するロジックを再実装したりします。

それがエージェントモードの罠の核心です：あなたは実装を委任していると思っていますが、実際にはアーキテクチャを委任しています。カーソルが「Stripe請求を追加」と見た場合、先 quarter に書いた支払いユーティリティと統合するのではなく、新しいフック、ルート、設定を発明するかもしれません。それらは500行の差分をスクロールして、なぜアプリの半分が動いたのか疑問に思うまで、目に見えない仮定です。

結果が自分のメンタルモデルから外れると、あなたは「再実行」プロンプトの儀式を始める。「いいえ、フォルダ構造は維持して」と言い、次に「実際にはTailwindを使って」と言い、「認証フローには触れないで」と言う。そのたびに別の大規模なリファクタリングが引き起こされる。モデルは解釈の間で揺れ動き、あなたの制約が頭の中にのみ存在しているため、共有された計画にはない。

trivial変更を超えるもの、たとえばプロパティの名前変更や小さなバグの修正などに関しては、このワークフローは効果的にスケールしません。複数ファイルにまたがる機能、横断的な懸念、段階的なリファクタリングは、各部分がどのように組み合わさるべきかの共通のメンタルモデルを必要とします。エージェントモードは盲目的に使用されると、そのステップを飛ばして、関連性があると思われるファイルの編集に直接飛び込んでしまいます。

あなたはAI生成のアーキテクチャ決定に対する人間のリンターのように振る舞うことになります。素早く出荷する代わりに、驚くべきマイグレーションをレビューし、攻撃的な編集を戻し、不自然な抽象化を修正するために時間を費やしています。カーソルは「コードスロットマシン」となり、レバーを引いて差分が意図と一致することを願い、一致しないときは再度引くことになります。

ほとんどの人はCursorをコードの自動販売機のように扱っています：巨大なプロンプトをエージェントに入力し、送信して、編集が理にかなっていることを願う。Cursorプランモードは、そのワークフローに欠けていたステップを追加し、AIを積極的なインターンから、ファイルに触れる前に作業を整理する慎重なテックリードへと変えます。

リポジトリ全体に変更を一度に適用するのではなく、プランモードの基本的な役割はシンプルかつ厳格です：「タスクを達成するための詳細な計画を作成する」。カーソルはあなたのコードベースをスキャンし、明確化のための質問を行い、コード生成が始まる前にアーキテクチャの決定、ファイルレベルの変更、実装ステップを詳述したMarkdownの青写真を草案します。

アクセスは、すでにエージェント用に使用しているドロップダウンにあります。チャット入力の隣にあるモードセレクターをクリックすると、次のオプションが表示されます： - エージェント：直接のコード編集用 - プランモード：構造化された実装計画用 - デバッグ：ランタイムの問題を追跡および修正する用 - 質問する：編集なしの純粋なQ&A用

プランモードに切り替えるとカーソルの動作が反転します。例えば、「OpenAI APIを使用してこのNext.jsアプリにAI駆動のカラーパレットジェネレーターを追加する」というプロンプトは、即座にファイルを書き込むのではなく、通常はコンポーネント、API統合ポイント、UI状態、エッジケースを概説した中間プランファイル（通常は`.md`）を生成します。

そのMarkdownプランは、生きた仕様書として機能します。ビルドステップが実行される前に、手順を編集したり、リスクのあるアイデアを却下したり、ファイルの名前を変更したり、範囲を縮小したりできますが、エージェントモードだけでは急いでいるときにはあまり促されません。5〜10のファイルにまたがる複雑な機能に対して、この事前の交渉は再作業や予期せぬ差分を大幅に削減します。

Cursorは、会話エンジンとしてプランモードも使用します。このモデルは、デザインの好みやパフォーマンスの制約、ライブラリの選択について質問し、あなたの回答に基づいてプランを更新します。これにより、「AIが静かに決定する」から共著の意図へと移行し、品質が向上します。

これは混雑したUIの中の単なるトグルではありません。プランモードは、Cursorをコード作成者から計画パートナーに再構築し、`pnpm dev`を実行する前に設計書を求めるシニアエンジニアとのペアリングに近づけます。一度採用すると、計画なしでエージェントを起動することが無謀に感じ始めます。

カーソルプランモードは、一見シンプルなことから始まります：おおよそのアイデアを入力するだけで、仕様書ではありません。デモでは、アストロ・K・ジョセフが空のNext.jsスターターの上に「AI駆動のカラーパレット生成ウェブサイト」のあいまいなブリーフを追加します。まだファイルの変更は行われず、プランモードは編集ではなく分析に移行します。

静かに前進する代わりに、AIは質問を返してきます。Cursorは、ダークテーマかライトテーマか、ユーザーがパレットを生成する方法（テキストプロンプト、画像アップロード、またはランダム）、そしてOpenAI APIの役割について尋ねます。また、レイアウトの詳細についても探ります：ランディングページとマルチページアプリ、カラーコードを表示する場所、そしてユーザーがパレットを保存または共有すべきかどうかです。

そのやり取りは、曖昧なアイデアを具体的な青写真に変えます。あなたが応答する頃には、次のような決定が下されています：

• 1UXフロー（シングルページ vs. ダッシュボードスタイル）
• 2パレット生成トリガー（ボタン、ライブプレビュー、またはフォーム送信）
• 3OpenAI APIからのデータ形式とその検証方法
• 4「洗練された現代的」対「遊び心のある」といった視覚的制約

カーソルはその回答をMarkdownプランにまとめます：プロジェクト概要、APIの使用、UIコンポーネント、ルーティング、実装ステップのセクションがあります。各ステップは特定のファイルと関数を参照しており、新しいコンポーネント、フック、およびユーティリティモジュールがどこに配置されるかを正確に把握できます。コードに手を触れる前に、そのプランをミニデザインドキュメントのように編集することができます。

それと対照的なのがエージェントモードで、これはあなたのためにすべての呼び出しを静かに行ってしまいます。ランダムなレイアウトを選ぶこともあれば、ライトテーマをハードコーディングしたり、OpenAIのレスポンスをあなたのアーキテクチャと衝突する形で状態に組み込んでしまうこともあります。そういった前提は、コードベース全体に変更が散らばった後に初めて気づくことになります。

インタラクティブなプランニングは、その曖昧さを排除します。あなたとCursorは、APIの予算からUIの仕上げまで、制約を共同所有するため、後の「コード生成」ステップは実行のように感じられ、ルーレットのようではありません。より大規模なプロジェクトでこのプランニングレイヤーがどのように機能するかについて詳しい例は、CursorのCursor Plan Mode公式ブログで、より多くのファイルやステップを含むワークフローが分解されています。

カーソルプランモードは考えるだけでなく、書きます。要件の交渉が終わると、それをすべてMarkdown仕様書という形に具現化します。これは、AIがコードの1行も変更する前に、何をするかを正確に記した単一の`.md`ファイルです。

そのMarkdownプランは通常、アーキテクチャの概要で始まります。アプリのコアコンポーネント、データフロー、境界について説明するセクションがあり、フロントエンドに何が存在し、API層に何が接触し、状態がシステム内でどのように移動し、OpenAI APIなどの外部サービスがどのように接続されているかが示されます。

次に、具体的な技術スタックの内訳が示されます。Next.jsのカラーパレットジェネレーターの場合、Cursorは「Next.jsアプリルーター、TypeScript、Tailwind CSS、OpenAI API、ミューテーションのためのサーバーアクション」といった決定を固めることができます。さらに、「データベースは使用せず、ローカルステートのみを使用」や「localStorageを通じてパレットを永続化」といった制約も考慮されます。

仕様は次に、現実のファイルレベルのマップに移ります。通常、次の内容が含まれます： - 作成するファイル（例：`app/page.tsx`、`app/api/palettes/route.ts`） - 修正するファイル（例：`app/layout.tsx`、`styles/globals.css`） - 現時点では手を付けないファイル

その下に、プランモードはステップバイステップのやることリストを示しています。各箇条は特定のアクションを説明しています：「プロンプトフォームを実装する」、「APIルートをOpenAIに接続する」、「ローディングとエラーステートを追加する」、「再利用可能な`PaletteCard`コンポーネントを作成する」、「APIハンドラーのための最小限のテストを書く」。カーソルは後にこのチェックリストを実行スクリプトとして使用します。

そのプランはMarkdownに存在するため、軽量な設計文書のように機能します。エディタでレビューしたり、コードレビューでコメントを追加したり、リファクタリングが行われる前にチームメンバーから迅速なフィードバックを得るためにSlackにスニペットを貼り付けたりできます。

チームはこれらの `.md` プランをリポジトリにコミットすることもできます。これにより、機能が存在する理由、受け入れたトレードオフ、実装がどのように進化したのかを検索できる履歴が作成されます。これは、ミステリーのようなプルリクエストの差分よりもはるかに透明性があります。

最も重要なことは、このアーティファクトがあなたに完全な透明性を提供することです。Cursorが静かにファイルを編集する代わりに、あなたは変更の全意図、範囲、順序を事前に確認し、AIが一行も書く前に設計図を承認します。

製品仕様の最初のドラフトを出荷することはありませんし、Cursorの計画の最初のドラフトを出荷するべきではありません。CursorのプランモードがそのMarkdownの青写真を吐き出したら、あなたの本当の仕事が始まります。設計者として行動し、観客ではなくなるのです。

カーソルは、AI駆動のカラーパレットジェネレーターのために、ルート、コンポーネント、APIコール、さらにはファイル名を提案します。あなたはMarkdown仕様に沿って、余分な部分を削除し、モジュールの名前を変更して、実際のアーキテクチャ、デザインシステム、そして譲れない要素に計画を整えます。

AIが忘れた「画像をアップロードして主要な色を抽出する」機能が必要ですか？計画に新しいサブセクションを追加します：必要なUIの変更、`/api/upload`エンドポイント、ファイルサイズの制限、画像はローカルディスクではなくS3に送信されるという注意事項。これで、Cursorはあなたのスタックやインフラを推測するのではなく、正確で人間によって承認された契約を持つことになります。

悪い仮定がコードに悪化する前に修正することもできます。Cursorがクライアントから直接OpenAI APIを使用することを提案した場合、そのステップを書き直してすべてをサーバーサイドのNext.js APIハンドラーを通すようにし、レートリミッティングを追加し、環境変数の使用を明記します。

この編集優先のループは、後からデバッグするよりもはるかに安全です。計画を修正することは数行のMarkdownを変更することで済みますが、生成されたコードを修正するには、5〜10のファイルを探り、副作用を解消し、AIがなぜ奇妙な抽象化を選んだのかを推測しなければならないことが多いです。

より迅速に動けます。計画を更新して以下を追加します： - ダークモードのサポート - キーボードショートカット - ユーザープロフィールへのパレット保存

テキスト内で数秒で完了し、エージェントモードでの複数のプロンプト生成と戻りのサイクルを必要としません。その後、カーソルはその単一の改良された計画を一貫した形で実行します。

あなたが最終的な権限を持っています。Cursorが戦略を作成しますが、どのライブラリ、パターン、制約が残るかはあなたが決定します。プランモードをジュニアエンジニアが設計文書を書くものと考えてください：価値があり、迅速で詳細ですが、一行のコード変更もあなたのレビューに常に従う必要があります。

承認は、Cursorが考えるのを止め、行動を開始する場所です。Buildをクリックすると、推測的なMarkdown仕様が即座に契約として確定します。その文書内のすべての箇条書き、ファイルパス、TODOが、次に何が起こるかのエージェントの真実の源となります。

Cursorのエージェントは、現在、そのプランをあなたのリポジトリのマイグレーションスクリプトのように扱います。チェックリストをステップバイステップで進みながら、具体的なアクションを実行します：ファイルの作成と名称変更、パッケージのインストール、インポートの接続、設定の更新など、全てあなたがすでに承認した構造に沿って行われます。

プランモードでの重い推論が行われるため、実行は迅速かつ驚くほど決定論的です。モデルはもはやアーキテクチャを再議論するためにトークンを消費することはなく、「ステップ3: /app/api/palettes/route.tsを実装する」を編集にマッピングするだけで、迷走したリファクタリングやランダムなファイルの修正を削減します。

CursorがMarkdown仕様をビルドログのように進む様子を観察できます。完了した項目は、ファイルを編集する際にチェックされるため、AIが静かにあなたの背後で何を変更しているのかを悩むことなく、正確にページを構築したり、フックを挿入したり、プロバイダーを接続したりする瞬間を確認できます。

複雑な操作は、同じ設計図に基づいているため、脆弱に感じることはありません。Next.jsアプリでは、Cursorが一度の操作で次のことを行えます： - 正しい /app/api サブツリーの下に APIルート を設定 - Tailwindやshadcn/uiのような UIライブラリ をインストールおよび設定 - Reactコンポーネントをレイアウト、セクション、共有プリミティブに構造化

その動きは「スマート」に見えますが、実際には従順です。もしプランに「カスタムカラー パレットを使ってTailwindを使用する」と書かれていれば、Cursorはtailwind.configを追加し、globalsを更新し、仕様が示す正確な場所にJSXでクラスを注入します。無作為なデザインシステムを即興で作り出すのではなく。

依存関係管理もプランの制御下にあります。MarkdownがOpenAI、Zustand、またはチャートライブラリを要求すると、Cursorは対応するnpmまたはpnpmのインストールを実行し、tsconfigやenvの型定義を更新し、その後、これらのパッケージが存在することを前提としたコードを書きます。

より深い技術的挙動やその他の自動化トリックについては、CursorがCursorの機能ページでこの構築予定のパイプラインを文書化していますが、基本的な変更はシンプルです。ビルドを開始すると、Cursorは議論をやめ、設計図を行ごとに実行し始めます。

ほとんどのカーソルユーザーはプランモードを魅力的なトグルスイッチのように扱い、その後無視しています。それは間違いです。プランモードは、実際にアーキテクチャを変更する作業のために存在しており、単一のファイルに数行のコードを追加するためのものではありません。

アプリの形を変更する際には、カーソルプランモードに手を伸ばしてください。これには、複数のコンポーネントに関わる新機能の構築、新しいAPIの導入、またはプロジェクト全体のデータフローの再構築が含まれます。図を描いたりデザインドキュメントを書いたりする必要があると感じたとき、それはプランモードの領域です。

Plan Modeは、複数のファイルを同時にリファクタリングする際に真価を発揮します。RESTからGraphQLへの移行や、モノリシックなReactコンポーネントを適切な機能モジュールに分割すること、自作の認証レイヤーをOAuthに置き換えることなどが考えられます。Cursorは影響を受けるファイルをマッピングし、段階的な手順を提案し、編集を無秩序に散発するのではなく、全体のリファクタリングを一貫性のあるものに保ちます。

馴染みのないコードベースですか？プランモードにデフォルト設定します。50,000行のレガシーアプリを引き継ぐ際、Cursorは混乱をあなたよりも速く読み取り、主要なモジュールをアウトライン化し、新しいロジックがどこに置かれるべきかを提案します。あなたはアーキテクチャの制御を維持しながら、AIがスキャンと整理という骨の折れる作業を扱います。

複雑なロジックもプランモードに属します。支払いフロー、マルチステップのオンボーディング、バックグラウンドジョブのオーケストレーション、あるいはリトライ、競合条件、厳密なパフォーマンス制約を伴うすべてのものは、レビュー、コメント、リポジトリへのコミットができるMarkdownプランから恩恵を受けます。

エージェントモードは依然として重要ですが、外科的な編集に使います。変更したい内容や場所がすでに分かっている場合は、エージェントを使用し、カーソルにあなたよりも早く入力させてください。タスクが一つのメンタルスクリーンに快適に収まる場合は、計画を立てる必要はないでしょう。

迅速でローカルな調整のために、エージェントモードに留まり、計画の手間を避けましょう： - 1つの関数のバグ修正 - ファイル全体での変数またはプロパティの名前変更 - コンソールログまたは単一のガード句の追加 - 小さなJSXスニペットやCSSルールの更新

プランモードをあなたの建築的な共同パイロットとして扱い、スペルチェッカーとして使用しないでください。設計の決定が重要なときに利用し、ただの素早い手が必要なときはスキップしてください。

カーソルは、そのモードを連携したシステムとして扱うとき、「単なるAIのオートコンプリート」以上の存在になります。カーソルプランモードは青写真を提供しますが、初回の構築後にすべてを処理する2つの他のエージェントとともにあります：デバッグモードとアスクモードです。これらは一緒に、構造、修理、調査の緊密なループを形成します。

Plan Modeをあなたの建設クルーとして考えてください。これは、Markdown仕様書の共著、ファイル構造の決定、変更を加える前にアーキテクチャに合意するために使用します。一度Buildを押すと、Agent Modeがその計画を実行し、事前に承認した方法でコンポーネント、API、UIを接続します。

バグは、アプリが実際のデータやユーザー、あるいは単に誤設定された環境に触れた瞬間に発生します。デバッグモードはまさにその瞬間のために存在しており、感覚ではなく実行時のトレースを利用します。Cursorはスタックトレース、ログ、エラーメッセージを取り込むことができ、それらを不具合を起こしている特定のファイルや関数にマッピングします。

コンソールログによるデバッグで手探りするのではなく、デバッグモードに失敗しているコマンドやテスト出力、またはトレースを提供します。これにより以下のことが可能になります： - 関連ファイル内の根本原因を特定する - 最小限のスコープで修正を提案する - 既存の計画を保持しながらパッチを適用する

Ask Modeはワークフローの第三の側面、すなわち理解をカバーします。Ask Modeでは、コードベースを検索可能な脳のようにじっくりと調査することができ、編集権限は一切与えません。「JWTの検証はどこで行いますか？」、「テーマの状態はレイアウトからコンポーネントにどのように流れますか？」あるいは「このPRは先週と比べて何が変わりましたか？」と尋ねることができます。

Ask Modeはあなたのリポジトリ、ドキュメント、さらにはPlan Modeが生成したMarkdown仕様さえも読み取るため、まるで社内のスタッフエンジニアのように機能します。ファイルパス、コードの抜粋、説明を伴って回答しつつ、編集は完全に手動でコントロールできます。意外なリファクタリングや隠された差分はありません。

専門的なツールキットとして活用してください：建設用のプランモード、修理用のデバッグモード、相談用のアスクモード。あなたは機能を計画し、コードを出荷し、クラッシュをデバッグし、アーキテクチャを問い合わせます。すべてCursorの中で行い、半端なツールと半分焼きのAIチャットを行ったり来たりする必要はありません。

AI コーディングはかつてパーティーの手品のように見えていました：機能を説明して生成を押し、うまくいくことを願うというものです。Cursor Plan Mode はその脚本を静かにひっくり返し、モデルを自動補完から一歩進めて、まるでスタッフエンジニアのように振る舞う仕様主導のコラボレーターに変身させます。

従来の「プロンプトと祈り」から、今ではあなたのリポジトリに存在し、他のアーティファクトと同様にバージョン管理されレビュー可能なMarkdownデザイン文書を共同執筆します。カーソルはコードベースを歩き、ファイル単位の変更を提案し、単一の行にも触れる前に明確な質問を投げかけます。これは、真剣なチームがすでにRFCや技術仕様書を用いて作業する方法を反映しています。

その構造は、コードを変えるだけでなく、開発者の心理も変えます。コンポーネント、API呼び出し、エッジケースの具体的なチェックリストを見ると、埋もれてしまう前に、反論したり、範囲を再構築したり、欠落している制約を指摘したりできます。開発者は、AIが「決定」したことを逆解析する時間を減らし、実装を指導する時間を増やすことで、より迅速な反復を報告しています。

コード品質は、モデルがあいまいな文ではなく、共有された計画に対して最適化するため向上します。「パレット生成にOpenAI APIを使用する」、「テーマトークンを集約する」、「ダークモードをサポートする」と明示的にリスト化された計画は、驚きの抽象化、不要なファイル、一回限りのハックを大幅に減少させます。その結果、脆弱なパッチが少なくなり、特に複数ファイルのNext.jsやReactビルドにおいて、一貫性のあるアーキテクチャが得られます。

自信も高まります。Cursorがステップバイステップの実行パスを表示すると、どこで問題が発生する可能性があるのか、どこにテストを配置すべきか、プルリクエストで何を見直すべきかが分かります。その透明性により、著作権を手放すことなく自動化を信頼しやすくなり、チームはますますPlan Modeを軽量なデザインレビューゲートとして扱うようになっています。

ズームアウトすると、これはより広いエージェントファーストのワークフロートレンドの一部です。ツールは単発のプロンプトから、計画、批評、そして実行を行うマルチステップのエージェントに移行しています。この進化についてのより深い考察は、(LSJ) Cursorの新しいプランモード - Lifetime Worldが類似のパターンを分解しています。

今日のカーソルプランモードは機能のトグルのように見えます。数年後には、このような計画から構築するループが、人間と機械が同じ仕様から作業することでソフトウェアが開発されるデフォルトの方法になるでしょう。

Cursorは、実際にプランをエンドツーエンドで実行したときにのみ新しいパラダイムとして機能します。そこで、5分間の挑戦です：今すぐ、明日や「時間があるとき」ではなく、Cursorプランモードを使ってマイクロ機能を出荷してください。

小さく、焦点を絞ったプロジェクトを構築しましょう：Markdownノート作成アプリ。`タイトル`と`コンテンツ`の二つのフィールドと、保存したノートのリストだけを備えています。認証、同期、タグ、気を散らす要素はありません。Cursorの計画を判断できるほどの、小さなものを求めているのです。

お好きなスタックで空のプロジェクトを作成してください：最小限のNext.jsアプリ、Vite + Reactスターター、または単一ファイルのNodeスクリプトでも構いません。リポジトリはクリーンに保ちましょう：余分なライブラリ、UIキット、データベースの統合はまだ必要ありません。キャンバスがシンプルであればあるほど、Cursorの計画はより明確に伝わります。

次に、サイドパネルのモードをエージェントからプランモードにドロップダウンを使って切り替えます。色の変化を確認し、誤って自動編集の世界に入らないようにしましょう。モデルを選択し、他の何も入力せず、「コード」から「デザイン」への精神的なシフトに意識を向けるようにしてください。

シンプルなMarkdownノート作成アプリを作成してください。タイトルフィールド、Markdownをサポートするコンテンツテキストエリア、保存されたノートのリスト、基本的なクライアントサイドストレージを含めます。クリーンでレスポンシブなレイアウトを使用してください。状態管理ライブラリやCSSフレームワークなどの実装詳細については避けてください。

- フレームワークまたはスタックの好みはありますか？ - LocalStorage と API バックエンドのどちらを選びますか？ - スタイリングのアプローチ：CSS モジュール、Tailwind、またはインラインスタイルのいずれですか？ - ファイル構造に関する制約はありますか？

そのやり取りの後、CursorはMarkdown仕様書を生成し、ファイル、コンポーネント、ストレージの選択、UIの状態を概説します。行ごとに読み、ファイルパス、コンポーネント名、Markdownレンダリングの処理方法を確認してください。ドキュメントとして実際に書くように仕様を編集し、チームメイトのためのものと一致させます。

計画が退屈に明白だと感じたときにだけ、Buildを押してください。あなたが共著したチェックリストを進むCursorを見てください。その瞬間、漠然としたアイデアが構造化された実行可能な青写真に具現化する様子を見ることは、Cursorの使い方を永久に変える「アハ！」の瞬間です。

Cursorのプランモードとは何ですか？

Plan Modeは、Cursor IDEの機能で、あなたとAIが協力して、コードを書く前にMarkdownファイル内で詳細なステップバイステップの実施計画を作成することを可能にします。これにより、アプローチの明確さと一致を保証します。

プランモードはデフォルトのエージェントモードとどのように異なりますか？

エージェントモードはプロンプトに基づいてあなたのコードを直接編集します。一方、プランモードは最初に設計図を生成し、明確化の質問を行い、計画を確認して編集することを許可し、その後にビルドプロセスを実行するため、エラーや再作業を削減します。

Cursorのすべてのタスクにおいて、プランモードは必要ですか？

いいえ、そうではありません。プランモードは、中～大規模な機能や複数のファイルの変更、または馴染みのないコードベースで作業する場合に最も効果的です。小さい、局所的な編集には、通常、標準のエージェントモードの方が効率的です。

AIがコーディングを開始する前にプランを編集できますか？

はい。プランモードの中心的な利点は、生成されたMarkdownプランを確認、編集、追加できることです。ビルドを開始する前に、最終的な設計図を完全にコントロールできます。