Spec-driven development: от идеи до архитектуры продукта с ИИ

Коротко (TL;DR)

Собрать прототип с ИИ за вечер и довести большой продукт до ума — две разные задачи. Первая прощает хаос, вторая на нём разваливается. Этот материал — про вторую: связный метод, который ведёт от сырой идеи через ресёрч и границы MVP к дисциплинированной архитектуре, с конкретными механизмами Claude Code на каждом шаге, а не абстрактным «сделайте спеку».

Что важно понять сразу:

• «Вайб-кодинг» большого проекта в одну сессию не масштабируется. Чем длиннее задача и чем больше файлов, тем сильнее агент теряет намерение и накапливает технический долг. Дисциплина здесь — не бюрократия, а способ не переписывать всё через месяц.
• Метод — это пять этапов: brainstorm → ресёрч рынка → границы MVP → выбор стека → спецификация и архитектура. Первые два делаются в обычном чате, кодового агента открываем позже.
• У Claude Code уже встроены инструменты под этот метод: режим планирования (Plan Mode), алиас opusplan (мощная модель на план, быстрая — на реализацию), сабагенты с изолированным контекстом и файл проекта CLAUDE.md.
• Риски реальны и измеримы: ИИ-код без плана и проверок статистически чаще содержит уязвимости. Метод снижает конкретные риски на конкретных шагах — об этом честно в конце.

Что понадобится: доступ к Claude Code (подписка или API), обычный веб-чат с моделью для первых этапов и готовность работать методично, а не одной сессией. Уровень — продвинутый. Термины вроде «спека» и «Plan Mode» разбираем по ходу, но предполагается, что вы уже пробовали писать код с ИИ.

Почему «просто вайб-кодить» ломается на масштабе

Короткий ответ: обычный вайб-кодинг оптимизирован под скорость получения работающего результата, а не под то, чтобы этот результат был правильным, поддерживаемым и безопасным. На прототипе за вечер это неважно — код можно выбросить. На продукте, который вы собираетесь развивать месяцами, накопленные срезанные углы превращаются в стену.

BYBIT EARNЗаставь крипту работатьПроценты на USDT и BTC без блокировки — деньги остаются под рукой.Разместить

Есть и данные. Академическое исследование рисков вайб-кодинга (arXiv 2509.12491, сентябрь 2025) по самоотчётам практиков фиксирует один и тот же набор проблем: технический долг, неподдерживаемый код, скрытые баги и небезопасные места, которые всплывают именно тогда, когда проект вырастает за рамки прототипа. Отдельная работа по безопасности сгенерированного кода (arXiv 2506.23034) показывает, что у большинства протестированных в ней моделей доля уязвимого кода — от 9,8% до 42,1% (конкретная цифра зависит от модели, бенчмарка и типа уязвимости), а в других исследованиях встречаются и более высокие значения. Вывод не «ИИ пишет плохой код», а «ИИ-код без плана и проверки нельзя считать готовым по умолчанию».

Монтаж видео кодом: пайплайн из Deepgram, FFmpeg и Remotion

Supabase и Stripe за вечер с Claude Code — и три вещи, которые агент сделает не так

Деплой на Vercel через GitHub: как выложить проект по шагам

AWS Continuum придёт в Claude Code и Codex: поиск дыр прямо в редакторе

OpenClaw на Claude отменил чужую бронь, чтобы поднять хозяина с 4-го места на 3-е

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

Этап 1 — Brainstorm: разгоняем идею до открытия кодового агента

Первая ошибка — сразу открыть Claude Code и начать «делать приложение». На этапе идеи технический агент вреден: он тянет вас в детали реализации, когда ещё не решено, что вообще строим.

Практика, которую советуют русскоязычные практики (например, разборы на bitrix24) и которая работает: brainstorm ведём в обычном чате с моделью, а не в кодовом агенте. Задача этапа — не код, а ясность. Хорошо работает роль «ИИ-скептик»: просите модель не соглашаться, а искать дыры — кому это нужно, чем уже решают эту проблему, где вы себя обманываете.

Ещё полезнее — не диалог, а структурированное интервью. Попросите ИИ провести вас по вопросам продакта: какую проблему решаем, для кого, какой сценарий использования главный, как поймём, что продукт нужен. Claude Code умеет вести такое интервью через уточняющие вопросы, но на этом этапе достаточно веб-чата. Итог этапа — короткий документ-концепция в Markdown, а не строчка кода.

Пример стартового промпта:

Ты — скептичный сооснователь. Я хочу сделать <идея>.
Не поддакивай. Задай мне по одному вопросу за раз про:
проблему, аудиторию, конкурентов, монетизацию и главный сценарий.
В конце собери из моих ответов концепцию на одну страницу в Markdown.

Этап 2 — Ресёрч рынка и конкурентов с ИИ

Прежде чем писать код, закройте четыре вещи: реальна ли проблема, кто аудитория, кто уже её решает и как продукт будет зарабатывать. ИИ здесь — ускоритель ресёрча, а не оракул: он быстро собирает ландшафт конкурентов и типовые решения, но каждую цифру и вывод проверяйте на первоисточнике.

BYBIT EARNЗаставь крипту работатьПроценты на USDT и BTC без блокировки — деньги остаются под рукой.Разместить

Сам вендор фактически подтверждает эту рамку. Anthropic выпустила «founder’s playbook» — описание жизненного цикла AI-native стартапа: Idea → MVP → Launch → Scale, где основатель работает «оркестратором» ИИ-инструментов. Это ровно тот путь, что мы разбираем, только сформулированный со стороны создателя модели.

Итог этапа — не «ИИ сказал, что рынок хороший», а список проверенных фактов: 2–3 прямых конкурента с их слабыми местами, ваша гипотеза отличия и один-два способа монетизации.

На этом же материале удобно собрать PRD (product requirements document) — короткий документ требований к продукту для людей. Как написать PRD с помощью ИИ: скормите модели концепцию и результаты ресёрча и попросите оформить их в структуру «проблема — аудитория — сценарии — функции первой версии — метрики успеха». Важно не путать PRD со спекой: PRD отвечает на вопрос «что и зачем строим» для человека, а спека (пятый этап) — «как именно агент это делает» для машины. PRD пишется один раз, спека живёт и меняется. Всё это ляжет в спеку на пятом этапе.

Этап 3 — MVP: очерчиваем границы и не ловим scope creep

MVP — это не «маленькая версия всего», а «минимум, который проверяет главную гипотезу». Две типовые ошибки, которые фиксируют практики (towardsdatascience и другие): scope creep (в MVP заползают функции «на будущее») и недостаток обратной связи (строим полгода, не показав никому).

Дисциплина простая: выпишите одну главную функцию, ради которой продукт существует, и всё остальное отправьте в список «потом». ИИ здесь удобен как безжалостный редактор скоупа — дайте ему концепцию и попросите вычеркнуть всё, что не обслуживает главную гипотезу, с обоснованием по каждому пункту.

Важно: именно на границах MVP определяется, будет ли следующий этап (архитектура) осмысленным. Размытый MVP → размытая спека → агент строит не то.

Этап 4 — Выбор стека для большого, а не одноразового проекта

Для прототипа стек неважен — что ИИ предложил, на том и собрали. Для продукта, который будете развивать, стек — это решение на месяцы вперёд: по нему считается наём, поддержка и то, насколько уверенно ИИ-агент в нём работает.

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

Этап 5 — От идеи к архитектуре: спецификация вместо догадок

Здесь метод переходит из продуктовой плоскости в инженерную. Ключевая идея — spec-driven development (SDD): сначала пишем спецификацию (что и как должно работать), а агент по ней генерирует план и код, сверяя результат с критериями. Спека становится контрактом, от которого агент не отклоняется без явного изменения контракта.

Чем спека отличается от PRD, который вы могли составить на этапе 2. PRD — документ для людей, его пишут раз и редко трогают. SDD-спека — живой документ для агента и CI, она обновляется по ходу. Подробный промпт — это ещё не спека: промпт разовый, спека — то, против чего сверяется каждый шаг.

Из чего состоит хорошая agent-спека. По анализу тысяч реальных конфигураций агентов на GitHub (исследование по 2500+ репозиториям) полезная спека покрывает шесть областей: команды (как собрать/запустить/протестировать), тестирование, структуру проекта, стиль кода, работу с git и границы — что агенту можно, что нельзя. Инструменты формализуют это по-разному: GitHub Spec Kit проводит через четыре гейтованные фазы (Specify → Plan → Tasks → Implement), а роль носителя спеки в Claude Code играет файл CLAUDE.md.

Отдельно про границы — самый недооценённый раздел. Вместо плоского списка запретов работает трёхуровневая система: что агенту разрешено всегда, что — только с подтверждением, и что — никогда. Самое частое правило в выборке — «никогда не коммить секреты». Такая градация читается агентом лучше сплошного списка «нельзя».

Важная оговорка: SDD оправдан не всегда. Для мелкой фичи или исследовательского прототипа, который вы собираетесь выбросить после проверки гипотезы, тяжёлая формальная спека — оверхед. Правило: задача целиком помещается в контекст агента и одноразовая — спека лишняя; продукт живёт и растёт — спека окупается.

Механика Claude Code для большого проекта

Теперь — конкретные инструменты, которые превращают метод из теории в рабочий процесс.

Официальный рабочий цикл: Explore → Plan → Implement → Commit. Сначала агент исследует код в режиме только-чтение, потом строит план (Plan Mode — агент не трогает файлы, пока вы не утвердили план), затем реализует и коммитит. Планирование до кода — это тот же принцип SDD, встроенный в инструмент.

Разделение моделей по этапам — алиас opusplan. Claude Code умеет ставить мощную модель (Opus) на планирование, а на реализацию автоматически переключаться на более быструю (Claude Sonnet 5). Это готовая техническая реализация ровно той идеи, которую метод советует делать вручную: думать дорого и тщательно, исполнять быстро и дёшево. Конкретные имена моделей меняются часто — сверяйте актуальную линейку в официальной документации по конфигурации моделей на момент работы.

CLAUDE.md — память проекта. Этот файл загружается в начале каждой сессии и держит контекст: как собрать проект, какие соглашения, какие границы. Правило — держать его коротким и по делу: раздутый CLAUDE.md сам съедает контекст.

Сабагенты — изолированный контекст под подзадачу. У сабагента своё окно контекста, свой системный промпт и свой набор инструментов. Это позволяет вынести тяжёлую подзадачу (ресёрч, ревью, миграцию) в отдельный «чистый» контекст и вернуть в основной только результат — так основная сессия не захламляется. Если хочется увидеть агентный паттерн в готовом продукте, показателен разбор личного ИИ-агента и его реальной себестоимости.

Управление контекстным окном. Anthropic называет эффект прямо — context rot: чем больше токенов в контексте, тем хуже модель их удерживает и тем ниже точность. Отсюда практика: не вести один бесконечный чат на весь проект, а работать фазами со свежим контекстом, передавая между ними короткий handoff-файл. Родственный эффект — «curse of instructions»: чем больше правил в одном промпте, тем хуже агент следует каждому, поэтому спеку декомпозируют на модули и фазы.

Адверсариальный ревью: генератор против критика

Один агент, который и пишет, и проверяет собственный код, — это конфликт интересов: у него цель «сдать». Работает разделение ролей. Anthropic в best practices советует запускать отдельного сабагента в чистом контексте, который проверяет diff против плана. Независимая инженерная практика (например, у Augment Code) формализует это как связку Coordinator / Implementor / Verifier — с противоположными целями «реализовать» и «найти брак».

Для одного разработчика это адаптируется просто: после того как основной агент реализовал фазу, откройте свежий контекст (или сабагента) с заданием «ты ревьюер, твоя задача — найти, где реализация расходится с планом и где дыры в безопасности». Разные цели ловят то, что один проход пропускает.

Вайб-кодинг за вечер vs дисциплинированный процесс

Метод не отменяет быстрый вайб-кодинг — у них разные задачи. Ориентир, когда что:

Правило выбора: чем дольше жить коду и чем выше цена ошибки, тем правее вы должны быть в этой таблице.

Риски и как метод их снижает

Дисциплина — не самоцель, а ответ на конкретные риски. Разбираем по каждому:

• Уязвимый код. ИИ-код статистически чаще содержит уязвимости (arXiv 2506.23034; конкретные доли зависят от модели и метода замера — не универсальная «средняя цифра»). Снижают: спека с явными границами безопасности и адверсариальный ревью diff’а.
• Технический долг и неподдерживаемость. Главная жалоба практиков (arXiv 2509.12491). Снижают: выбор зрелого стека, короткий CLAUDE.md, декомпозиция на фазы.
• Потеря намерения на длинной дистанции. Context rot и «curse of instructions». Снижают: работа фазами со свежим контекстом, спека как внешняя память вместо перегруженного окна.
• «Lethal trifecta» (формулировка Саймона Уиллисона, атрибутированное мнение): скорость + недетерминизм ИИ + экономия на верификации вместе дают опасную комбинацию. Снижает: не срезать проверку ради скорости на коммерческом продукте.
• Регуляторика. Для некоторых классов систем появляются обязательства (например, положения EU AI Act поэтапно вступают в силу; сверяйте актуальные сроки и применимость к вашему случаю на первоисточнике). Снижает: заранее заложить требования в спеку.

YMYL-вывод: ИИ радикально ускоряет путь от идеи до продукта, но «сгенерировано» не равно «готово». Метод из этой статьи — способ получить скорость ИИ, не заплатив за неё качеством и безопасностью.

Как выглядит один проход метода целиком

Соберём этапы в короткий сквозной пример — сервис, который превращает голосовые заметки в структурированные задачи.

1. Brainstorm (веб-чат). Роль «скептик»: «кому это нужно, если есть готовые заметочники?» Ответ на возражения даёт формулировку отличия — «фокус на извлечении задач, а не на хранении текста». Итог — концепция на страницу.
2. Ресёрч. ИИ собирает 3 конкурентов, вы сверяете их фичи и цены руками. Находка: у всех слабая обработка длинных записей. Это ваша гипотеза отличия. Оформляете PRD.
3. MVP. Главная гипотеза — «пользователь готов платить за точное извлечение задач». Всё, что не обслуживает её (теги, шаринг, мобильное приложение), уходит в «потом». В MVP остаётся: загрузка записи → транскрипт → список задач.
4. Стек. Зрелый и популярный: чтобы агент уверенно писал код и меньше «додумывал». Хостинг, база и оплата намечены заранее.
5. Спека и архитектура. Пишете спеку с шестью областями (команды, тесты, структура, стиль, git, границы) и трёхуровневыми границами. Открываете Claude Code, Plan Mode строит план по спеке, вы его утверждаете.
6. Реализация с разделением моделей. opusplan: Opus планирует, Sonnet пишет код по фазам. После каждой фазы — свежий контекст.
7. Ревью. Отдельный агент-критик проверяет diff против плана и ищет дыры в безопасности (тут — как хранится и передаётся аудио пользователя).

На выходе — не «прототип, который жалко развивать», а продукт с зафиксированным намерением, управляемым техдолгом и понятной архитектурой. Именно это отличает разработку MVP с Claude Code по методу от вайб-кодинга большого проекта наугад.

FAQ

С чего начать, если идея пока сырая? С обычного чата, не с Claude Code. Проведите brainstorm в роли «скептик», соберите концепцию на одну страницу, и только потом переходите к ресёрчу и коду. Кодовый агент на этапе идеи мешает — тянет в детали реализации.

Чем спека отличается от подробного промпта? Промпт — разовая инструкция. Спека — живой документ, против которого агент сверяет каждый шаг плана и по которому потом проверяется результат. Подробный промпт спеку не заменяет.

Обязательно ли писать спеку для каждого проекта? Нет. Для одноразового прототипа или мелкой фичи формальная спека — оверхед. Она окупается, когда продукт живёт и растёт. Критерий — помещается ли задача целиком в контекст агента и выбросите ли вы её после проверки.

Что даёт opusplan и зачем разделять модели? Планирование выигрывает от самой сильной модели, а рутинная реализация — нет. opusplan ставит Opus на план и переключается на Sonnet для кода: качество замысла при меньшей цене исполнения. Актуальные имена моделей сверяйте в документации — они часто меняются.

Как не дать агенту накопить технический долг на большом проекте? Три вещи: зрелый популярный стек, работа короткими фазами со свежим контекстом (против context rot) и отдельный агент-ревьюер, который проверяет каждую фазу против плана. Один агент, пишущий и проверяющий сам себя, — плохой контроль качества.

Можно ли доверить ИИ всю архитектуру? ИИ хорошо предлагает варианты и пишет спеку под вашим руководством, но финальные решения по границам, безопасности и стеку остаются за вами. Роль человека здесь — оркестратор, а не наблюдатель.