まとめと練習

重要なポイント

• 仕様が先で、しかも短かった — 動いているアプリには決して現れないワークフロー制約を含め、重要な制約を挙げた一段落だった。
• シークレットはリポジトリに触れなかった。どのプロジェクトも環境変数か、ダッシュボードで設定した暗号化済み設定からキーを読んだ。
• スタックは間違えにくいように選ばれた — マネージド認証、マネージドデータベース、静的ホスティング、サーバーレス関数。
• 障害はAIに正確な証拠を与えて解決した — 実際のエラー、実際のコード、デプロイ設定 — そして修正範囲を狭く絞った。
• 出荷は「コンパイルできた」ではなく、現実に対する本物のテストを意味した: 実際の購入、2つ目のアカウント、デプロイ済みサイトのディープリンク。

試してみよう

自分のアイデアを一つ選び、この4例のように一段落の仕様を書こう: 中心となる動作、各ユーザーが見られるデータ、そして少なくとも一つのワークフロー制約(コンテンツがどう公開されるか、誰が何をできるか)を挙げる。次に、壊れるカスタムコードを減らすために頼るマネージドの構成部品を列挙する。一段落と短い箇条書き程度にとどめよう — それを超えて膨らんだら、過剰に仕様化している。

この章のプロンプト

I want to build: [one-paragraph description of the app].
Before any code, help me tighten this into a buildable spec.
1. Restate the single core action a user performs.
2. List the data each user can see — and what they must NOT see.
3. Name the workflow constraints that won't show up in the UI
   (e.g. "pushing a file should publish it", "only their own data").
4. Recommend a stack that MINIMIZES custom code: managed auth,
   managed database, static or serverless hosting where possible.
5. Flag the one part most likely to go wrong, and how we'll test it
   against reality (a real purchase, a second account, a deep link).
Keep the spec to a paragraph plus bullets. Push back if it's too big.