Технический контекст
Я посмотрел на это обсуждение как практик, а не как наблюдатель со стороны: рынок явно движется к Spec-Driven Development, но зрелый стек пока складывается не вокруг одного инструмента, а вокруг связки подходов. В живом использовании чаще всплывают SpecKit, Claude Code с командой /plan и файл CLAUDE.md как опорный слой для управления контекстом.
Я отдельно отметил важную деталь: openspec и get-shit-done в этом поле пока выглядят нишево или сыро, а вот SpecKit уже стал де-факто ориентиром. Причина проста: у него есть понятная структура SDD — constitution, specification, task breakdown, validation gates — и это уже можно встраивать в инженерный процесс, а не просто показывать на демо.
По спекам я вижу и обратную сторону. SpecKit потребляет много токенов, потому что прогоняет модель через несколько фаз: принципы, спецификацию, декомпозицию, затем код и тесты. На длинных фичах это быстро превращается в дорогую воронку контекста, особенно если подключать сильные модели уровня Claude Opus или аналогов с высоким качеством рассуждения.
Именно поэтому мне близка мысль из обсуждения, что «спеки — это тесты». Когда я строю архитектуру ИИ-решений, я почти всегда стараюсь привязать спецификацию к проверяемому артефакту: тестам, контрактам API, acceptance-критериям, схемам данных. Иначе команда получает красивый документ, но не получает управляемую поставку.
Влияние на бизнес и автоматизацию
С точки зрения бизнеса я вижу здесь не модный workflow, а смену модели управления разработкой. SDD выгоден там, где цена ошибки высока: внутренние платформы, многомодульные B2B-продукты, интеграционные контуры, regulated-процессы. В таких случаях внедрение ИИ работает лучше, когда модель не «пишет код по вдохновению», а двигается по заранее заданной спецификации.
Кто выигрывает? Команды с сильной инженерной дисциплиной, где уже есть архитектурные правила, CI/CD, тестовая стратегия и владелец требований. Кто проигрывает? Те, кто хочет сделать ИИ автоматизацию поверх хаотичного legacy без нормальных границ системы и без человека, который удерживает архитектуру.
По моему опыту в Nahornyi AI Lab, основная ошибка при внедрении искусственного интеллекта в разработку — пытаться автоматизировать кодогенерацию раньше, чем определены инварианты системы. Тогда CLAUDE.md разрастается, /plan начинает генерировать слишком общие шаги, а token burn маскирует отсутствие решений. Снаружи кажется, что агент работает, а внутри растёт технический долг.
Поэтому я бы не продавал SDD как универсальную замену обычной разработки. Я бы продавал его как управляемую ИИ интеграцию в инженерный цикл: для greenfield, для крупных фич, для модулей с ясными контрактами и для команд, которые готовы платить за предсказуемость.
Стратегический взгляд и глубокий разбор
Я думаю, что следующий этап SDD — не «ещё больше спецификаций», а более жёсткая компрессия контекста. Победит не тот стек, который пишет самые длинные спеки, а тот, который умеет разложить систему на короткие доменные контуры, подать агенту только нужные правила и вернуть результат в общую архитектуру без расползания контекста.
Именно здесь Claude Code с /plan и аккуратным CLAUDE.md часто оказывается практичнее, чем тяжёлый универсальный фреймворк. Я уже видел этот паттерн в проектах Nahornyi AI Lab: короткий архитектурный манифест, узкие task-пакеты, тесты как форма спецификации и отдельные саб-агенты под bounded contexts. Это даёт лучшее соотношение между качеством, скоростью и стоимостью.
Мой прогноз простой: SDD останется, но в зрелом виде сольётся с AI-архитектурой, где спецификация станет не документом ради документа, а исполнимым контрактом. Для бизнеса это хорошая новость. Значит, разработка ИИ решений будет уходить от дорогой импровизации к повторяемому production-подходу.
Этот разбор подготовил я, Вадим Нагорный — ведущий эксперт Nahornyi AI Lab по AI-архитектуре, ИИ автоматизации и практическому внедрению ИИ в реальный бизнес. Если вы хотите понять, подходит ли SDD вашему продукту, как сократить token burn и как выстроить архитектуру без хаоса, я приглашаю вас обсудить проект со мной и командой Nahornyi AI Lab.