最初のプロンプトから動作する成果物まで、Emergent SHを使う

「モダンなアプリを作って」といったリクエストでは、対象ユーザー、データモデル、ナビゲーション、成功条件が明示されていません。見た目は洗練されていても、間違った問題を解決している可能性があります。

回避策冒頭のブリーフで、1人のユーザー、1つの主要タスク、3つの必須フィールド、1つの成功シグナルを明記します。

説得力のある画面があっても、フォームが正しくバリデーションされること、状態が保持されること、エッジケースに対応できることの証明にはなりません。基盤となるユーザージャーニーの信頼性が確立する前に、表面上は完成しているように見えることがあります。

回避策現実的な値で主要なパスをテストし、その後、意図的に未入力、無効、極端に長い入力を試します。

決済、非公開データ、外部API、権限、本番デプロイには、生成されたドラフトだけでは見た目から安全に判断できない要件が含まれます。

回避策生成された成果物を出発点として使用し、各依存関係を文書化したうえで、関連する技術またはセキュリティの責任者に検証してもらいます。

小さな追加リクエストが積み重なると、余分な画面や競合するCTAが増え、最初のバージョンより説明しにくいプロダクトになることがあります。

回避策短い受け入れ条件リストを維持し、当初のユーザータスクを改善しない変更は受け入れません。