Spec-Driven Development: как Авито убирает фрустрацию от AI-кодинга и управляет продуктовой ценностью

Spec-Driven Development: как Авито убирает фрустрацию от AI-кодинга и управляет продуктовой ценностью

Энтузиазм вокруг применения нейросетей в разработке программного обеспечения переживает смену фаз: от восхищения сгенерированными строками кода команды переходят к осознанию реальной стоимости их поддержки. Массовая практика так называемого «вайб-кодинга» — итеративной генерации кода по словесным промптам без системной архитектуры — часто создает лишь иллюзию высокой скорости. Инженеры быстро получают результат, но столкновение с репозиторием раскрывает накопление технического долга и проявление фрустрации от решений, которые выглядят «почти правильными», но требуют длительного ручного поиска скрытых багов.

Чтобы устранить этот разрыв между набором текста и созданием продуктовой ценности, команды ищут системные методологии. Одной из наиболее перспективных практик становится Spec-Driven Development (SDD) — подход к разработке, направляемый спецификацией. В кластере HR-Tech компании Авито пилотирование SDD показало, как превращение спецификации в главный исполняемый источник правды позволяет взять под контроль контекст нейросети, защитить архитектуру от деградации и направить мощности AI на решение задач бизнеса.

Искажение метрик: почему генерация кода не равна полезности

Ключевой вывод из доклада Александра Шаповалова, кластерлида HR-Tech в Авито, касается глубокой разницы между метриками скорости написания кода и реальным выходом готового продукта.

Опросы разработчиков при неструктурированном использовании AI-ассистентов демонстрируют субъективное ощущение ускорения работы в 3–4 раза. Однако объективные полевые замеры продуктовой полезности показывают более скромный прирост — примерно в 1,4–2 раза.

Это расхождение объясняется спецификой работы нейросетевых моделей:

1. Иллюзия выработки: ассистент быстро генерирует сотни строк кода и попутные вспомогательные функции, создавая видимость огромного объема сделанной работы.
2. Накладные расходы на ревью: инженер тратит значительное время на вчитывание в сгенерированный текст, отладку логики и исправление контекстных ошибок.
3. Утечка контекста: при длительном диалоге модель забывает первоначальные бизнес-требования, начинает додумывать интерфейсы и вносить непредусмотренные изменения в соседние модули.

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

Инженерный воркфлоу SDD: от бизнес-цели к валидации

Методология Spec-Driven Development меняет базовый вектор работы: вместо генерации кода сразу по промпту команда строит последовательный и контролируемый процесс.

Рабочая цепочка SDD состоит из пяти обязательных этапов:

1. Requirements (Требования). Входом служит продуктовый документ: описание проблемы, пользовательская история (User Story) и бизнес-логика. На этом этапе формируется понятный словарь терминов (Glossary), чтобы продуктовые менеджеры, аналитики и инженеры единообразно понимали терминологию. Спецификация требований обязательно вычитывается людьми, поскольку модель способна сгенерировать неверное или лишнее условие.
2. Design (Технический проект). Требования перекладываются на технический язык архитектуры. Проектируются клиенты, обработчики запросов (handlers), структуры данных, схемы API и правила валидации.
3. Tasks (Декомпозиция на задачи). Архитектура разбивается на атомарные задачи. Каждая задача имеет прямую ссылку на пункт требований и проектных решений. Разработчик может удалить лишнюю задачу или вернуть план на переработку.
4. Code Generation (Генерация кода). AI-агент получает строго изолированный контекст конкретной задачи и реализует код в рамках согласованного дизайна.
5. Automated Validation (Автоматическая проверка). Сгенерированный код проходит проверку компилятором, линтерами и тестами.

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

Спецификация как артефакт в репозитории

В практике Авито для организации процесса используется специализированная структура артефактов. Для каждой спецификации создается отдельная папка внутри репозитория проекта, которая коммитится в Git и привязывается к отдельной ветке.

Такой подход решает проблему хранения контекста:

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

Ограничения метода и результаты пилота в Авито

Пилотирование SDD в кластере HR-Tech Авито позволило определить четкие границы применимости методологии. Подход показал себя не как универсальная серебряная пуля, а как инструмент для конкретного класса задач.

Наибольший позитивный эффект SDD продемонстрировал на крупных спринтовых задачах объемом около 8 Story Points (Story Point — абстрактная единица оценки сложности задачи в гибких методологиях). При реализации новых сервисов и функциональных модулей, особенно затрагивающих одновременно фронтенд и бэкенд, SDD кардинально снижает число нестыковок на стыке систем. В одной из команд Авито около 12% крупных технических задач были успешно переведены на этот процесс.

Напротив, на мелких точечных задачах объемом 0,5–1 Story Point (например, исправление опечатки или локальный хотфикс) полноформатный SDD оказывается неэффективным. Накладные расходы на составление требований и дизайна превышают время самого исправления. Сравнительный замер показал: точечная правка итеративным промптингом заняла 8 минут, тогда как проведение ее через весь цикл SDD потребовало 33 минуты и генерации избыточного объема сопроводительного текста.

Для предотвращения риска «водопада» (Waterfall), когда команда тратит недели на согласование идеальной спецификации, SDD требует гибких итераций и быстрой обратной связи.

Открытый toolkit: GitHub Spec Kit и официальный порядок установки

Для команд, желающих внедрить Spec-Driven Development, открытым стандартом является GitHub Spec Kit — специализированный инструментарий (toolkit), созданный GitHub для автоматизации процесса Spec → Plan → Tasks → Implement.

Официальная процедура развертывания Spec Kit включает следующие этапы:

1. Системные требования: операционная система Linux, macOS или Windows (PowerShell), установленный Python версии 3.11 или выше, а также менеджер пакетов uv или pipx.
2. Установка консольной утилиты: Для установки официальной CLI-утилиты через uv используется команда:

   uv tool install specify-cli
   

   Альтернативный вариант установки через pipx:

   pipx install specify-cli
   

3. Инициализация проекта: В корневой директории вашего проекта выполняется команда инициализации с указанием целевого AI-агента (например, Copilot, Claude или Gemini):

   specify init my-project --integration copilot
   

4. Проверка корректности установки: Для подтверждения работоспособности инструмента и проверки текущей версии выполняется команда:

   specify version
   

После инициализации в окружении разработчика становятся доступны команды управления этапами: /speckit.specify для составления требований, /speckit.plan для проектирования архитектуры, /speckit.tasks для декомпозиции и /speckit.implement для запуска сфокусированной генерации кода.

Итоги: управление продуктовой ценностью

Опыт Авито и развитие открытых инструментов доказали, что будущее нейросетевой разработки лежит не в усложнении промптов, а в дисциплине контекста и архитектуры. Spec-Driven Development возвращает инженеру роль архитектора и арбитра продуктовой ценности. Спецификация становится не формальным отчетом для менеджеров, а живым двигателем разработки, гарантирующим, что создаваемый код точно решает задачу бизнеса.