Внедрение Spec-Driven Development в существующие проекты

[flancer]

Spec Kit также генерирует дерево папок и файлов, показывающее, что будет создано, изменено или удалено. Этот уровень видимости помогает разработчикам немедленно понять полный объем предстоящих изменений.

Почему "немедленно"-то? Как можно "немедленно понять", что именно хранится в дереве папок и файлов? Это как войти в супермаркет и немедленно понять, где лежит всё, что тебе нужно купить для сегодняшнего ужина, хотя в этом супермаркете ты в первый раз.

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

Может просто дать возможность самим "архитекторам и старшим разработчикам" этот план сгенерировать? По мне, так это делегирование ответственности за сгенерённый нейронкой слоп.

Я согласен, что спецификации должны быть частью проекта, если в нём задействованы llm-агенты, но доверять агентам самим генерировать спецификации, которые ты сам не понимаешь? Это зло.

Проверка сгенерированных ИИ Markdown-файлов необходима, но когнитивно утомительна. В отличие от кода или документации, написанный ИИ текст выглядит грамматически правильным и вроде бы разумным, но требует постоянного тщательного изучения на предмет фактической и архитектурной точности.

Но вот чего мы не сказали: чтение текста, сгенерированного ИИ, ментально истощает.

Абсолютная правда! Я это как следует прочувствовал на этой статье.

[AppCrafter]

В целом интересно, видно что это практический опыт. Хотя и видна увлечённость авторов Spec Kit, который как по мне так немного запутан. Но многие моменты действительно имеют место.

Но вот это непонятно - "Итерируйте для исправления мелких отклонений: Перезапускайте ту же команду для регенерации частичных выходных данных при работе с проблемами ограниченного объема"

Что значит "перезапускайте ту же команду"? - Повторить тот же промт или что-то другое? И заодно как вам идея перепроверки на других моделях? Там вообще можно утонуть в деталях и нюансах.

[Bardakan]

Учитывая отклонения и проблемы с качеством выше, рабочий процесс меняется после первоначальной реализации. Агент выполнил механическую работу - структурированную, предсказуемую генерацию кода. Теперь вы берете на себя критическую работу - уточнение, качество и архитектурное выравнивание.

Именно здесь вы возвращаете контроль от ИИ. Ваша роль становится похожей на роль технического лида, проверяющего реализацию джуниор-разработчика: внимательно проверьте реализацию, определите, что требует исправления, затем используйте ИИ-инструменты (GitHub Copilot, Cursor, Claude code или аналогичные), чтобы помочь эффективно реализовать эти исправления.

Cursor периодически игнорирует даже те правила, которые по его документации учитывать просто обязан. Как он тогда будет исполнять требования вашего spec kit.

Интеллект модели напрямую влияет на соотношение 80/20. Обновление с Claude Sonnet 4.0 до 4.5 сократило наше время на переделки почти вдвое. Более умные модели сохраняют контекст на протяжении более длинных реализаций, лучше обнаруживают переиспользование кода, строже следуют правилам конституции и принимают более сильные архитектурные решения.

почему все пишут, как хорошо делегировать Claude все задачи (даже те, что не нужно было), но никто не говорит о стоимости затрат?

[Gorthauer87]

Вот не понимаю что там инновационного, обычный шаблон для md для написания спеки, который болт кладет на процессы внутри компании.

Лучше блин mcp сделать для того чтобы агент мог ходить нормально по внутренним ресурсам и пару инструкций чтобы он это делал. В первую очередь блин спеки и доку надо для людей писать.