Ну что, аналитики, настало ваше время! Самый модный способ разработки программ с помощью ИИ сейчас — SDD, spec-driven development. Человек пишет требования и спецификации, ИИ пишет по ним код. Программисты не нужны.

Вот сейчас мы и посмотрим — насколько важная роль разработчика и что он вообще делает, и насколько точно аналитики могут формулировать требования и задачи.

Идея похожа на подход "documentation first", знакомый нам по API. Как конкретно код написан — уже не очень важно, пока он соответствует спецификациям. И меняется в ходе проекта в первую очередь спецификация, она становится ключевым артефактом. А как все смеялись над российским подходом с обязательными аналитиками и постановками на каждом проекте!

Инструменты SDD уже выкатил GitHub: Spec Kit, есть отдельные проекты — Tessl.io и Kiro. Недавно на сайте Мартина Фаулера вышла обзорная статья, кратко перескажу её здесь.

Три основные идеи SDD:

1. Spec-first: сначала пишется (ну или генерируется) спецификация. Код генерируется только по этой спецификации.
2. Spec-anchored: спецификация сохраняется надолго. Если в дальнейшем понадобятся изменения — меняется спецификация, а не код. Изменения в коде следуют за изменениями в спецификации.
3. Spec-as-source: спецификация — главный артефакт, и только над ней работает человек. К коду человек не прикасается.

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

Работает примерно так:

Kiro предлагает цепочку Requirements → Design → Tasks (Требования → Проект → Задачи).
Требования записываются в виде юзер-сторей с критериями приемки в формате BDD-сценариев (Дано... Когда... Тогда...).
Проект представляет собой описание устройства будущей системы:
Архитектура:
Компоненты архитектуры
Потоки данных
Компоненты и интерфейсы
Модели данных и т.д.

Задачи — это как в таск-трекере. Создай функцию такую-то, напиши набор тестов, добавь функцию фильтрации и т.п. Каждая задача имеет ссылку на требование.

У Spec Kit всё примерно так же, но перед требованиями есть ещё общий документ "Constitution" (Конституция), это что-то вроде системного промпта, где перечислены главные правила, вроде "Никакого кода без заранее написанных юнит-тестов" и "Обязательная модульность: каждая фича реализуется как отдельно стоящая библиотека".

В промптах используется очень много чеклистов для проверки каждого шага (правда, проверяет их сам же ИИ).

Tessl пока выглядит, как база спецификаций для агентов, создающих других агентов. Там некая смесь задач и инструкций по генерации, это уже совсем близко к коду.

Теперь о проблемах. В статье есть и описание попыток что-то сделать в логике SDD, и основной вывод — непонятно, для какого кейса применим этот подход. В туториалах, если они есть, показано создание небольшого проекта с нуля (greenfield). Но именно что небольших. При попытке исправить небольшой баг в существующем проекте (brownfield) быстро выяснилось, что нужно написать 4 разных юзер-стори и проверить 16 приемочных сценариев. Причем в одном из случаев ИИ неплохо разобрался с кодовой базой, но когда дошло дело до самостоятельного написания — принялся дублировать уже существующие классы...

В общем, пока возникает множество вопросов. Удобнее ли проверять спеки, тест-кейсы и задачи, чем проверять код? В какой момент нужно переходить от проработки спецификации к написанию (или исправлению) кода? Какие вообще есть кейсы: написание системы с нуля, доработки, исправления багов, рефакторинг — и в каких случаях SDD оправдано, а когда скорее вредит?

Поминается MDD, который так и не взлетел. А я думаю, вопросы-то совсем концептуальные — могут ли в принципе существовать спецификации отдельно от кода? Есть ли граница между проработкой требований и проектированием? Что составляет суть работы программиста, если спецификации и модели уже готовы? Кажется, тут есть что-то, чего мы не очень улавливаем, и всё время думаем, что это автоматическая перекладка требований в код. Возможно, глядя в зеркало ИИ, мы лучше поймем свою собственную деятельность.