Как мы используем спецификации и AI-агентов, чтобы ускорить разработку видео в 2026

Зачем Фора Софт написала этот плейбук

Фора Софт каждый день делает продукты на видео в реальном времени, WebRTC, стриминге и мультимодальном AI. За последние 18 месяцев мы перестроили нашу поставку вокруг spec-driven agentic engineering и обкатали её на самых разных проектах — концертах Worldcast Live с 10 000 одновременных зрителей, телемедицине под HIPAA на CirrusMED, продакшн-комнатах 1080p на Speed.Space и онлайн-переводе на 62 языка в Translinguist.

Этот плейбук — ровно тот метод, который мы используем. Четыре артефакта, которые мы пишем до строчки кода. Контрольные точки ревью, ловящие галлюцинации и дрейф безопасности. Реальные дельты по циклу и стоимости, которые мы наблюдаем у себя. И подводные камни, в которые мы уже вступили, чтобы вы туда не лезли. Прочитайте до конца один раз, а потом держите под рукой, когда будете оценивать следующий проект на WebRTC или стриминге.

Если вы хотите применить этот пайплайн прямо к вашей кодовой базе — команда Agentic Engineering у нас работает по фиксированной стоимости в формате 3–6-недельного контракта.

Что такое spec-driven agentic engineering на самом деле

Spec-driven development (SDD) переворачивает традиционный цикл. Вместо «сначала пишем код, потом, может быть, документируем» источником истины становится спецификация, а код — её производным. Когда вы добавляете сюда современных AI-агентов — Claude Code, Cursor, GitHub Copilot в режиме агента, AWS Kiro, OpenAI Codex CLI — спецификация превращается в контракт, который агент реализует, а человек становится не машинисткой, а ревьюером и архитектором.

Практический процесс, к которому пришли GitHub Spec Kit, Kiro и наша собственная поставка, — это четырёхфазный цикл: Specify → Plan → Tasks → Implement. У каждой фазы — явные «ворота». Спецификация не коммитится без ревью. Задачи не стартуют без спецификации. PR не мерджится без тестов, утверждающих спецификацию.

Выигрыш не в том, что агент пишет код быстрее (хотя пишет). Выигрыш в том, что быстрее работает вся система: меньше переделок, меньше скачков скоупа на полпути, оценки реально удерживаются, а от бизнес-намерения до строки кода тянется встроенный аудиторский след. В регулируемых вертикалях это разница между HIPAA-аудитопригодным пайплайном и кошмаром управления процессами.

Четыре режима: vibe coding, spec-first, TDD, spec-driven

Эти четыре часто путают; на самом деле это разные практики с разными профилями риска.

TDD и SDD дополняют друг друга — SDD работает выше уровня модулей и рассматривает тестовый набор как один из выходов спецификации, а не как саму спецификацию.

Ландшафт AI-агентов в 2026

Claude Code (Anthropic). Наш дефолт для длительной работы. Постоянная память CLAUDE.md, субагенты, хуки, отличные многофайловые рефакторинги. Опрос Pragmatic Engineer (февраль 2026): 46% — «самый любимый» агент.

Cursor. Прежде всего IDE. Хорош для плотных циклов правок, параллельной оркестрации агентов после редизайна апреля 2026. Берём его для фронтенда и плотных проходов рефакторинга.

GitHub Copilot + Spec Kit. 4,7 млн платных подписчиков к январю 2026; ~46% сгенерированного кода в компаниях из Fortune 100. Spec Kit CLI добавляет внутрь Copilot в режиме агента явные фазы Specify → Plan → Tasks → Implement.

AWS Kiro. Единственная массовая IDE с первоклассной поддержкой spec-driven разработки и хуками на события. Выдала 95%+ кода бизнес-логики в трёхнедельном кейсе AWS по drug discovery. Хороша для AWS-стеков.

OpenAI Codex CLI. Лёгкий компаньон, который работает рядом с Claude Code; хорош для быстрых рефакторингов, поиска по коду и структурированных правок. Плагин Claude Code в апреле 2026 заставил их работать вместе, а не конкурировать.

Cognition Devin, Replit Agent. Агенты с большей автономией. Полезны на узкой повторяющейся работе; в продакшене всё равно нужны контрольные точки.

Сейчас наш стек: Claude Code как основной агент, Cursor для плотной работы в IDE, Spec Kit CLI для процессов с воротами и собственные CI-задачи для отлова дрейфа. Один инструмент не выигрывает на каждой задаче; навык в том, чтобы оркестрировать их вокруг одной спецификации.

Анатомия полезной спецификации

Спецификации, по которым агент действительно может работать, имеют общую форму. Это markdown, под версионным контролем, короткие и чёткие в части того, что в скоуп не входит.

Бизнес-цель. Одно предложение, обращённое к пользователю. Не «собрать транскодер», а «дать пользователям стримить в 1080p с задержкой < 500 мс и аккуратным фолбэком на аудио ниже 1 Мбит/с».

Критерии приёмки. Маркированный список, каждый пункт — тестируемый. Стиль Given-When-Then хорошо подходит для конечных автоматов WebRTC и медиапайплайнов. Расплывчатые критерии («обрабатывать сетевые сбои») — это допущения, которые агент додумает не туда.

Ограничения. Бюджеты задержки, предпочтения по кодекам, лимиты по полосе пропускания, требования платформ, версии библиотек. Агенту нужно понимать, что зафиксировано, прежде чем он начнёт импровизировать.

Вне скоупа. Список «не в этот раз» в одну строку. Не даёт услужливости агента превратиться в раздувание скоупа.

Известные риски. То, что вы и так знаете и что может выстрелить (вариативность декодера H.265 на Android, entitlements фонового аудио на iOS). Записывая их в спецификацию, вы держите их на виду на ревью.

Четыре артефакта, которые мы пишем на каждом проекте

.project-root/
├ AGENTS.md           # project-wide rules for every agent
├ specs/
│   ├ requirements.md # user stories + acceptance criteria
│   ├ design.md       # architecture + constraints + trade-offs
│   └ tasks.md        # ~2-hour units, test-first, agent-sized
├ src/
└ tests/

AGENTS.md. Тот самый файл, который любой агент читает первым. Команды сборки, конвенции именования, правила тестирования, запреты («не трогать infra/prod.tf без согласования»). Формирующийся стандарт, теперь под крылом Linux Foundation Agentic AI Foundation, к началу 2026 его принял уже 60 000+ репозиториев.

requirements.md. Пользовательские истории, критерии приёмки, метрики успеха. Без кода, без архитектуры. Не больше двух страниц на фичу; больше — значит фичу пора резать.

design.md. Стек, границы сервисов, контракты данных, рассмотренные и отклонённые компромиссы. Агенты могут с этим работать — им просто нужен контекст. Включите явный список «без согласования агенту нельзя X» для кода, чувствительного к безопасности.

tasks.md. Гранулярные задачи, каждая — 1–2 часа для человека, ≤ 100 строк диффа, с тестами приёмки на каждую задачу. Это и есть то, что агент реально потребляет в фазе Implement.

Реальные цифры по продуктивности (с оговорками)

Честная версия истории про продуктивность — неоднозначная. Заявленные приросты варьируются от исследования к исследованию, по типу задач, опыту команды и тому, насколько серьёзно команда относится к дисциплине спецификаций.

Как это читать. Прирост реален, когда (а) спецификации дисциплинированные, (б) на ревью заложен бюджет, и (в) команда уже знакома с предметной областью. Негативные сигналы DORA — рост времени ревью PR и инцидентов на PR — это предсказуемый сценарий провала при попытке прицепить агентов к командам без SDD. Агенты выпускают больше кода; спецификации направляют этот код; ревью по-прежнему ловит дефекты. Все три элемента нужны.

На наших видеопроектах мы фиксируем ускорение поставки фич на 20–40% и точность оценок в пределах примерно 6% по проекту целиком. Это и есть та цифра, которую мы готовы зафиксировать, когда оцениваем работу по фиксированной стоимости.

Где это работает лучше всего: видео, WebRTC, стриминг

Видео — идеальная цель для SDD. Много шаблонного кода, чётко определённые протоколы, тяжёлая кросс-платформенная обвязка, понятные критерии приёмки («< 500 мс glass-to-glass») и сильные стимулы тщательно тестировать. Где агенты действительно отрабатывают свою стоимость:

Обвязка и сигналинг WebRTC. Обработка ICE-кандидатов, согласование SDP, конечные автоматы соединения, NACK/PLI. 70–80% шаблонного кода ложатся на спецификацию и пишутся агентом.

Медиапайплайны и DASH/HLS. Обвязка FFmpeg, генерация манифестов, разбиение на чанки, лестницы битрейта. Агенты сильны в коде-оркестраторе; тонкую настройку производительности оставляйте людям.

UI плеера (веб и мобильные). Обёртки HTML5 video, обработчики жестов, рендеринг субтитров, адаптивный CSS. По чёткой спецификации — 60–70% кода от агента.

Генерация тестов для стримов. Критерии приёмки в стиле Given-When-Then напрямую превращаются в тесты на pytest/mocha. Одно предложение в спецификации — 5–10 тест-кейсов. Метрики, против которых эти тесты пишутся, разобраны в нашем плейбуке по качеству WebRTC-стрима.

Конфигурация и деплой SFU. Конфиги LiveKit, mediasoup и Janus; манифесты Kubernetes; правила автоскейлинга. Прекрасно поддаётся шаблонам; при тугой спецификации агенты выдают стабильный результат.

Обёртки мобильных SDK. Биндинги iOS Swift, обвязка JNI на Android, потоки разрешений, обработка lifecycle. Агент делает повторяющуюся часть; за человеком — работа с памятью и потоковая безопасность на C++-ядре.

Применение SDD на легаси-кодовой базе

Чистый SDD блестит на greenfield. Brownfield-работа — кодовая база, в которой ваш продукт живёт сегодня — требует более узкого варианта. Ошибка — пытаться задним числом покрыть спецификациями весь монолит, прежде чем разрешить агентам что-либо трогать. Никогда не закончите, и агенты никогда не помогут.

Спецификация — на одно изменение за раз. Пишите requirements и design на каждую конкретную фичу или фикс, а не на всю систему. «Добавить HEVC в существующий транскодер» — полезная спецификация. «Переписать систему транскодинга» — это уже проект.

Паттерн Sidecar Inference. Новая AI-логика работает как отдельный сервис за адаптером. Легаси-система не трогается. Изолированная спецификация, изолированное тестирование, изолированный откат.

«Душитель» для миграций. Маршрутизируйте новый трафик на spec-driven сервис; легаси обрабатывает остальное, пока его постепенно не заменят. Meta использовала этот паттерн при миграции 50+ кейсов WebRTC с разошедшегося форка, где агенты автоматически чинили ошибки сборки и разрешали мердж-конфликты.

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

Human-in-the-loop: контрольные точки, которые имеют значение

1. Утверждение спецификации. Никакого кода, пока не смерджены requirements.md и design.md. Подписывают и техлид, и владелец продукта. Это убивает 70% последующих изменений скоупа.

2. Декомпозиция задач. Прежде чем агент начнёт реализацию, старший инженер ревьюит tasks.md. Любая задача дольше ~2 часов делится. Любая задача без теста приёмки отклоняется.

3. Ревью PR. Каждый PR от агента проходит человеческое ревью. На код криптографии, кодеков, аутентификации и обработки данных смотрит профильный эксперт. На шаблонный код достаточно обычного инженера. Заложите 25–40% времени поставки на этот этап — SDD сдвигает работу, а не отменяет её.

4. Проверка дрейфа спецификации в CI. Лёгкая CI-задача сопоставляет спецификацию с смерджённым PR: удовлетворяет ли код каждому критерию приёмки? Расхождения роняют сборку. Инструменты: GitHub Spec Kit, собственные скрипты поверх JSON-схем.

5. Поэтапный rollout. Код от агента сначала уезжает в стейджинг. Реальное парное тестирование WebRTC, синтетические мониторы, проверка SLO. И только потом — в продакшен.

Мини-кейс: MVP видеочата на LiveKit за 40 человеко-часов

Ситуация. Клиенту нужен был MVP видеочата на LiveKit поверх его существующего стека аутентификации и уведомлений к демо для инвесторов. Традиционный скоуп: 4–6 недель с выделенными фронтенд- и бэкенд-инженерами. До демо — 10 календарных дней.

План на 12 дней. Дни 1–2 — написали четыре артефакта: пользовательские истории (звонок 1-на-1, комната, mute/unmute, демонстрация экрана, чат), design (LiveKit Cloud + Next.js + наш auth), задачи (18 штук, каждая ~2 часа) и AGENTS.md, который запрещал трогать продакшн-аутентификацию. Дни 3–7 — Claude Code и Cursor параллельно прорабатывали задачи; один старший инженер ревьюил каждый PR, техлид отвечал за CI на дрейф спецификации. Дни 8–10 — полировка, нагрузочные тесты на LiveKit Cloud и продакшен-смоук с реальным авторизованным пользователем на iOS и Android.

Результат. 40 человеко-часов инженеров за 10 дней. MVP отгружен на 10-й день. Демо закрыло раунд. Постмортем показал отклонение от плана по часам ~4% и ноль переделок на сигналинге WebRTC. Мы собрали его на нашей практике LiveKit-разработки, которая с тех пор показывает похожую скорость и на других видеопроектах.

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

Экономика: что SDD реально меняет в счёте

Подписки на агентов. Claude Code, Cursor и Copilot вместе укладываются в 3 750–7 500 ₽ на инженера в месяц. Существенно, но мелочь рядом с зарплатами инженеров. Агенты — это дешёвый вход; дорогой вход — это спецификации и ревью.

Наш подход к ценообразованию. На Agentic Engineering большую часть экономии времени мы передаём клиенту и берём обязательство по фиксированному скоупу. Если в 2026 году вам предлагают традиционные сроки и цены на видеопроект или WebRTC-сборку — рынок уже посчитал вашу работу неправильно.

Стек агентов Фора Софт в 2026

Оркестрация. Claude Code как основной драйвер. Cursor — когда работа — это плотные циклы в IDE. Kiro — для greenfield в AWS-стеке.

Авторинг спецификаций. GitHub Spec Kit для пайплайна Specify → Plan → Tasks → Implement. Везде markdown; никаких проприетарных форматов.

Конфигурация агентов. AGENTS.md в корне репозитория, CLAUDE.md для Claude Code, .cursorrules для Cursor. Содержание одно, файлы разные.

Верификация. CI с юнит- и интеграционными тестами, проверкой дрейфа спецификации и сканом безопасности (Snyk, Trivy). Стейджинг с синтетическими мониторами WebRTC. Ревью кода — на каждом PR от агента.

Наблюдаемость. Дашборды Datadog или Grafana, лог рассуждений агента на каждый PR — на случай постмортема. Если в продакшен уехал баг, мы вместе перепрогоняем спецификацию, прогон агента и заметки ревью — чтобы найти, где проскочило.

Слой QA. AI-усиленное QA поверх тестов от агента и сводный отчёт по тестированию в формате пирамиды Минто на каждый релиз — см. наш материал о том, как правильно рассказывать о ходе тестирования.

Фреймворк решения — пять вопросов перед запуском SDD

1. Можете ли вы уместить критерии приёмки на одну страницу? Если да — SDD подходит. Если команда не может договориться, что значит «готово», — задача ещё не созрела для агентов.

2. Это greenfield или хорошо ограниченный модуль? Greenfield и чётко изолированные brownfield-модули — отличная ниша для SDD. Запутанные легаси-переписывания — нет, для них работают паттерны sidecar и «душителя».

3. Есть ли у вас старшие ревьюеры? Агенты умножают объём работы. Без старших ревьюеров для разбора этого потока вы выпустите 3× кода и 3× инцидентов. Если ёмкости на ревью сегодня нет — сначала почините это.

4. Регулируемая ли у вас область? HIPAA, SOC 2, PCI, IEC 62304 — SDD здесь, наоборот, подарок: спецификация + CI на дрейф + история ревью — ровно то, что хотят аудиторы. Но заложите дополнительные циклы на ревью безопасности и неизменяемые логи.

5. Хватит ли у руководства терпения на спецификации в начале? Команды под давлением «давайте уже кодить» обычно пропускают этап спецификаций и потом обвиняют агентов в хаосе. Если руководство не готово защитить первую неделю на написание спецификаций — SDD не приживётся.

Пять подводных камней, которые убьют ваше SDD-внедрение

1. Галлюцинации без тестового стенда. Агенты охотно пишут уверенно неправильный код — особенно на стыках кодеков, криптографии и протоколов. Защита — ваш тестовый набор. Нет теста приёмки — нет мерджа PR.

2. Дрейф спецификации. В спецификации стоит «< 500 мс задержки»; агент привозит код, в котором задержка вообще не измеряется. Тесты проходят, в поле — падает. Поставьте в CI задачу, которая проверяет, что каждый критерий приёмки превратился где-нибудь в утверждение в тестах.

3. Перекладывание решений. Агенты прекрасно справляются с 80% шаблонного кода и катастрофически — с теми 20%, где нужна экспертиза предметной области (потокобезопасность, допуски lip-sync, регуляторные пограничные случаи). На этих 20% явно держите человека в цикле.

4. Пропуск AGENTS.md. Без проектных правил для агентов каждый прогон заново изобретает конвенции именования, переспоривает стиль и иногда рефакторит файлы, которые вы не просили трогать. 200 строк AGENTS.md в первый день экономят сотню грязных PR.

5. Делать вид, что ревью необязательно. Цифры DORA 2026 — время ревью PR +441%, инциденты +243% — это то, что происходит с командами, которые подключают агентов и не защищают ёмкость на ревью. Закладывайте 25–40% времени поставки на ревью — или принимайте такой объём инцидентов.

Безопасность и соответствие требованиям в агентных процессах

Отчёт State of AI Agent Security 2026 зафиксировал, что 80,9% команд гоняют агентов в продакшене, а полное согласование по безопасности есть только у 14,4%. 88% сообщили хотя бы о подозреваемых инцидентах. Риски реальны и управляемы.

Изолируйте права агента. Никогда не давайте агенту запись в продакшен-кредлы, секреты или пайплайны деплоя. Песочница для рабочей зоны; явное согласование на сетевые вызовы.

Сканируйте каждый PR от агента. Snyk, Trivy, GitGuardian, Semgrep. Более 25% из 30 000 проанализированных навыков агентов содержали хотя бы одну уязвимость — сканируйте до мерджа, не после.

Неизменяемый аудиторский след. Логируйте каждый прогон агента (промпт, ответ, тронутые файлы, прогнанные тесты) в неизменяемое хранилище. Для регулируемых вертикалей это и есть аудиторский артефакт.

Моделируйте угрозы для самих агентов. Дрейф агента (тихое расхождение с намерением) и Prompt Injection (вредоносный ввод, перенаправляющий агента) — два новых класса угроз. Митигаторы: CI на дрейф спецификации, очистка вводов, ограниченный список инструментов на агента.

Подключайте SDD к compliance-пайплайну. Спецификации, заметки ревью, логи CI и записи об инцидентах ложатся в одно неизменяемое хранилище. Для аудитов SOC 2 или HIPAA это теперь более быстрый путь, не более медленный.

KPI для отчёта бизнесу

KPI скорости. Lead time фичи (от мерджа спецификации до продакшена), сторипоинты на спринт, отклонение оценки (%).

KPI качества. Доля дефектов, ушедших в продакшен; инциденты на PR; коэффициент переделок (дни на переделку / дни на исходную поставку); нестабильность автотестов (цель < 1%).

KPI эффективности. Время ревью на PR, доля PR от агентов, покрытие спецификации (% критериев приёмки, на которые есть тесты), стоимость фичи (часы инженеров + токены агентов).

Когда НЕ стоит использовать spec-driven агентов

Исследовательские спайки и поисковые прототипы. Если вы не знаете, что строите, спецификация — преждевременная оптимизация. Сначала vibe-код, узнавайте, потом пишите спецификацию на то, что оставите.

Реально новые домены. Агенты, обученные на публичном коде, плохо работают на задачах, для которых нет аналога. Ведут люди; агенты помогают с шаблонами по краям.

Команды без ёмкости на ревью. Выход агента без ревью даёт результат хуже, чем работа без агентов. Сначала чините ёмкость на ревью.

Среды с очень низким уровнем доверия. Закрытая работа в air-gapped-сетях, стадии до получения регуляторного одобрения — поверхность аудита для агентного пайплайна может всё ещё быть слишком широкой. Используйте ограниченные паттерны или ждите on-prem-агентов, удовлетворяющих вашей модели угроз.

FAQ

Spec-driven development — это то же самое, что водопад?

Нет. Водопад исходит из того, что спецификация финализирована до начала реализации. SDD исходит из того, что спецификация — текущее лучшее понимание, она лежит в системе контроля версий и итерирует вместе с кодом. Изменение поведения сначала меняет спецификацию, потом — код. Водопад — это модель фаз; SDD — цикл обратной связи, где якорем выступает спецификация.

Какого AI-агента выбрать команде?

В 2026 году по умолчанию — Claude Code: сильный многофайловый контекст, хорошая работа со спецификациями, 46% предпочтений в опросе Pragmatic Engineer. Cursor — для плотной работы по фронтенду в IDE. Kiro — для greenfield в AWS-стеке. GitHub Copilot + Spec Kit — если вы и так Copilot-команда. Большинство серьёзных команд параллельно использует двух, а не ставят всё на одного.

Насколько spec-driven agentic engineering реально быстрее?

RCT GitHub показал падение времени цикла PR на 75%. DORA 2026 — +66% к пропускной способности по эпикам. AWS Kiro отгрузила трёхмесячный проект за 3 недели. На наших видеопроектах мы фиксируем ускорение поставки фич на 20–40%. Разброс реален — результат зависит от дисциплины спецификаций, опыта команды и знания домена.

Можно ли применить это к нашей легаси-кодовой базе?

Да, но аккуратно. Спецификация — на одно изменение за раз, sidecar inference — чтобы изолировать новую AI-логику, паттерн «душителя» — для постепенной миграции. Пытаться написать спецификацию на весь легаси-монолит до того, как что-то трогать — ловушка. Расширяйте автономию агента по мере того, как данные ревью подтверждают его надёжность в вашей кодовой базе.

Как остановить галлюцинации агента?

Три контроля. (1) Точные спецификации с конкретными примерами — исследование на ArXiv показывает, что уточнённые спецификации сокращают ошибки кода LLM примерно на 50%. (2) Тестовый стенд, который роняет PR, если критерии приёмки не выполнены. (3) Ревью кода человеком на каждом PR от агента, с особой строгостью на коде криптографии, кодеков и безопасности. По отдельности ни один контроль не достаточен; вместе — работают.

Что на самом деле лежит в AGENTS.md?

Команды сборки и тестирования, конвенции стиля и именования, файлы и каталоги, которые агент не должен править без согласования, чувствительные к безопасности пути, как поднять локальное окружение, какие внешние библиотеки заранее одобрены, и указатель на каталог спецификаций. AGENTS.md теперь — открытый стандарт под крылом Linux Foundation Agentic AI Foundation, его принял уже 60 000+ репозиториев.

Безопасно ли это для рабочих процессов под HIPAA / SOC 2 / PCI?

Да — если так и проектируете. Спецификации, заметки ревью и логи CI образуют тот неизменяемый аудиторский след, который и нужен аудиторам. Ограничьте права агента (никаких продакшен-секретов, никакого доступа к деплою), сканируйте каждый PR и пускайте чувствительный к безопасности код через ревью профильного эксперта. На HIPAA-телемедицине и PCI-платёжных системах, которые мы делаем, SDD сократил подготовку к аудиту, а не удлинил.

Сколько стоит spec-driven MVP видеопродукта?

На Agentic Engineering мы обычно отгружаем MVP видеочата на LiveKit или mediasoup за 3–6 недель календарного времени и 40–120 человеко-часов инженеров. Конкретная оценка зависит от платформ (web + iOS + Android против только web), скоупа интеграции с аутентификацией и списка фич — позвоните нам или напишите, чтобы получить конкретную цифру.

Что почитать дальше

Готовы выпустить видеопродукт на SDD?

Spec-driven agentic engineering — это не мода. Это сегодняшний лучший ответ на вопрос «как нам быстрее отгружать сложный видеософт и не утонуть в инцидентах». Дисциплины описать просто, срезать углы — нельзя: сначала пишем спецификацию, потом агент реализует против неё, жёсткое ревью, тесты против критериев приёмки — и спецификация ведёт аудиторский след.

Если делать аккуратно — вы выпускаете фичи на 20–40% быстрее, режете переделки до однозначных процентов, удерживаете точность оценки в пределах ~6% и получаете аудиторский артефакт, который радует аудиторов. Если делать небрежно — получите сценарий ужастика DORA 2026. Разница — в дисциплине, и у нас за плечами два десятилетия отработки этой дисциплины на регулируемых, высокорисковых видеопродуктах.