AIコーディングで本当に知っておくべきこと（vibeコーディングではなく）

概要

ソフトウェアエンジニアがAIを「戦略的に導く」やり方と、ただ生成に任せる「vibeコーディング」との違いを解説する動画。Warp Codeでデモしているが、Claude CodeやCursorなど他のツールにも共通する原則として、ルール設定・プロンプトの具体性・計画駆動の開発フロー・マルチエージェント活用までを体系的に紹介している。

主なポイント

• AIにコードベース全体の文脈を持たせるため、事前にインデックス（コードベースコンテキスト）を作らせておく
• グローバルルール（コーディング規約・使用ライブラリ・テスト方針）とプロジェクト固有ルール（技術スタック・DBスキーマ・APIパターン・ブランチ命名）をWARP.md/CLAUDE.md/.cursorrulesなどのファイルに分けて管理し、毎回同じ指示を繰り返さない
• プロンプトは曖昧にせず、変更対象のフィールド名・エンドポイント・条件分岐まで具体的に書く（「編集ボタンをトグルにして」ではなく実装内容を明記）
• ファイル参照やコードのハイライト、UIバグのスクリーンショットをプロンプトに添付し、追加コンテキストを与えることでトークン消費とコストを抑えつつ精度を上げる
• タスクに応じてモデルを明示的に指定し（例: 計画はGPT-5 high reasoning、実装はOpus/Sonnet）、必要のない限り会話途中でモデルを切り替えない
• 1つの会話は短く・焦点を絞る（会話履歴が毎回コンテキストに含まれるためコストが増える）
• 「まず計画を立てさせ、コードは書かせない→計画を確認・制約を付けて実装させる」というスプリント的なワークフローを徹底する
• 生成されたコードは新人とのペアプログラミングのようにレビューし、「なぜこの実装にしたか」を質問し、自分でも積極的にコードを編集する
• 複数エージェントを並列活用する（同じタスクを実装・レビュー・テストで役割分担、または独立タスクをgitのworktreeで並列実行）
• パーミッション設定で自動実行タスクと承認必須タスクを分け、エージェントが暴走したら作業を中断して直前のコミット/チェックポイントに戻す

実践に使えること

• プロジェクトルートにグローバルルール用と、サブモジュールごとのプロジェクト固有ルールファイルを整備する
• プロンプトを書く前に「対象ファイル」「変更内容」「制約」をテンプレート化して毎回埋める
• 大きめの機能追加では、まず「コードを書かず計画だけ出させる」プロンプトを投げてから実装を指示する
• モデル切り替えの基準（計画用・実装用）を決め、無駄なモデル切り替えによるコスト増を避ける
• git worktreeを使って複数のAIセッションを独立タスクで並列に走らせる