Код или док? Почему команды возвращаются к спецификациям — Spec-Driven Development

С Agile Manifesto всё в порядке, и никто его не отменяет. В 2000–2010-х годах подробная документация действительно нередко становилась бутылочным горлом. Написать детальную спецификацию и поддерживать её в актуальном состоянии — большая работа, требующая времени и ресурсов на всех этапах проекта.

А в продуктовой команде тем временем проводили исследования, тестировали гипотезы, вводили и убирали функциональность, стараясь отвечать на изменчивую среду и запросы пользователей... Документация не поспевала за изменениями в коде. Иногда вопрос стоял ребром: либо быстрая разработка, либо comprehensive documentation. Часто ответ был простым: надо делать, а не документировать. Когда ресурс времени ограничен, его предпочитали тратить на код, а не на документацию. Это практический выбор команды, а не требование Agile.

О том, какие документы помогают работать над IT-проектом, мы уже рассказывали в материале о проектной документации. Здесь речь о другом: как спецификация становится инструкцией для AI-разработки.

AI меняет соотношение этих затрат. Большие языковые модели могут генерировать код из текстовых описаний и контекста проекта, создавать тесты из спецификаций, превращать требования в прототипы. Но быстро получить код и получить готовый продукт — разные задачи. Остаются ревью, интеграции, тестирование и исправления. На этом фоне вопрос «что и как нужно написать?» становится ещё заметнее. Для этого необходимо сначала подробно описать, что ожидается на выходе.

Сама идея «сперва спецификация, потом код» не нова. В 2004 году Jonathan S. Ostroff, David Makalsky и Richard F. Paige опубликовали работу Agile Specification-Driven Development, соединяющую тесты и контракты — заранее заданные условия работы программы. Речь там не об AI-агентах; считать эту работу прямым предком современных инструментов оснований нет.

Однако актуальный сегодня AI-подход Spec-Driven Development не обязательно означает возврат к «водопаду» с многостраничными ТЗ. Спецификацию разрабатывают и для людей, и для агентов. На её основе AI помогает создавать код, API, тесты и документацию. В описанном ниже процессе спецификация становится первым и главным ориентиром, отражающим цель и суть продукта. Но её всё ещё надо поддерживать — иначе этот ориентир перестанет соответствовать коду. Markdown удобен для такого описания, но не является обязательным стандартом SDD.

Такой подход совместим с agile-ценностями — гибкостью, обратной связью, приоритетом работающего продукта. Меняется распределение усилий: время, которое удаётся высвободить благодаря код-ассистентам, можно посвятить проработке требований, архитектуры и бизнес-логики.

Фундаментальные вещи остаются на своих местах: стабильность системы, польза для клиента, бизнес-эффект, окупаемость команды...

Для нас в arcsinus SDD — это открытия, эксперименты, исследования, перестройка привычных процессов. Словом, новая веха в технологическом развитии компании. Артём Потёмин рассказывает, как произошла — а точнее, происходит — эта смена парадигмы. Ниже — его рассказ о работе команды на февраль 2026 года. Сведения о внедрении приводим с его слов: это не независимая проверка проектов и не измерение их эффективности.

По рассказу Артёма, он начал экспериментировать с AI-инструментами в апреле 2024 года. За несколько месяцев перепробовал множество подходов и пришёл к простому выводу: ИИ хорошо выполняет подробные инструкции, но требует заданного контекста и проверки результата. Чем точнее инструкция, тем меньше шансов, что что-то пойдёт не так. Инструкция в этом конкретном случае — аналитика, спецификация. О других поисках команды можно прочитать в статье о трёх экспериментах с вайб-кодингом.

«В своих поисках я набрёл на Spec Kit и понял, что сам интуитивно работаю по нему, — говорит Артём. — Сообщество, как оказалось, пришло к тому же, центром разработки должны быть инструкции».

По рассказу Артёма, переход на SDD изменил расстановку ролей в команде. В описанном им процессе аналитик — новый центр разработки.

«На всех установочных встречах я повторяю: мы теперь Spec-Driven Development, наша цель — делать хорошую документацию и хорошо тестировать. Потому что именно так мы гарантируем результат, — объясняет Артём. — У аналитика сейчас фундаментальная роль в процессе разработки. Его слово и документ — истина».

Так Артём формулирует приоритеты команды. Сама спецификация гарантии не даёт: результат всё равно необходимо проверять, а документы — актуализировать.

В описанном Артёмом процессе глобально роли не изменились. Аналитик по-прежнему собирает требования, оформляет их в пользовательские истории и пишет документацию — теперь в формате Markdown-файла с явно описанными данными, эндпоинтами и JSON-структурами. Разработчик по-прежнему реализует функциональность и покрывает её тестами. Тестировщик делает регрессионное и функциональное тестирование. Отличие в том, что документацию аналитика создают во многом для ИИ. И ещё в том, что разработчик пишет код теперь в основном через AI-агента — используя документ аналитика как инструкцию.

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

В arcsinus присматривались к Spec Kit, но, по рассказу Артёма, выбрали набор скиллов — Markdown-файлов с инструкциями для AI-агентов. Принцип работы такой: аналитик даёт контекст проекта, передаёт задачу через скилл — AI строит детальный план реализации. Если к задаче прикреплена документация, план становится ещё точнее. Дальше через скилл «Имплементация» план реализуется. Разработчик управляет агентами и отвечает за результат. Название и версия набора в этом рассказе не указаны, поэтому здесь описан принцип работы, а не инструкция по установке.

«Я нахожусь в постоянном поиске баланса между тратой токенов и точными результатами. — объясняет Артём. — Когда усиливаешь одну сторону, начинает хромать другая».

По состоянию на февраль 2026 года, о котором рассказывает Артём, для работы с кодом команда использует Cursor, а на некоторых проектах тестирует OpenAI Codex. В его опыте Codex может взять верхнеуровневую задачу, декомпозировать её и реализовать с небольшим участием разработчика. Это не отменяет проверки результата.

Мы переходим на SDD постепенно, внедряя подход в отдельных проектах. По рассказу Артёма, в феврале 2026-го полный цикл по SDD запущен на одном из наших проектов. Это первый проект с полным набором ролей, где, по его описанию, новый процесс отрабатывается целиком.

По рассказу Артёма, на февраль 2026 года на очереди ещё один проект — там уже в курсе перехода и восприняли его позитивно. Ожидаемая выгода для бизнес-заказчика формулируется просто: больше задач за то же время и меньшая стоимость реализации. Чтобы понять, достигается ли она, нужно учитывать весь цикл, включая ревью, тесты, интеграции, исправления и стоимость инструментов. Измерений такого выигрыша в этом рассказе нет.

Один из интересных эпизодов связан с тестированием. Артём рассказывает, как попросил Codex протестировать разработанное им же мобильное приложение. По его словам, агент спросил, установлен ли Android Studio, создал для себя инструмент тестирования, открыл эмулятор, установил APK, запустил приложение и начал самостоятельно взаимодействовать с экранами приложения. Параллельно рассказывал в чате, что делает и какие результаты получает. В финале — автоматически сформированный отчёт. По рассказу Артёма, ручных действий в этом эпизоде не потребовалось. Это отдельный эпизод из рассказа собеседника. Логи, перечень сценариев и независимая проверка результата к материалу не приложены; по нему нельзя судить о надёжности всех проверок приложения.

«Мне кажется, это перевернёт процессы тестирования, — говорит Артём. — Как минимум, SMOKE-тесты и базовое функциональное тестирование уже сейчас можно отдать AI. Это очень сильно ускоряет работу».

Smoke-тесты — короткая проверка базовых функций. Возможность поручить их агенту не означает, что его отчёт автоматически подтверждает качество продукта: нужно понимать, какие сценарии он проверил и что осталось за пределами проверки.

Постепенно меняются навыки специалистов и их подход к работе. По словам Артёма, когда он рассказывал команде об AI-first разработке, iOS-разработчик одного из проектов написал ему: «Я послушал тебя и понял: мы больше не разработчики, мы инженеры. Как ты смотришь на то, что я начну брать задачи по Android?».

Для нас это и есть верное понимание пути развития. SDD и AI-first могут расширять возможности, компетенции и зоны ответственности разработчика. Его работа всё больше связана не только с написанием кода, но и с управлением AI-агентами и архитектурой системы.

• Thoughtworks включила SDD в Technology Radar от 5 ноября 2025 года, в кольцо Assess. Это рекомендация изучать подход. В обзоре отмечают различия между реализациями: спецификации и их роль не везде одинаковы.
• GitHub представил Spec Kit — открытый набор инструментов для разработки от спецификации через план к задачам. Спецификация развивается вместе с проектом. Это описание процесса поставщиком инструмента; оно само по себе не измеряет выигрыш команды.
• Microsoft Learn предлагает обучающий модуль по SDD и GitHub Spec Kit. Модуль доступен на дату редакционной проверки — 7 октября 2026 года. Его наличие именно в феврале 2026 года отдельно не установлено; это дополнение к датированному рассказу команды.

Разумеется, не все в восторге от SDD. Основатель французской студии Marmelab François Zaninotto 12 ноября 2025 года опубликовал статью с провокационным заголовком: Spec-Driven Development: The Waterfall Strikes Back — «Водопад наносит ответный удар».

Он критикует объём Markdown, необходимость проверять и документы, и код, а также ложное чувство безопасности. По его оценке, чтение длинных файлов может стать дополнительной нагрузкой для разработчиков, а проверка требований и дизайна требует сочетания аналитической и технической экспертизы. Это критический взгляд автора на процесс, а не доказательство, что любой SDD-проект превращается в «водопад».

Разумеется, SDD — не серебряная пуля. Для каких-то команд и продуктов подход spec-first может стать лишней нагрузкой. Следующие условия — ориентиры для выбора пилота, а не универсальные правила.

• Продукт сложный и создаётся надолго. Если система будет развиваться годами и обрастать легаси-кодом, актуальная спецификация помогает сохранять общий ориентир. Но она не исключает технический долг и не заменяет контроль соответствия кода архитектуре.
• Команда распределённая или часто меняется. Когда разработчики работают удалённо или в проект регулярно приходят новые люди, спецификация помогает передавать контекст и снижать зависимость от одного человека, который всё знает. Для этого в ней должны оставаться актуальные решения.
• Есть культура проработки требований. SDD не создаёт эту культуру — он помогает её поддерживать. Если команда умеет работать с требованиями, аналитикой и архитектурой, спецификации могут стать рабочим инструментом. Если не умеет — превратятся в ещё одну формальность.
• Используются AI-инструменты для кодогенерации. В описанном здесь подходе спецификация задаёт контекст для кода и тестов. Но и без AI документация совместима с итеративной разработкой: наличие спецификации само по себе не делает процесс «водопадом».

• Продукт — стартап на стадии поиска product-market fit. Если каждую неделю гипотезы меняются, а срок жизни новой функции — две недели, слишком подробная спецификация может стать избыточной нагрузкой. Объём документации должен соответствовать задаче.
• Команда маленькая и стабильная. Если 3–5 человек сидят в одной комнате и постоянно общаются, часть формальных документов может быть избыточной. Хотя даже здесь бывают исключения: через полгода команда легко забывает, почему приняла то или иное решение. Кроме того, чем точнее контекст, тем лучше ИИ-помощник понимает задачу.
• Нет дисциплины и культуры требований. SDD выявляет недостатки в организации работы, но сам по себе их не устраняет. Если команда не умеет собирать требования, не понимает, что такое критерии приёмки, не привыкла думать об архитектуре, формальные спецификации станут ещё одной бюрократической нагрузкой, которую все игнорируют.
• Актуальность спецификации не поддерживается. Самый простой способ провалить SDD — написать спецификацию один раз в начале проекта и бросить. Код дописывают уже без документации, он уходит вперёд, документы не обновляют. В итоге спецификация становится источником дезинформации.

Напоследок — практические рекомендации Артёма для команд, которые хотят начать:

1. Найдите человека, который понимает, как работать с AI. Это должен быть универсал, который не боится брать незнакомые задачи и разбираться в новом — с помощью AI, разумеется. Он станет источником опыта и драйвером для всей команды.
2. Инвестируйте в аналитиков. Чем качественнее спецификации, тем меньше поводов для неверной реализации. В описанной Артёмом парадигме SDD аналитика — не дополнение к коду, а центр. Но экономию ресурсов ещё нужно оценить на практике.
3. Пересмотрите роли. В большинстве компаний традиционно главные герои — разработчики, и всё подтягивается за кодом. В центре описанного процесса SDD — тестирование и аналитика. Код важен, но его проверяют по спецификации и ожидаемому результату.

Если вы запускаете пилот, оценивать его полезно по полному циклу: от требований до результата после ревью, тестирования и исправлений. Это рекомендация для оценки перехода, а не уже измеренный результат arcsinus.

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

AI может ускорить создание кода. Но проблема понимания, что именно нужно делать, никуда не делась и стала более заметной. Спецификация помогает зафиксировать это понимание; результат всё равно требует проверки.

Рассказ arcsinus на февраль 2026 года показывает, как команда пробует жить по спецификациям: меняет роль аналитика, управляет агентами и сохраняет тестирование. Это описание опыта со слов собеседника, а не доказательство универсальной экономии. Критика Marmelab напоминает о риске новой бюрократии и нагрузке на ревью.

«Я думаю, подход SDD станет промышленным стандартом в компаниях, которые разрабатывают с помощью AI. Если уже не стал».

Артём Потёмин

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