Эволюция спецификаций: почему документ, созданный с помощью ИИ-агентов, требует постоянных правок
Анализ статьи разработчиков Anthropic подчеркивает, что спецификация программного обеспечения не является статичным планом, составленным один раз. В эпоху спецификационно-управляемой разработки (Spec Driven Development) с использованием ИИ-агентов документ должен рассматриваться как живой организм, который уточняется и «перерисовывается» по мере того, как агент исследует скрытые нюансы кодовой базы и открывает ранее неизвестные ограничения.
# Спецификация как путь, а не чертеж: урок от Anthropic о разработке с ИИ-агентами
В современном ландшафте разработки программного обеспечения концепция создания спецификаций трансформируется под влиянием искусственного интеллекта. Традиционный подход, при котором разработчик формулирует детальное описание требований до начала написания кода, сталкивается с фундаментальным парадоксом: невозможно предугадать всё, что возникнет в процессе реализации. Новый подход, описанный в материалах Anthropic, предлагает рассматривать спецификацию не как финальный документ, а как динамический процесс уточнения.
Центральная идея заключается в том, что использование ИИ-агентов, таких как специализированные инструменты для работы с кодом, позволяет выявить категории проблем, которые человек часто упускает из-за своей «слепой зоны» профессиональной компетенции.
Карта местности против реальной местности
В основе методологии лежит метафора: спецификация — это карта, а код и реальная логика бизнеса — это сама местность. Карту нельзя нарисовать, пройдя всю территорию один раз заранее, так как существуют территории, которые мы еще не открыли.
Агент, взаимодействующий с кодом, выполняет функцию разведчика. Он не просто следует инструкциям, но и исследует «землю». В ходе этого исследования выявляются различия между тем, что описано в документации, и тем, что реально существует в архитектуре проекта. Этот процесс требует итеративного подхода: черновик спецификации создается, агент его проверяет, а разработчик вносит правки на основе полученной информации.
Категории неизвестного
Разработчики выделяют четыре категории знаний, которые определяют сложность процесса:
1. Известное известное (Known Knowns): Ясные цели и намерения, которые разработчик осознает и готов сформулировать. Это отправная точка, грубый набросок карты. 2. Известное неизвестное (Known Unknowns): Проблемы, о которых разработчик знает, что не знает, но которые он пытается предусмотреть. Это то, что агент помогает выявить, задавая уточняющие вопросы. 3. Неизвестное известное (Unknown Knowns): Явные истины или ограничения, которые очевидны разработчику настолько, что он считает их аксиомой и не записывает в документацию. Однако для агента эти факты могут быть скрыты, и именно агент помогает их显显изировать. 4. Неизвестное неизвестное (Unknown Unknowns): Риски и ограничения, о которых разработчик и не подозревал. Методология предпологает, что агент, анализируя код и контекст, может обнаружить и эти скрытые проблемы.
Итеративный цикл уточнения
Процесс создания спецификации в условиях использования ИИ-агентов представляет собой цикл обратной связи. Начальный документ содержит лишь намерения. Затем агент изучает базу знаний и код, выявляя пробелы. На основе этих данных обновляется спецификация, а код пишется или дорабатывается уже с учетом более полной картины.
Этот цикл повторяется до тех пор, пока спецификация не совпадет с реальной логикой работы системы. Такой документ становится не просто инструкцией, а живым объяснением принятия решений: почему выбрана та или иная архитектура, какие граничные случаи были учтены и какие компромиссы были сделаны.
Инструментарий для совместной работы
Инструменты, подобные SpecBuddy, интегрируемые в среды разработки вроде JetBrains IDEs, облегчают этот процесс. Они позволяют взаимодействовать с агентом не только через чат, но и через прямой анализ кода и спецификаций. Это снижает когнитивную нагрузку на разработчика, позволяя сосредоточиться на логике, а не на формулировках.
Поддерживаемые инструменты включают OpenCode, Claude Code и Codex, что позволяет гибко адаптировать подход под различные стеки технологий.
Финальная спецификация как артефакт доверия
Завершение разработки должно привести к документу, который отражает итоговый результат работы. Такой документ ценен не только для текущего проекта, но и для будущих разработчиков, которые будут поддерживать систему через полгода или более. Он заменяет необходимость глубоко изучать исторические коммиты, предоставляя четкий и обоснованный ответ на вопрос «почему система работает именно так».
Создание спецификации с первого раза является невозможным по определению, так как это требует предсказания будущего. Однако регулярное обновление документа на основе фидбека от агентов превращает его в надежный актив проекта.
*Метод напоминает процесс исследования неизвестных континентов: мы не можем нарисовать карту до того, как ступим на землю, но чем больше мы исследуем, тем точнее она становится. В разработке с ИИ агент выступает в роли картографа, который показывает те земли, на которые мы даже не пожелали смотреть.*
Этот подход не отменяет важности планирования, но меняет отношение к документации: она перестает быть догмой и становится частью инженерного процесса, evolving вместе с продуктом.