От vibe coding к спецификации
2 сентября 2025 года GitHub выпустил открытый набор Spec Kit и объяснил, зачем он нужен. Vibe coding хорош для быстрых прототипов, а на серьёзных приложениях и в старом коде даёт куда менее надёжный результат. Работа в Spec Kit идёт в четыре этапа: описать, что строим и зачем, составить технический план, разбить его на маленькие проверяемые задачи и только потом писать код. Формулировка GitHub: источником правды перестаёт быть код и становится замысел (GitHub). Похожим путём идут Kiro от Amazon и Tessl.
Что должно быть в спецификации
В книге я показываю это на салоне маникюра, где клиенткам разрешили несколько телефонов. Приказ «добавь в таблицу второе поле и кнопку в форму» описывал два звена из семи, и остальные пять порвались. Замысел звучал бы иначе: клиентка может указать несколько номеров и отметить основной, напоминание уходит на основной, после переноса у старых клиенток телефоны на месте, выгрузка для бухгалтера открывается, все проверки зелёные (глава «Цель вместо инструкции»). Цепочку можно пройти в опыте «Семь звеньев одного телефона».
Кроме цели, в хорошем замысле есть пределы: чего нельзя делать даже ради победы и где агенту остановиться и доложить (там же). Пределы полезнее всего записывать как запреты (глава «Архитектура как система запретов»). Для этого есть файл AGENTS.md, который агент читает в начале каждой сессии; по данным agents.md, им пользуются больше 60 тысяч открытых проектов (там же).
Чего спецификация не решает
Бригитта Бёкелер из Thoughtworks в октябре 2025 года разобрала Kiro, Spec Kit и Tessl и честно описала, где они буксуют. Kiro превратил мелкую правку бага в четыре пользовательские истории с 16 критериями приёмки. От Spec Kit осталась гора markdown-файлов, и она написала, что лучше бы читала код. А агент, несмотря на все чек-листы, иногда пропускал инструкции и создавал заново классы, которые уже были в проекте (Martin Fowler).
Последнее меня не удивляет. Правило в текстовом файле это просьба, и в длинной сессии агент может о ней забыть (глава «Архитектура как система запретов»). Поэтому спецификация работает, когда её пункты превращаются в проверки, а тесты пишет или утверждает не тот агент, который пишет код (глава «Агент обманывает тест»). И план стоит прочитать до начала работы, пока агент ещё ничего не удалил (глава «Цель вместо инструкции»). Формулировать задачу так, чтобы её нельзя было понять двояко, учит первый модуль моего курса по вайб-кодингу.
