Итоги и практика

Ключевые выводы

• Спецификация шла первой и была короткой — абзац, назвавший важные ограничения, включая ограничения рабочего процесса, которые никогда не видны в работающем приложении.
• Секреты ни разу не попадали в репозиторий; каждый проект читал ключи из переменных окружения или зашифрованной конфигурации, заданной в дашборде.
• Стек выбирали так, чтобы было меньше шансов ошибиться — управляемая аутентификация, управляемая база данных, статический хостинг, serverless-функции.
• Препятствия решались тем, что AI скармливали точные улики — буквальную ошибку, реальный код, конфиг деплоя — и узко ограничивали правки.
• Запуск означал реальную проверку на реальности, а не «оно скомпилировалось»: живая покупка, второй аккаунт, глубокая ссылка на развёрнутом сайте.

Попробуй сам

Возьми одну из своих идей и напиши её спецификацию в один абзац так, как сделали эти четверо: назови основное действие, данные, которые видит каждый пользователь, и хотя бы одно ограничение рабочего процесса (как контент публикуется, кто что может делать). Затем перечисли управляемые строительные блоки, на которые ты обопрёшься, чтобы было меньше кастомного кода, способного сломаться. Уложись в один абзац плюс короткий список — если он разрастается, ты переспецифицируешь.

Промпт главы

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.