Spec-driven development: воспроизведение проекта только по спецификациям
Может ли AI клонировать проект по спецификациям?
Эксперимент: Claude Code воспроизвёл Go-проект за 20 минут, имея только спецификации. Без исходного кода. Результат - 85.5% успеха и 23 мутации, три из которых критические.
Что я сделал
Взял свой проект archlint - инструмент для анализа архитектуры Go-проектов. Подготовил 10 детальных спецификаций в формате Markdown + PlantUML. Всего 73 килобайта текста.
Спеки покрывали:
- Инициализацию модуля и Makefile
- Модель данных
- Go-анализатор
- CLI на Cobra
- Команды collect и trace
- Tracer-библиотеку
- Кастомный линтер tracelint
- Интеграционные тесты
Дал Claude Code эти спецификации и пустую директорию. Задача - реализовать проект с нуля.
Результаты
Время: ~20 минут от пустой директории до работающего проекта.
Структурная идентичность: 100%
Структура директорий идентична. Все 13 Go-файлов на своих местах: cmd/, internal/, pkg/, tests/.
Успешность клонирования: 85.5%
Ядро функциональности сохранено. Проект компилируется и работает.
Семантическая эквивалентность: ~75%
А вот тут начинается интересное.
Размер кода: минус 14.5%
Клон получился короче оригинала - 1845 строк Go против 2159. Те же файлы, меньше кода.
23 мутации: где AI отклонился от оригинала
Цифры красивые. Но дьявол в деталях.
3 критические мутации - изменения поведения
Первая: алгоритм построения sequence-диаграмм. AI переинтерпретировал логику формирования вызовов. Другая работа со стеком вызовов, другие условия записи.
Вторая: валидация в tracelint. Клон считает допустимым deprecated-вызов Exit(), тогда как оригинал его отвергает.
Третья: структура GoAnalyzer. AI добавил поля baseDir и modulePath, которых не было в оригинале. Спецификация не фиксировала границу ответственности анализатора - что хранить внутри, что вычислять снаружи. AI решил улучшить модель.
Все три критические мутации произошли в одних и тех же местах - там, где спецификация допускала неоднозначность.
8 средних мутаций - влияют на вывод и логи
Упрощённая инструментация трейсера. Рефакторинг имён методов. Другое форматирование вывода.
12 минорных мутаций - косметика
Комментарии на английском вместо русского. Именование переменных. Версии зависимостей.
Почему это важно
Spec-driven development работает. Но работает ровно до тех пор, пока спецификации закрывают поведение однозначно.
Критические отклонения возникают там, где спецификация описывает что должно быть, но не фиксирует как это проверять.
Для таких мест нужны:
- Точные правила и инварианты
- Примеры вход/выход
- Golden-тесты - сравнение результата побайтно или по структуре
- Явный запрет на расширение модели без указания в спеках
AI не просто реализует. Он интерпретирует. Любая зона интерпретации превращается в источник расхождений.
Практические выводы
Для алгоритмов
Включайте псевдокод, не только описания. Давайте конкретные примеры входных и выходных данных. Добавляйте golden-тесты.
Для моделей данных
Явно определяйте границы. Указывайте что НЕ нужно добавлять. Фиксируйте структуру.
Для валидации
Перечисляйте точные критерии приёмки. Включайте edge cases. Указывайте тексты ошибок дословно.
Итог
AI может клонировать проект по спекам быстро. 20 минут - и 85.5% проекта воспроизведено точно.
Остальные 14.5% - там, где я недосказал. В этих точках AI не воспроизвёл поведение, а выбрал собственную трактовку и встроил улучшения.
Иногда это помогает. В критических местах - почти всегда вредно.
Качество спецификаций напрямую определяет точность воспроизведения. Хочешь идентичное поведение - не оставляй места для интерпретации.
Ссылки
Репозиторий клона: github.com/mshogin/archlint-reproduction
Оригинальный проект: github.com/mshogin/archlint
Telegram: t.me/MikeShogin