AI спецификации пишутся не до, а вместе с кодом: метод Anthropic в четыре шага

Тариг Шихипар из Anthropic опубликовал в корпоративном блоге статью о том, как ИИ-агент помогает находить так называемые «неизвестные неизвестные», то есть пробелы, о которых автор задачи даже не подозревает. Идея легла в основу подхода Spec Driven Development, где ai спецификации создаются не до, а вместе с кодом. Русскоязычное сообщество разработчиков активно обсуждает метод, потому что он решает знакомую боль: агент получает неполное задание и начинает «галлюцинировать» (уверенно выдумывать то, чего не было), заполняя пробелы догадками.

Четыре слоя незнания: почему первый черновик всегда неполон

Шихипар использует метафору карты и местности. Ваша постановка задачи для агента, это карта. Разница между картой и реальным маршрутом состоит из неизвестностей, и каждая неизвестность, это точка, где агент вынужден угадывать.

Неизвестности делятся на четыре типа:

• Известное известное (known knowns): то, что вы уже можете сформулировать. Ваше намерение.
• Известное неизвестное (known unknowns): то, чего вы пока не поняли, но знаете, что не поняли.
• Неизвестное известное (unknown knowns): то, что для вас настолько очевидно, что вы никогда не стали бы это записывать.
• Неизвестное неизвестное (unknown unknowns): то, о чём вы вообще не задумывались.

Спецификация или промпт (текстовая инструкция для модели), написанные за один присест, вмещают только первую категорию. Остальные три живут не в вашей голове. Они «живут на местности», и местность, по которой вы не прошли, нанести на карту нельзя.

Как устроен цикл уточнения?

Процесс строится не линейно, а итерациями. Каждая итерация, это проход «написал, запустил, увидел новое, перерисовал карту».

Шаг первый: набросок намерения. Вы фиксируете, что хотите получить и примерно как этого достичь. Это грубый черновик, достаточный, чтобы задать направление, но недостаточный, чтобы по нему строить.

Шаг второй: разведка агентом. Прежде чем писать код, агент изучает контекст. Он проходит по вашему коду, читает базу знаний, если она подключена через MCP (Model Context Protocol, протокол, который позволяет агенту обращаться к вашим данным) или иным способом. Агент вытаскивает наружу то, что вы упустили: детали, которые вам очевидны, и ограничения, которые вы не видели. Агент задаёт вопросы, ответить на которые вы сами не догадались, и карта обрастает деталями ещё до того, как маршрут построен.

Шаг третий: план и первый проход. С учётом новых обстоятельств вы вместе с агентом создаёте план. Запускаете его по шагу за раз или целиком. Именно здесь раскрывается настоящая местность: граничные случаи, ограничения, решения, которые противоречат исходной спецификации.

Шаг четвёртый: перерисовка карты. Граничный случай уходит в спецификацию. Решение записывается. Карта догоняет реальность, и следующий шаг стартует с более точной картины, чем предыдущий. Этот цикл повторяется многократно. С первого раза ai спецификации не могут быть верными, потому что на первом заходе вы ещё никуда не ходили.

Что понадобится

• ИИ-агент с доступом к кодовой базе (Claude Code, OpenCode, Codex или аналог).
• Текстовый редактор для спецификации. Подойдёт любой, от Google Docs до Markdown-файла в репозитории.
• Подключение базы знаний к агенту через MCP или встроенные средства IDE, если база есть.
• От 30 минут на первый цикл «черновик, разведка, перерисовка».

Пошаговая инструкция

1. Сформулируйте намерение в свободной форме. Напишите, что хотите получить, в двух-трёх абзацах. Не пытайтесь охватить всё. Зафиксируйте только то, что точно знаете.

2. Передайте черновик агенту и попросите провести разведку. Пример промпта:

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

1. Ответьте на вопросы агента и обновите спецификацию. Каждый ответ, это деталь, которую вы «знали, но не записали», или ограничение, о котором вообще не думали.

2. Попросите агента составить план реализации на основе обновлённой спецификации.

На основе обновлённой спецификации составь пошаговый план реализации.
Для каждого шага укажи, какие допущения ты делаешь.

1. Запустите выполнение по шагу за раз. После каждого шага проверяйте результат. Если обнаружился граничный случай или решение, которое противоречит спеку, вернитесь к спецификации и обновите её.

2. Повторяйте цикл, пока спецификация не совпадёт с реальностью. Финальная версия спека фиксирует не только «что хотели», но и «почему сделали именно так».

3. Сохраните финальную спецификацию в репозитории рядом с кодом. Через полгода кто-то спросит, почему фича работает именно так. Ответ будет в спеке, а не в истории коммитов.

Что делать с этим прямо сейчас, по ролям

Разработчикам. Попробуйте цикл на ближайшей задаче: напишите черновик спека за 10 минут, скормите агенту, ответьте на его вопросы. Результат будет точнее, чем часовая спецификация «из головы». Инструменты: Claude Code, OpenCode, Codex. Для пользователей JetBrains IDE автор подхода упоминает бесплатный плагин SpecBuddy, который позволяет комментировать код и спецификации прямо в среде разработки.

Авторам Дзена и копирайтерам. Принцип «карта, не территория» работает и для контент-планов. Попросите ИИ-агента указать, где в вашем техзадании на статью он вынужден догадываться. Вы удивитесь, сколько «очевидного» вы не записали.

Предпринимателям и менеджерам. Если ваша команда передаёт задачи ИИ-агентам, внедрите правило: спецификация обновляется после каждого цикла, а не сдаётся один раз. Это снижает количество итераций на переделку.

Финальную спецификацию стоит хранить рядом с кодом, как советует Шихипар. Через полгода именно она ответит на вопрос «почему сделали так», а не diff из коммита, который уже никто не помнит.