Почему спецификация не пишется с первого раза: опыт Anthropic с Fable и уроки для Spec-Driven Development
Идеальная спецификация с первой попытки — это миф. Даже с мощными AI-агентами, такими как Fable от Anthropic, процесс создания требований требует итераций и уточнений. К такому выводу пришёл инженер Thariq Shihipar, делясь опытом работы над внутренним инструментом. Его наблюдения напрямую касаются м

Идеальная спецификация с первой попытки — это миф. Даже с мощными AI-агентами, такими как Fable от Anthropic, процесс создания требований требует итераций и уточнений. К такому выводу пришёл инженер Thariq Shihipar, делясь опытом работы над внутренним инструментом. Его наблюдения напрямую касаются методологии Spec-Driven Development (SDD), которая набирает популярность в AI-assisted разработке. В этой статье разберём, почему спецификации — это живой процесс, а не статичный документ, и как Fable помогает выявлять скрытые пробелы в требованиях.
Как Fable помогает находить «Неизвестные Неизвестные»
Thariq Shihipar работает над внутренним инструментом Fable, который представляет собой AI-агента, способного генерировать спецификации и код на их основе. Однако ключевая проблема, с которой столкнулась команда, — это так называемые «Неизвестные Неизвестные» (Unknown Unknowns): пробелы в требованиях, о которых разработчики даже не подозревают. Fable, анализируя код и контекст, помогает выявить эти скрытые неопределённости, предлагая уточняющие вопросы или альтернативные сценарии.
Например, при создании спецификации для модуля обработки платежей Fable может запросить детали о поддержке валют, обработке ошибок или сценариях возврата средств, которые изначально не были учтены. Это напоминает работу опытного архитектора, который задаёт правильные вопросы до того, как будет написана первая строка кода. Такой подход позволяет снизить количество переделок на поздних этапах и повысить качество конечного продукта.
Предыстория и контекст: почему спецификации — это процесс, а не документ
Идея Spec-Driven Development (SDD) заключается в том, чтобы сначала написать формальную спецификацию, а затем генерировать код, соответствующий ей. На первый взгляд это звучит как идеальный подход, особенно в эпоху AI-ассистентов. Однако практика показывает, что спецификация, созданная без обратной связи от кода, почти всегда содержит ошибки, неполноту или логические противоречия.
История разработки программного обеспечения знает множество примеров, когда «водопадные» спецификации приводили к провалам проектов. Agile-методологии частично решили эту проблему, сделав требования гибкими. Теперь, с появлением AI-агентов, способных не только писать код, но и анализировать спецификации, мы получаем новый инструмент для итеративного уточнения требований.
Почему нельзя написать идеальную спецификацию с первого раза?
Главная причина — в фундаментальной неполноте любого формального описания сложной системы. Даже если вы используете формальные методы, такие как TLA+ или Alloy, всегда остаются аспекты, которые можно понять только в процессе реализации. Например, детали интеграции с существующими сервисами, неожиданные краевые случаи или требования к производительности, которые становятся очевидными только при тестировании.
Fable, по словам Shihipar, не претендует на роль «волшебной палочки», которая создаёт идеальную спецификацию. Вместо этого он предлагает диалоговый режим: агент задаёт вопросы, предлагает варианты и уточняет требования, пока спецификация не станет достаточно полной для генерации кода. Этот процесс может занять несколько итераций, но в итоге документ получается более качественным.
Технические подробности: как устроен Fable
Fable — это не просто генератор спецификаций, а полноценный AI-агент, построенный на базе языковых моделей Anthropic. Он использует технику «цепочки мыслей» (chain-of-thought) для анализа неявных требований. В своей статье Shihipar описывает, как агент разбивает задачу на подзадачи, ищет зависимости и проверяет согласованность спецификации с существующей кодовой базой.
Один из ключевых приёмов — активное использование вопросов. Fable не просто генерирует текст, а задаёт уточняющие вопросы разработчику, подобно тому, как это делал бы опытный системный аналитик. Например: «Вы упомянули поддержку нескольких валют, но не указали, как обрабатывать курсы обмена. Использовать внешний API или фиксированные курсы?». Такой подход позволяет выявить «Неизвестные Неизвестные» на ранней стадии.
Кого затронет и как
Для разработчиков, практикующих Spec-Driven Development, опыт Anthropic означает, что нужно пересмотреть ожидания: AI-агент не заменяет итеративное уточнение, а лишь ускоряет его. Вместо того чтобы тратить недели на создание «идеальной» спецификации, команды могут быстрее переходить к коду, используя агента для выявления проблем.
Для бизнеса это снижает риски: более качественная спецификация означает меньше переделок на поздних этапах. В российском контексте, где многие компании уже внедряют AI-ассистентов, методология Spec-Driven Development с агентами типа Fable может стать стандартом для сложных проектов, особенно в финтехе и логистике.
Что будет дальше
Anthropic продолжает развивать Fable, и, вероятно, мы увидим интеграцию подобных агентов в популярные IDE и платформы управления проектами. Ожидается, что в ближайшие год-два Spec-Driven Development станет мейнстримом, особенно в сочетании с AI-агентами, способными не только писать код, но и вести диалог о требованиях.
Сам Shihipar отмечает, что будущее — за симбиозом человека и AI, где человек остаётся ответственным за стратегические решения, а AI берёт на себя рутину выявления неопределённостей и проверки согласованности.
Итог
Спецификация — это не документ, а процесс. Опыт Anthropic с Fable наглядно демонстрирует, что даже самые продвинутые AI-агенты не могут создать идеальную спецификацию с первого раза. Однако они могут сделать этот процесс намного быстрее и качественнее, помогая разработчикам обнаруживать «Неизвестные Неизвестные» до того, как они приведут к ошибкам в коде. Следите за развитием Spec-Driven Development — эта методология может изменить то, как мы пишем софт.