1. コードを作成する前に計画を立てる必要があるのはなぜですか?
Vibe コーディングで最もよくある間違いの 1 つは、計画なしにいきなりコーディングに取り掛かることです。通常、結果は次のようになります。
- エージェントが間違った方向に進み、最初からやり直す必要がある
- コード構造が規模に適していない
- 重要なエッジケースが欠落している
- 多くの反復 (およびトークン/リクエスト) のコストがかかる
プランエージェント 段階を分けることでこの問題を解決する 計画中。計画 そして 実装。実装。
2. エージェントのワークフローを計画する
┌─────────────────────────────────────────────────┐
│ PLAN-FIRST WORKFLOW │
├─────────────────────────────────────────────────┤
│ │
│ 1. 📝 USER: Mô tả feature/task │
│ ↓ │
│ 2. 🔍 PLAN AGENT: Phân tích codebase │
│ - Đọc files liên quan │
│ - Hiểu architecture hiện tại │
│ - Hỏi clarifying questions nếu cần │
│ ↓ │
│ 3. 📋 PLAN AGENT: Tạo implementation plan │
│ - Step-by-step tasks │
│ - Files cần tạo/sửa │
│ - Dependencies cần install │
│ - Potential risks/trade-offs │
│ ↓ │
│ 4. 👀 USER: Review + điều chỉnh plan │
│ ↓ │
│ 5. 🚀 HAND OFF: Plan → Agent để implement │
│ │
└─────────────────────────────────────────────────┘
3. プランエージェントを使用する
ステップ 1: プランエージェントを選択する
チャットビューで、選択します 「計画」 エージェントのドロップダウンから。
ステップ 2: タスクの説明
I want to add a real-time notification system to our Express.js app.
Requirements:
- WebSocket-based (Socket.IO)
- Notification types: info, warning, error, success
- Persist notifications in PostgreSQL
- Mark as read/unread
- Bell icon with unread count badge
- Dropdown showing recent notifications
- API endpoints for CRUD operations
- Only authenticated users receive notifications
ステップ 3: プラン エージェントがプランを分析して返す
プラン エージェントは次のような構造化されたプランを作成します。
## Implementation Plan: Real-time Notification System
### Phase 1: Database & Models
1. Create `notifications` table migration
- Fields: id, user_id, type, title, message, is_read, created_at
2. Create Notification model (Sequelize/Prisma)
3. Add relations to User model
### Phase 2: Backend API
4. Install socket.io dependency
5. Create NotificationService (create, getByUser, markAsRead, delete)
6. Create NotificationController with REST endpoints
- GET /api/notifications (with pagination)
- PATCH /api/notifications/:id/read
- DELETE /api/notifications/:id
7. Add authentication middleware to notification routes
### Phase 3: WebSocket Integration
8. Setup Socket.IO server alongside Express
9. Implement auth for WebSocket connections (JWT verification)
10. Create room-per-user pattern for targeted notifications
11. Emit events on notification create/update
### Phase 4: Frontend Components
12. Create NotificationBell component (badge with unread count)
13. Create NotificationDropdown component
14. Setup Socket.IO client with auto-reconnect
15. Add toast notifications for new incoming notifications
### Trade-offs & Risks:
- Socket.IO adds complexity; consider SSE for simpler use case
- Need Redis adapter for multi-server deployment
- Consider rate limiting notification creation
ステップ 4: 確認と調整
次のように応答できます。
Good plan! But let's make these changes:
- Use Prisma instead of Sequelize
- Add a Phase 0 with unit test setup
- Skip the toast notifications for now
- Add rate limiting in Phase 2
ステップ 5: エージェントに引き継ぎます
プランがOKの場合は、選択してください エージェントに引き継ぎます。エージェントは計画を段階的に実行し、セッション内の進行状況を追跡できます。
4. さまざまなシナリオを計画する
4.1.新機能
Plan adding OAuth2 social login (Google, GitHub) to our Next.js app.
We currently use JWT with email/password auth.
Consider: NextAuth.js vs custom implementation.
4.2.リファクタリング
Plan migrating our REST API from Express.js to Fastify.
Current codebase has 15 route files, 8 middleware, Sequelize ORM.
We want zero downtime migration — propose a phased approach.
4.3.バグ調査
Plan debugging this issue: Users report that their session expires
randomly after 10-15 minutes, even though token expiry is set to 24h.
Analyze our auth flow and create a debugging plan.
4.4.アーキテクチャの決定
Plan the data layer for our e-commerce app. Compare these options:
1. PostgreSQL + Prisma
2. MongoDB + Mongoose
3. PostgreSQL + Drizzle ORM
Consider: our team knows SQL, we need transactions, Vercel deployment.
5. プランファーストとコードファースト
| 基準 | 計画第一 | コードファースト (ダイレクトエージェント) |
|---|---|---|
| いつ使用するか | タスクは複雑で複数のファイルがあり、アーキテクチャに影響を与える | タスクはシンプルで、単一の機能があり、明確に定義されています |
| セットアップ時間 | 長期 (計画 + レビュー) | 高速 (今すぐコーディング) |
| 出力品質 | 高いほどやり直しが少なくなる | 迅速な品質に依存します |
| リスク | 低い（問題を早期に発見） | より高い（おそらく間違った方向に） |
| トークンの効率 | より良い（反復回数が少なくなる） | 何度も繰り返しがかかる場合がある |
経験則:
- タスク < 30 分 → コードファースト (ダイレクト エージェント モード)
- タスク > 30 分、または多くのファイルに影響する → 計画優先
- 移行またはリファクタリング → 常に計画を優先する
6. 効果的な計画を立てるためのヒント
- 完全なコンテキストを提供する: 技術スタック、現在の規約、制約
- あなたが知っているトレードオフを明確に述べてください: プラン エージェントが正しい決定に集中できるように支援します。
- リスク分析をリクエストする: 「何が問題になる可能性がありますか?」または「エッジケースは何ですか?」
- 代替案について尋ねる: コミットする前に「アプローチ A と B を比較」
- 引き継ぎを行う前に計画を注意深く確認してください: 計画の編集は、実装されたコードを編集するよりも簡単です
7. 練習問題
- チャットビューを開く → 選択 計画 エージェント。エージェント
- プロンプト: 「ファイルベースの投稿、タグ、カテゴリー、検索、RSS フィード、ダーク モードを備えたマークダウン ブログ エンジンの構築を計画してください。Next.js 15 と Tailwind を使用してください。」
- プランエージェントからのプランのレビュー
- 少なくとも 2 点の調整が必要です
- フェーズ 1 を実装するためにエージェントに引き継ぎます
8. まとめ
Plan Agent は「アーキテクト」です - それはあなたを助けます 行動する前に考える。このシリーズの第 5 回では、すべての実際のプロジェクトに対してプランファーストのアプローチを使用します。
| ワークフロー | ステップ |
|---|---|
| 計画第一 | 説明→計画→レビュー→調整→引き継ぎ→実装 |
| コードファースト | 説明→実装→レビュー→反復 |
次の曲はカバーになります クラウドエージェントとCopilot CLI — ローカル、バックグラウンド、クラウド、プル リクエスト経由など、どこでもエージェントを実行する方法。