Когда использовать
Есть идея продукта, нужно решить «на чём и как строить», прежде чем писать первую строку — на уровне продукта, а не отдельной фичи. Роль ИИ — техлид/архитектор, который думает reuse-first и считает trade-offs. Результат: внятная архитектура MVP, по которой можно оценить сроки и начать (или отдать spec-driven ТЗ агенту-кодеру).
Промт (бери и вставляй)
Ты — техлид/архитектор. Спроектируй архитектуру MVP по идее. Рассуждай по шагам, считай trade-offs.
ПРОДУКТ: «<ВСТАВЬ, что за сервис и кому>»
КЛЮЧЕВЫЕ ФИЧИ MVP: <2–4 главные функции>
ОГРАНИЧЕНИЯ: <команда/сроки/бюджет; знакомый стек; нагрузка, если известна>
Выдай:
1. Стек: фронт/бэк/БД/хостинг — с КОРОТКИМ обоснованием выбора и где уместно «скучный надёжный» вместо модного. Reuse-first: бери готовое, не изобретай.
2. Схема данных: основные сущности, поля, связи (как список таблиц/моделей). Помечай ключи и важные индексы.
3. Компоненты системы и потоки: что с чем общается (клиент ↔ API ↔ БД ↔ внешние сервисы), без переусложнения.
4. Главные риски и узкие места MVP + как их снять дёшево на старте.
5. Что НЕ делать в MVP (явный список over-engineering, который соблазнительно начать).
6. Этапы запуска: 3–4 вехи от «каркас» до «первые пользователи», по каждой — что готово.
Где данных не хватает — задай разумное допущение, пометь [допущение]. Один рекомендованный путь, не «зависит от».
Приём: пошаговое рассуждение над trade-offs + «что НЕ делать в MVP» удерживают модель от красивой, но неподъёмной архитектуры. Архитектура и схема данных — первичный артефакт, из которого выводится код.
Пример заполнения
Продукт: «сервис записи к частным мастерам (барбер, мастер маникюра): онлайн-слоты + напоминания». Фичи MVP: каталог мастеров, бронь слота, SMS/email-напоминание. Ограничения: соло-разработчик, знаю TS/React/Node, бюджет минимальный.
Ожидаемый ответ ИИ: стек Next.js + Node + PostgreSQL + managed-хостинг (обоснование: один язык, быстрый деплой, «скучно и надёжно»); сущности master, service, slot, booking, client с ключами/индексом по времени слота; поток клиент → API → БД, напоминания через очередь + внешний провайдер SMS; риск — двойная бронь одного слота → решается уникальным ограничением в БД; «не делать» — микросервисы, своя auth, мобильное приложение; этапы: каркас+БД → бронь работает → напоминания → первые мастера.
Вариации
- Несколько вариантов. «Дай 2 варианта стека (монолит vs serverless) с плюсами/минусами и порекомендуй один под мои ограничения».
- ADR. «Оформи 3 ключевых решения как короткие Architecture Decision Records: контекст → решение → последствия».
- Мост к коду. «На основе этой схемы данных дай DDL для PostgreSQL» или «сгенерируй spec-driven ТЗ на фичу брони».
Про-советы
- Самый ценный раздел — «что НЕ делать в MVP». Если ИИ его размывает, требуйте явный список соблазнов over-engineering.
- Гоните «reuse-first»: для типовых задач (auth, платежи, очереди) готовое решение почти всегда лучше своего — просите называть конкретные.
- Архитектуру от ИИ читайте как черновик сильного коллеги: trade-offs проверяйте под СВОИ ограничения, а не принимайте «модный» стек на веру.