Spec Development (или Specification-Driven Development) в контексте разработки с помощью ИИ — это подход, при котором основным инструментом становится не написание промптов, а создание и поддержка подробных спецификаций (инструкций, требований и логических схем).
Проблема
В рамках вайб-кодинга мы привыкли делать свои проекты путем постоянного написания промптов, направляя ИИ-агента в нужную сторону; так шаг за шагом мы доводим проект или прототип до приемлемого уровня. Те, кто имеет большой опыт создания проектов с таким подходом, рано или поздно сталкивались с двумя серьезными проблемами:
- Галлюцинации ИИ-агента — когда агент начинает ломать старый код в момент написания нового.
- Сжигание токенов — когда ИИ-агент начинает при каждой итерации читать весь проект, тратя при этом существенно количество ресурсов.
Конечно, эти проблемы появляются у проектов, которые выходят за рамки лендинга или небольшого многостраничного сайта, но все мы рано или поздно сталкиваемся с ними.
Как это работает на практике
Spec development призван решить эти две проблемы следующим способом: мы выносим всю «голову» проекта в отдельную папку. Вместо того чтобы каждый раз объяснять агенту в чате, что мы строим CRM на Payload CMS with кастомными полями, мы фиксируем это в файлах спецификаций.
Тут важный нюанс: не стоит валить всё в один файл. Если засунуть в один .spec и логику авторизации, и стили кнопок, файл раздуется и сам начнет жрать контекст как не в себя. Правильный подход — модульность. У тебя должен быть «главный чертеж» и отдельные спецификации под конкретные модули: AUTH_LOGIC.md, UI_SYSTEM.md, DB_SCHEMA.md. Агент подключает их только тогда, когда реально лезет в эти части кода. Это и есть та самая экономия ресурсов и точность «хирургического вмешательства».
В чем разница между skills и spec development
С появлением claude code стали доступны skills и многие путают их со spec development, но это не одно и тоже, они выполняют разные функции.
- Skills — это «микро-навыки» агента: как он пишет код, как оформляет коммиты, умеет ли он в Tailwind или нет. Это инструменты ии-агента.
- Spec Development — это архитектурный план. Это то как ии-агент или их система должна работать в целом.
Если навыки — это умение забивать гвозди, то спек — это чертеж небоскреба. Современный ИИ уже достаточно круто «забивает гвозди», но все еще тупит, если не видит общей картины.
Твоя новая роль — Reviewer
С приходом Spec Dev работа сводится к минимуму. По минимуму пишешь код, одобряешь или отклоняешь то, что сделал агент, сверяя результат со своим же спеком. Если агент накосячил, то ты не исправляешь код за ним, ты правишь инструкцию (спек), чтобы в будущем эта ошибка не повторилась. Это превращает разработку в масштабируемый процесс.
Реальные примеры применения
Представь, что ты пилишь сложный виджет для стримеров с кучей интерактива.
- Сценарий «без спека»: Ты просишь добавить анимацию появления сейфа. ИИ добавляет её, но случайно переписывает логику проверки 10-значного кода, потому что «забыл», как она работала три итерации назад.
- Сценарий «Spec Dev»: У тебя есть файл widget-logic.md. ИИ видит жесткое правило, добавляет анимацию, сверяется с правилом валидации, и проект остается целым.
Пример для дизайнеров: поддержка дизайн-системы. Ты фиксируешь в спеке формулы clamp() для типографики и сетки. Теперь, какой бы агент ни пришел в проект, он не сможет «накостылить» фиксированные пиксели, потому что спек для него — это закон.
Как создавать спеки
Изначально может показаться что это что-то заумное, но на самом деле для простых проектов, написание спеки проекта это тоже самое что написать инструкцию для стажера: просто открываешь текстовый файл и человеческим языком фиксируешь в нем правила игры. Сначала задаешь контекст (на каком стеке работаем), потом устанавливаешь что ИИ делать категорически запрещено, например, менять шрифты или удалять комментарии, и по пунктам расписываешь все остальное, желательно разбивая все по логическим файлам UI, валидация, анимация, микротранзакции. В итоге у тебя формируется солидный список файлов, которые ты редактируешь время от времени, когда возникают ошибки, и работа над проектом становится все более легкой и автоматизированной.
Перспективы и стоит ли учить
Тренд на «спеки» пошел не из пустоты. Гиганты вроде Amazon уже вовсю двигают тему KIRO (Knowledge-Intensive Reasoning & Orchestration), которая сейчас переросла в индустриальный стандарт MCP (Model Context Protocol). Это протоколы, которые позволяют ИИ-агентам динамически «понимать», где лежат знания о проекте и как ими пользоваться.
В обозримом будущем я вижу, что спеки будут встроенными, и если основная часть ваших проектов - сайты, интернет-магазины, простые приложения, то сильно углублятся в spec development нет никакого смысла, потому что из собственной практики я наблюдаю, как большие продукты уже встраивают «спеки» под капот:
- Payload CMS и Strapi стали поставлять готовые схемы и типы, которые ИИ-агенты (например, в Cursor, Antigravity через .cursorrules .antigravityrules) читают мгновенно. Тебе не нужно объяснять, как работает коллекция в Payload, или как сгенерить админку, агенту уже доступна актуальная спека фреймворка.
- Для Next.js доступны готовые схемы под разные типы проектов, которые предоставляет агенту все необходимые правила для корректной работы.
- Собственно KIRO - сам генерирует спеки подстраиваясь под твой стек. Единственный минус - это работа с внешними API ИИ для кодинга, которые довольно прожорливые в отрыве от их нативной подписки.
Вывод
Spec Development — это логичный этап взросления всей этой ИИ-движухи. Вайб-кодинг хорош для фана и пет-проектов на один вечер, но если ты строишь что-то серьезное, на чем планируешь зарабатывать — без спеков не обойтись.
Главное правило: Твой спек должен лежать в Git вместе с кодом. Изменилась логика — обновился файл спецификации. Это переход от хаоса промптов к дисциплине архитектуры. И, честно говоря, это именно то, что делает разработку снова предсказуемой и кайфовой, избавляя нас от роли «няньки» для ИИ. Ты больше не просишь ИИ «сделать красиво», ты задаешь законы, по которым работает твоя личная цифровая вселенная.