Я попробовал Spec Kit на 4 проектах. Вот когда он работает

За 5 недель прогнал Spec Kit на 4 проектах: сайт, бот, скрипт, рефакторинг. На двух выстрелил, на двух - нет. Делюсь когда заходит.

Я не разработчик. Я предприниматель, который собирает свои продукты через Claude Code: сайты, телеграм-боты, обвязка для рассылок и аналитика. Шесть месяцев у меня этим занимается один файл CLAUDE.md. Туда положил методологию, словарь, правила работы. Работает.

Когда в октябре 2025 GitHub выкатил Spec Kit, а Karpathy в феврале 2026 сказал, что «вайб-кодинг» как термин ему больше не подходит и он перешёл на «agentic engineering», я обратил внимание. По всем каналам понеслось: «теперь нормально», «спецификации вместо промптов», «это убьёт CLAUDE.md». 107 000 звёзд на GitHub за 8 месяцев. Сценарий простой: команда /specify, дальше /plan, /tasks, /implement.

Я взял 4 свои реальные задачи за май и прогнал их через Spec Kit. Получилось интересно: на двух Spec Kit сэкономил вечера, на двух я закрыл вкладку и вернулся к CLAUDE.md. Расскажу где он реально вытащил, где провалился, и как теперь делю работу между Spec Kit, CLAUDE.md и Plan Mode.

Spec Kit - это набор команд для Claude Code (и для Cursor, и для Copilot, но я гонял в Claude Code), которые разбивают работу над функцией на 4 фазы:

Главный сдвиг: спецификация теперь не подсказка для промпта, а основной артефакт проекта. Код становится её выражением. Та же логика, по которой в Linear задача важнее коммита, а в Notion документация важнее реализации.

Почему вокруг этой штуки шум именно сейчас. GitHub выложил репозиторий публично в октябре 2025 и с тех пор накопил 107 000 звёзд. В январе 2026 туда подвезли поддержку Claude Code, Cursor, Copilot и ещё нескольких сред. AWS опубликовали свой кейс - 95% бизнес-логики одного из их внутренних сервисов сгенерировано напрямую из спецификации, по их подсчётам это 80 часов работы инженера, которые не пришлось вкладывать. Rackspace в марте отчитались, что переписали свой биллинг с 52 недель в плане до 3 недель по факту. Karpathy в феврале 2026 написал в Twitter, что считает термин «вайб-кодинг» больше не подходящим под то, что он делает с моделью, и его новое слово - «agentic engineering». Сообщество приняло это как сигнал, что момент серьёзно поменялся.

Звучит красиво. Дальше - как это выглядит в реальной жизни.

Задача: одностраничный сайт под новый продукт. Hero, 4 секции, форма заявки, отправка на электронную почту. Раньше я бы дал CLAUDE.md проекту и попросил «собери сайт по схеме N, текст вот».

Со Spec Kit пошёл иначе. Открыл новый репозиторий, поставил uvx specify-cli init. В Claude Code первой командой написал:

Claude вернул spec.md на 90 строк со сценариями, с ограничениями, с открытыми вопросами: «какой сервер для приёма формы?», «нужны ли проверки на повторную отправку?». Я ответил на вопросы. Потом /plan - и получил такой же файл с архитектурой: Next.js 14, app router, поле формы валидируется на клиенте, серверный action отправляет письмо через Resend. Никаких «давай попробуем Drizzle и пройдёмся по PostgreSQL». Чисто под задачу.

/tasks дал 14 задач, от «создать структуру проекта» до «настроить отправку письма». Каждую subagent взял в работу, прокатился и закоммитил. Я не вмешивался 2 часа. Через 3 с половиной часа открыл результат - готовый сайт, текст под мою методологию, форма работает, письмо приходит.

Что Spec Kit сделал лучше длинного промпта:

После первого теста я понял: для нового изолированного проекта Spec Kit реально работает. Идём дальше.

Второй тест - небольшой телеграм-бот: пользователь нажимает /start, бот спрашивает почту, сохраняет в базу, проверяет оплату через CloudPayments, открывает доступ в группу. Тоже новый изолированный проект.

Тут Spec Kit окончательно меня купил. Я раньше делал такие боты ровно столько, сколько уходило на чтение документации aiogram и поиск примеров. В этот раз - те же 4 фазы. В спецификации проговорил все сценарии: «что если пользователь нажал старт второй раз», «что если оплата не прошла», «что если пользователь уже в группе». Это вытащило 4 сценария, которые я бы пропустил в обычном промпте.

/plan предложил aiogram 3 + Postgres + cron-задачу на проверку статуса оплаты. /tasks разбил на 22 задачи. На фазе /implement я первый раз попробовал режим, где subagent'ы работают параллельно: пока один пишет хендлер /start, второй настраивает cron для проверки оплаты. Сэкономил часа три на ровном месте.

Через 5 часов работы бот делал всё, что от него хотели. Я даже не открывал документацию aiogram - сценарии из spec.md сами стали проверками. Перед публикацией прогнал каждый сценарий руками, нашёл одну ошибку в обработке двойной оплаты, попросил subagent починить. На следующий день бот заработал в боевом режиме.

Главное наблюдение по второму тесту: Spec Kit заставляет тебя описать сценарии, а не реализацию. Это меняет всё. Ты больше не говоришь «сделай функцию X», ты говоришь «когда пользователь делает A, должно происходить B». Та же модель, по которой пишут acceptance criteria инженеры в больших проектах. Только теперь её получает вайб-кодер.

Дальше пошли провалы. Третий тест - скрипт на Python, который раз в день забирает данные из Яндекс.Метрики, телеграм-аналитики и базы оплат, складывает в один отчёт и кидает мне в почту. Задача звучала «простая»: один скрипт, 200 строк кода.

Открыл новый репозиторий, написал /specify. Claude сделал спецификацию на 70 строк - и тут начались проблемы. Спецификация описывала «как должен выглядеть отчёт», «какие поля», «какая частота». А я не мог сформулировать сценарии, потому что сам не знал, что именно хочу видеть в отчёте. Это был исследовательский скрипт - я писал его, чтобы понять, что важно.

В обычном вайб-кодинге я бы просто открыл Claude, написал «забери метрики за 7 дней, склей в таблицу, покажи мне» и дальше шёл от того, что увидел. Со Spec Kit это не работает. Спецификация требует, чтобы я уже знал ответ.

Попробовал упростить: сделал спецификацию на 10 строк («забрать метрики, склеить, отправить»). Claude в фазе Plan честно вернул мне «не хватает деталей» и задал 8 вопросов. На каждый я ответил «не знаю». Закрыл вкладку, открыл обычный Claude Code, через 40 минут скрипт работал.

Вывод по третьему: Spec Kit умирает, когда ты ещё не знаешь, что хочешь. В исследовательских задачах он только добавляет шум.

Четвёртый тест - рефакторинг живого CRUD-приложения, написанного 8 месяцев назад. 4 200 строк кода, 23 файла, своя структура. Задача - перевести с REST на серверные actions Next.js 14 и заодно убрать дубли в обработке форм.

Я подумал: ну, тут как раз нужна формальная спецификация, я знаю что хочу. Открыл, написал /specify с описанием «текущее состояние X, целевое состояние Y, что меняется». Claude вытащил spec.md на 120 строк. На /plan пошло хуже: Claude не видел структуру моего кода. Spec Kit не читает существующий проект в фазе Plan, он опирается только на спецификацию. Он предложил архитектуру «с нуля», как если бы мы писали приложение заново.

Я попробовал положить рядом контекст проекта - не помогло. Subagent на фазе Implement начал писать код «как должно быть», игнорируя то, что уже есть. После трёх неудачных задач я остановил процесс. Вернулся в Claude Code с правильно настроенным CLAUDE.md, прошёлся по файлам руками, рефакторинг занял два вечера.

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

После 5 недель и 4 проектов у меня получилась простая разделительная линия. Опишу через 6 признаков задачи:

Мой текущий разрез: примерно 30% задач я гоняю через Spec Kit (новые продукты, новые фичи в зрелых проектах), 70% - через CLAUDE.md и обычные команды в Claude Code. Если бы кто-то прислал мне эту разделительную линию три месяца назад, я сэкономил бы пару вечеров.

Отдельная история - граница между Spec Kit и Plan Mode внутри Claude Code. Plan Mode у меня включается на каждой второй задаче, потому что он быстрый и работает в любом проекте: написал, что хочешь, получил план, нажал «вперёд», поехали. Spec Kit заметно тяжелее: он создаёт папку с тремя файлами, требует прохождения 4 фаз, ведёт коммиты по задачам. Это окупается, когда задача большая и сценариев много. На задаче «переписать одну функцию» Plan Mode выиграет ровно потому, что не накладывает формальности. На задаче «собрать новый сервис с авторизацией, оплатой и интеграциями» Plan Mode проиграет, потому что не заставит тебя проговорить всё заранее.

Хорошее упражнение: возьми любую задачу из своего списка прямо сейчас, запиши её одной фразой и спроси себя - смогу ли я перечислить 5 разных сценариев на этой задаче? Если да, и сценарии не очевидны - бери Spec Kit. Если фраза умещается в одно действие («поменяй текст на главной», «допиши логи в эндпоинт») - бери Plan Mode или просто диалог.

База, по которой я работаю с CLAUDE.md, у меня лежит отдельно: Как настроить CLAUDE.md в 2026: шаблон и 6 правил. Там шаблон, по которому я начинал, и 6 правил, которые я выработал за полгода. Скорми Claude и адаптируй под свой проект.

Даже когда я не запускаю полный цикл /specify → /plan → /tasks → /implement, я взял из Spec Kit несколько привычек, которые перешли в обычный вайб-кодинг.

Первое: пишу «что НЕ нужно» перед «что нужно». В спецификации это отдельная секция. В обычном диалоге с Claude я теперь тоже сначала ограничиваю: «не делай авторизацию, не делай платежи, не пиши тесты». Это убирает половину ненужного кода и галлюцинаций про «давай добавим Redis».

Второе: проговариваю сценарии перед реализацией. Раньше я писал «сделай форму подписки». Теперь - «когда пользователь оставил почту первый раз - делаешь A, повторно - B, повторно с другим телефоном - C». Это спасает от багов на стыках, которые потом ловишь руками.

Третье: делю работу на задачи в чек-листе. Это не обязательно отдельная фаза. Я просто прошу Claude перед началом кода прислать список задач, проверяю его, ставлю галочки по ходу. Когда subagent закончил всё - сразу видно, что осталось.

Четвёртое: храню спецификации в репозитории. Папка .specify/specs/ есть теперь и в проектах, где я не запускаю полный цикл Spec Kit. Это бесплатный второй мозг под отдельные фичи: открыл папку, увидел что было задумано, что вышло, что не зашло.

И вот эта пятая привычка - самая интересная. Я перестал писать длинные промпты вообще. Теперь мой стандартный размер первого сообщения Claude - 3-5 предложений с разделом «что не нужно». Дальше я веду диалог короткими вопросами. Промпт-инжиниринг как отдельный навык в моей работе исчез. Вместо него - короткий диалог через спецификацию и сценарии.

Если ты до сих пор гоняешь Claude Code «одним длинным промптом» - попробуй пару вещей.

Кстати, я отдельно разбирал, как из Plan Mode выжимать максимум без полного перехода на Spec Kit: Plan Mode в Claude Code: пошаговая инструкция и 4 этапа. Скорми Claude и попробуй, занимает 20 минут.

Финальная мысль. Через 2-3 года, я думаю, мы перестанем называть это «Spec Kit» или «CLAUDE.md». Это просто будут разные режимы одного и того же инструмента, как branch в git. Сейчас мы в моменте, когда они выглядят как отдельные продукты, но под капотом одна и та же модель, одно и то же управление контекстом. Вопрос только в том, какую обёртку ты выбрал под конкретную задачу.

А ты Spec Kit уже пробовал? На каком проекте зашёл, на каком нет?