Внимание

Статья

Specification-Driven Development как операционная парадигма

01.Откуда взялась категория

История идеи «спецификация важнее кода» в индустрии длиннее текущей волны: от формальных методов и BDD (Behaviour-Driven Development) до DDD (Domain-Driven Design). Что изменилось в 2025–2026 — появление ИИ-агентов, способных писать значимый код по описанию. Это превратило старый методологический подход в практическую необходимость.

Без явной спецификации ИИ-агент работает на «здравом смысле»: выдумывает граничные условия задачи, не помнит контекст между сессиями, не воспроизводит ранее принятые архитектурные решения. К 2026 году это перешло из теоретической проблемы в операционную, и крупные игроки начали категоризацию рынка.

02.Кто и что продвигает

03.Что меняется в цикле разработки

Традиционный цикл: задача → код → документация (часто опциональная). Единственный источник истины — код.

SDD-цикл: задача → спецификация → код, документация, тесты (всё генерируется или сверяется со спецификацией). Единственный источник истины — спецификация.

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

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

04.Где Spec Builder

В фреймворке Сбертех, Spec Builder реализует слой Intent Loop — этап формулирования намерения до начала реализации. Коллекция-шаблон в нашей модели соответствует Pattern Library Сбера, Design Document — SDD-артефакту, эксперт-редактор — HITL-контуру (Human In The Loop). Ключевое отличие Spec Builder от рассмотренных решений — отсутствие привязки к конкретному облачному стеку (Bedrock, GitHub, собственной IDP). Это готовое решение для команд, которым нужен SDD-подход без многомесячного проекта внедрения собственной платформы разработки. Подходит как самостоятельным командам разработки, так и крупным корпорациям.

05.Когда нужен внешний SDD-движок, а когда строить свой

Подходит готовый движок

Внешний SDD-движок (Spec Builder)

Удобен, если:

  • Команда уже использует AI-агентов и появилась первая боль координации
  • Нет ресурсов или желания создавать собственную интегрированную платформу разработки
  • Нужен SDD-подход в работе сразу, без многомесячного проекта внедрения
Имеет смысл собственный слой

Свой SDD-слой в IDP

Оправдан, если:

  • Организация уже инвестировала в собственную Integrated Development Platform и хочет SDD-функционал внутри неё
  • Есть команда, готовая поддерживать такой инструмент длительно
  • Готовность к полному циклу AI-нативной разработки в собственной инфраструктуре

В обоих случаях SDD-подход — формирующийся корпоративный стандарт. Различие в том, кто строит инструмент: вы сами или мы для вас.

Связанные материалы