Что общего у этих четырёх

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

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