По мере развития AI-assisted development фокус разработчиков смещается с написания кода на формулировку задачи и проверку результата. Когда разработчик работает над задачей с агентом, он передаёт агенту в чате контекст, необходимый для формулировки задачи. Этот контекст живёт только до тех пор, пока жив агент или пока не произойдёт сжатие контекста. Для простых сценариев разработки, когда автономность агентов невелика, это подходящий вариант.

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

Спеки также повышают качество ревью другими агентами. У ревьюеров появляется постановка задачи, по которой был написан код.

Типичная спека состоит из следующих частей:

1. Требования: как должна вести себя система.
2. Ограничения.
3. Критерии приёмки.
4. План реализации и список задач, которые агент должен выполнить в процессе реализации.

Есть два популярных фреймворка для работы со спеками:

1. GitHub Spec Kit фокусируется на пайплайне разработки: specify → plan → tasks → implement.
2. OpenSpec фокусируется на жизненном цикле изменений в спеках: explore → propose → apply → archive.

В моём опыте пайплайн в разработке на основе спецификаций (spec-driven development, SDD) выглядит так:

1. В тикете фиксируется краткое описание задачи, цель и критерии приёмки.
2. Владелец продукта вместе с агентом формулирует требования человеческим языком. Я предпочитаю EARS, но формат может быть другим.
3. Разработчик вместе с агентом добавляет технические детали: разбивка на подсистемы, ограничения, технические требования.
4. Разработчик и агент готовят план и список задач для реализации.
5. Один или несколько агентов под присмотром разработчика реализуют фичу по плану и пишут тесты.
6. Разработчик и агент-ревьюер проверяют соответствие кода цели, спеке и критериям приёмки. Выявляют и устраняют расхождения между спецификациями и кодом.
7. Ответственный за приёмку сверяет результат со спекой и критериями приёмки, проверяет, что все автоматизированные проверки прошли (тесты, линтеры, агенты), а затем принимает его.

Если во время ревью или приёмки обнаруживается проблема в спеке или плане, работа возвращается на соответствующий этап пайплайна.

Автономный агент берёт на себя всё большую часть реализации. Разработчик отвечает за спеку и план, а после реализации проверяет результат. Чем автономнее агент, тем сильнее качество кода зависит от качества этих артефактов.