В сообществе GitHub разгорелась жаркая дискуссия вокруг Spec-kit — инструмента для спецификации AI-разработки. Пользователь под ником sholtomaud поднял фундаментальные вопросы, которые резонируют с опытом многих вайбкодеров: почему мы тратим на написание промптов и спецификаций больше времени и денег, чем на сам код?
Главные боли Spec-driven подхода
Основная претензия заключается в том, что даже идеально описанное приложение на выходе может иметь «мусорную» реализацию. Автор отмечает несколько критических проблем:
- Галлюцинации в базе: AI может использовать устаревшие методы JS, даже если в спецификации это не запрещено. Разработчик не должен прописывать очевидные вещи вроде «не используй deprecated методы».
- Разрыв между ТЗ и отладкой: Нет четкого воркфлоу — если в коде баг, нужно ли править код или переписывать спецификацию? Постоянный рефакторинг спеков превращается в кошмар.
- Экономическая нецелесообразность: Существует порог, за которым время, потраченное на уточнение спецификаций, не окупается качеством кода. «Если я могу получить лучший результат от LLM без Spec-kit и дешевле — у нас проблемы», — пишет автор.
- Проблема «Идеальное ТЗ — ноль MVP»: Риск застрять на этапе проектирования, так и не выпустив работающий продукт.
От SRE к SpecRE
В ходе дискуссии родился новый термин — Spec Reliability Engineering (SpecRE). По аналогии с классическим SRE, нам нужны метрики надежности спецификаций. Автор предлагает пересмотреть отношения с провайдерами AI-агентов, перейдя от модели «оплата за токены» к модели «разделение рисков» (pain share/gain share). Если агент ошибается и выходит за рамки бюджета, провайдер должен нести финансовую ответственность.
Вердикт вайбкодера
Самое интересное произошло в финале обсуждения. Спустя время автор признался, что полностью забросил Spec-kit.
«На данный момент всё слишком изменчиво. Проблема с недетерминированными облачными LLM в том, что то, что хорошо работало вчера, не обязательно сработает сегодня».
Для нас, как для пользователей Cursor, Windsurf и других агентов, это важный сигнал. Пока инструменты спецификации не научатся самообучаться на разрыве между «как описано» и «как реализовано», избыточное проектирование может только тормозить процесс.
Контекст для VibeCoderz: Если вы строите продукт в одиночку, не пытайтесь создать «идеальную документацию» внутри Spec-kit. На данном этапе развития AI итеративный подход и прямой контроль кода агентом (как это сделано в Cursor) показывают себя эффективнее, чем попытки навязать жесткую структуру через внешние фреймворки спецификаций.
