Разборы · Статья: · Видео: · 17:47
Spec-driven development: спека до кода как способ приручить ИИ-ассистента
Разбор доклада Эрика Ханчетта (AWS) о spec-driven development: почему написать требования и дизайн в markdown до кода делает ИИ-ассистента быстрее и качественнее, при чём тут зона Златовласки, property-тесты, MCP и роль человека-ревьюера.
Смотреть на YouTube Using Spec-Driven Development for Production Workflows - Erik Hanchett, AWS
AI Engineer · 17:47
Главы видео — нажми, чтобы перейти к моменту 9
- 0:00 Что такое spec-driven development Спецификации и дизайн-документ в markdown создаются до того, как написана хоть строчка кода.
- 1:14 Зачем это нужно: LLM как ИИ-стажёр Помощнику по коду нужно давать направление, иначе он сходит с рельсов — как слишком ретивый стажёр.
- 2:46 Разве фронтир-модели не справятся сами? Модели умнеют, но не идеальны: больше контекста направляет их надёжнее, чем ожидание «умнее чипа».
- 3:58 Осторожно с контекстом и скиллы Зона Златовласки в steering-доке: не много и не мало правил. Плюс скиллы — инструкции по требованию.
- 5:09 Ты — человек в цикле и ревьюер Всё в SDD завязано на тебя: если что-то сломается, виноват ты, а не агент. AI-ревью — в помощь, но не вместо.
- 6:32 Kiro: зачем AWS сделала свой инструмент Клиенты вайб-кодили, но не получали нужного результата и строили bespoke-паттерн спек. AWS собрала Kiro.
- 8:33 SDD без Kiro: вручную и Spec Kit Тот же процесс можно вести руками с любым ассистентом или через открытый Spec Kit от GitHub.
- 10:42 Три документа и property-тесты Требования (EARS), дизайн (mermaid), список задач с property-based тестами против самих спек. Плюс трюк с MVP.
- 12:45 MCP: подтянуть тикеты в спеку Model Context Protocol тянет требования из Jira/Asana прямо в spec-flow — при всех спорах, жив ли MCP.
Коротко
Spec-driven development — это писать требования и дизайн-документ в markdown до того, как ИИ-ассистент напишет хоть строчку кода: так модель получает контекст и не сходит с рельсов. Главный вывод — инструмент вроде Kiro лишь автоматизирует процесс, но ответственность, ревью и правка спек остаются на человеке.
Выжимка голосом
Самое ценное из разбора — за пару минут
Показать текст выжимки Скрыть текст выжимки
Озвучено синтезом речи · голос alena
Объясни проще
Суть без жаргона
Простыми словами
Spec-driven development — это когда ты сначала простыми словами описываешь в markdown-файлах, что должна делать программа и как она устроена, и только потом даёшь ИИ-ассистенту это кодить. Так модель не фантазирует, а следует твоему плану, и код выходит и быстрее, и надёжнее.
Как ребёнку
Прежде чем строить дом из лего, ты рисуешь на бумаге, каким он будет. ИИ — как очень быстрый, но слишком буквальный помощник: без чёткого чертежа он соберёт что-то своё. Спека и есть тот чертёж, по которому он собирает.
Аналогия — «это как…»
Это как работа с подрядчиком: сначала техзадание и чертежи, которые вы вместе согласовали, и только потом стройка. Без чертежа рабочий-энтузиаст зальёт фундамент не там, где надо.
Зачем это мне
Вайб-кодинг без плана даёт красивое демо, но разваливается на сложных фичах и легаси-проектах. Спека-до-кода — способ получить от ИИ предсказуемый результат и не оказаться крайним, когда что-то сломается в продакшене.
Для тех, кто в теме
SDD формализует цикл requirements (EARS) → design (mermaid/ASCII) → tasks с property-based тестами против самих спек. Нюансы: steering-доки в зоне Златовласки, скиллы по требованию, переупорядочивание задач в MVP, подтягивание тикетов через MCP. Kiro и Spec Kit автоматизируют паттерн, но human-in-the-loop и ручная правка спек остаются обязательными.
Оценка видео
Чем выше — тем больше пользы на минуту
средняя из 5
Spec-driven development, скиллы и MCP — одна из главных тем инженерии вокруг ИИ в 2026 году.
Процесс объяснён плотно и по делу, но заметная часть — презентация Kiro и демо-скриншоты.
Сама идея «спеки до кода» стара как водопад; свежесть — в связке с LLM, скиллами, property-тестами и MCP.
Даёт готовый воркфлоу, трюк с MVP, property-тесты и чек-лист — можно применить в тот же день.
По сути доклад вендора (AWS/Kiro); автор это признаёт, но уклон в свой продукт остаётся.
Кому будет полезно
Чем выше оценка — тем больше пользы для профессии. Разверни — почему.
Для разработчиков и программистов 4.6 /5
Прямое попадание: готовый процесс, как получать от ИИ-ассистента предсказуемый код на сложных фичах и в легаси, а не только красивые демо.
Для тимлидов и техлидов 4.2 /5
SDD даёт командный стандарт: единый формат требований и дизайна, ревью документов и явная роль человека в цикле вместо хаотичного вайб-кодинга.
Для начинающих в вайб-кодинге 4 /5
Объясняет, почему их поделки разваливаются, и даёт структуру: сначала требования и дизайн, потом код, с обязательным ревью.
Для QA-инженеров 3.7 /5
Property-based тесты против самих требований и дизайна — свежий взгляд на то, как связать тесты со спецификацией, а не с реализацией.
Для продакт-менеджеров 3.5 /5
EARS-формат требований, уточняющие вопросы и подтягивание тикетов из Jira/Asana через MCP делают их документы напрямую исполнимыми ИИ.
Инсайты
Нажми, чтобы раскрыть — то, что меняет взгляд на тему
01 Модель — не всезнающий джун, а стажёр, которого ведут документами 1:14
Смена рамки: проблема не в том, что модель «недостаточно умная», а в том, что ей не хватает направления. Спека-до-кода — это способ дать контекст и удержать ассистента на рельсах, а не ждать более сильного релиза.
02 Больше контекста не значит лучше — есть зона Златовласки 4:16
Перегрузить agents.md или CLAUDE.md правилами так же вредно, как оставить его пустым. Контекст надо дозировать: достаточно правил, чтобы модель знала, что делать, но не столько, чтобы утонуть в них.
03 Спеки нужны не только для новых проектов 9:54
Расхожее возражение — «это только для greenfield». На деле в живых приложениях, которым годы, лежат десятки spec-файлов: подход одинаково полезен для легаси, когда фича требует продумывания заранее.
04 Ответственность не делегируется агенту 5:28
Код пишет ИИ, но человеком в цикле и ревьюером остаёшься ты. Если что-то сломается в продакшене, спросят с тебя — поэтому дизайн- и требования-документы нужно читать так же внимательно, как код.
05 Тесты можно писать против спецификации, а не против кода 12:02
Property-based тесты проверяют не конкретную реализацию, а соответствие требованиям и дизайну, прогоняя десятки и сотни случайных значений. Тест становится продолжением спеки, а не отдельным артефактом.
Ключевые цитаты
Сильные фразы из видео — нажми тайм-код, чтобы услышать в оригинале
«Структурированные спецификации создаются до того, как написана хоть строчка кода.»
«Мне нравится думать о наших помощниках по коду как об ИИ-стажёрах: дай им чуть свободы — и они сойдут с рельсов.»
«Тут нужна зона Златовласки: информации должно быть ровно столько, сколько нужно, — не много и не мало.»
«Помни: в spec-driven development всё завязано на тебя — ты человек в цикле.»
«Если что-то пойдёт не так, виноват будешь ты, а не агент.»
«Результат ровно настолько хорош, насколько хорош твой вклад.»
«Возьми первые четыре задачи, вынеси их наверх и сначала собери мне MVP.»
Полезные советы
Что можно применить уже сегодня. Разверни совет — сколько займёт, что даст и что конкретно делать
1 Пиши спеку до кода в три документа
час на первую фичу ИИ перестанет фантазировать и начнёт следовать плану
Пиши спеку до кода в три документа
Разложи задачу на требования, дизайн и список задач — каждый следующий документ опирается на предыдущий. Это и есть контекст, который направляет модель.
Что делать
- 1 Попроси ассистента создать user requirements по твоему описанию.
- 2 Проверь и поправь их, затем попроси дизайн-документ.
- 3 После правки дизайна попроси список задач для реализации.
2 Настрой steering-док в зоне Златовласки
20 минут модель получит нужные правила и не утонет в лишних
Настрой steering-док в зоне Златовласки
В agents.md или CLAUDE.md держи ровно столько правил и гайдлайнов, чтобы ассистент понимал контекст проекта. Не пусто и не гигантская простыня.
3 Проси сначала MVP из первых четырёх задач
2 минуты на промпт быстро увидишь рабочий результат вместо долгой сборки вслепую
Проси сначала MVP из первых четырёх задач
Как только сгенерирован список задач, попроси вынести наверх первые четыре и собрать из них минимальный работающий продукт — потом достраивай остальное.
Что делать
- 1 Дождись сгенерированного task-листа.
- 2 Напиши: «вынеси первые четыре задачи наверх и собери MVP».
- 3 Запусти MVP, убедись, что он работает, и продолжай.
4 Включи property-based тесты против требований
полчаса убедишься, что задачи реализованы по спеке, а не «на глаз»
Включи property-based тесты против требований
Попроси сгенерировать тесты, которые прогоняются десятки-сотни раз с разными значениями и проверяют требования и дизайн. В node-мире это, например, fast-check.
5 Останавливайся и правь спеку своей экспертизой
15 минут на документ результат станет ровно настолько хорош, насколько хорош твой вклад
Останавливайся и правь спеку своей экспертизой
После генерации дизайна и требований не гони сразу в код: внеси свои знания, вкус и детали, вычитай на галлюцинации, нестыковки и ошибки.
6 Используй скиллы для повторяемых инструкций
вечер на настройку ассистент будет подключать нужные инструкции по ключевым словам сам
Используй скиллы для повторяемых инструкций
Скиллы — это файлы-инструкции, которые запускаются по требованию: по ключевому слову или через слэш-команду. Их удобно подключать на этапах дизайна и реализации.
7 Подтяни тикеты из трекера через MCP
полдня на интеграцию требования продакта попадут в спеку без ручного копирования
Подтяни тикеты из трекера через MCP
Через Model Context Protocol можно тянуть тикеты и требования из Jira или Asana прямо в spec-flow. Пропиши в steering-доке, из какого MCP-сервера брать данные.
8 Мелочь вайб-коди, крупное — спекай
по ситуации не будешь тратить церемонию спек на однострочные правки
Мелочь вайб-коди, крупное — спекай
SDD оправдан на глубоких фичах, сложных проектах и там, где нужно продумать заранее. Для мелкого фикса быстрее просто вайб-кодить, хотя спек-режим для багфиксов тоже существует.
Сценарии применения
Как разные люди применяют это на практике
Я как Инди-разработчик
Проблема: вайб-кодит один, и на второй сотне файлов проект превращается в кашу без структуры
Хочу: получать от ассистента предсказуемый код, который потом не стыдно поддерживать
Поможет: статья даёт процесс requirements → design → tasks и трюк с MVP, чтобы держать проект в узде
Я как Техлид
Проблема: команда вайб-кодит кто во что горазд, ревью превращается в разбор чужих фантазий модели
Хочу: единый стандарт работы с ИИ-ассистентами
Поможет: можно ввести общий формат спек, steering-доки и обязательное ревью документов до кода
Я как Продакт-менеджер
Проблема: требования живут в Jira, а разработка с ИИ идёт отдельно и теряет детали
Хочу: чтобы его требования напрямую попадали в разработку
Поможет: разбор показывает EARS-формат и подтягивание тикетов через MCP прямо в спеку
Я как QA-инженер
Проблема: тесты привязаны к реализации и ломаются при каждом рефакторинге
Хочу: тестировать соответствие требованиям, а не конкретный код
Поможет: property-based тесты против спеки прогоняют сотни значений и проверяют требования, а не строки
Я как Джун на первой работе
Проблема: ИИ выдаёт код, который вроде работает, но джун не понимает, правильный ли он
Хочу: научиться направлять ассистента и проверять результат
Поможет: статья объясняет роль человека в цикле и как читать дизайн-документ до принятия кода
Я как Фрилансер на легаси
Проблема: достался старый проект на годы кода, страшно трогать без карты
Хочу: понять, применим ли спек-подход к существующему коду
Поможет: разбор развеивает миф «только для greenfield» — spec-файлы работают и в легаси
Логика повествования
Как устроена аргументация видео — пройди по шагам
-
Предпосылка ИИ-ассистенты мощны, но без направления сходят с рельсов 1:14
Как ретивый стажёр: дай чуть свободы — и он сделает не то. Нужна структура, а не только сильная модель.
-
Аргумент Больше контекста направляет модель надёжнее 2:46
Фронтир-модели не идеальны; дополнительный контекст помогает вести их туда, куда нужно проекту.
-
Аргумент Спеки в markdown до кода дают этот контекст 0:35
Требования и дизайн-документ, написанные заранее, отлично ложатся на работу с LLM.
-
Аргумент Но контекст надо дозировать, а человек — ревьюить 5:09
Зона Златовласки в steering-доке плюс обязательное ревью каждого документа: ответственность на человеке.
-
Пример Kiro формализует это в spec-режим 6:32
AWS увидела bespoke-паттерн у клиентов и собрала инструмент: требования EARS, дизайн, задачи.
-
Пример Property-тесты и MVP проверяют результат 12:02
Тесты против самих спек и переупорядочивание первых задач в MVP дают быструю обратную связь.
-
Вывод SDD даёт и скорость, и качество — на сложных фичах и легаси 9:54
Вывод: не просто быстрее кодить, а получать более качественный код при структурном планировании.
Подробный разбор
Полный разбор — разверни, если нужно глубже
Развернуть подробный разбор Свернуть подробный разбор
Стоит ли смотреть целиком
Да — если ты пишешь код с ИИ-ассистентами и устал от того, что вайб-кодинг красиво стартует и разваливается на второй сотне файлов. За 18 минут Ханчетт укладывает рабочий процесс: описать требования и дизайн в markdown, вычитать их своей головой, а уже потом пускать модель в код. Самая ценная мысль доклада — не про инструмент, а про рамку: ИИ стоит воспринимать как ретивого стажёра, которому нужно направление, а не как автономного сеньора.
Держи в уме, что это доклад инженера AWS, и середина уходит в презентацию Kiro. Но подход не привязан к продукту: тот же цикл requirements → design → tasks можно вести вручную с любым ассистентом или через открытый Spec Kit от GitHub. Практические жемчужины — зона Златовласки для steering-доков, трюк «вынеси первые четыре задачи в MVP» и property-тесты против самих требований — работают где угодно.
Что не стоит упускать
Главный тезис, который автор повторяет дважды: человек остаётся в цикле. Спека не снимает ответственность, а концентрирует её — ты ревьюишь каждый документ на галлюцинации и нестыковки ровно потому, что за сломанный продакшен спросят с тебя, а не с агента. И контрапункт для честности: на мелких правках вся эта церемония избыточна, спек-подход раскрывается на сложных фичах и легаси, где цена ошибки высока, а планирование заранее окупается.
План внедрения
С чего начать — отмечай шаги, прогресс сохранится
Выполнено 0 из 6
Проверь себя
Ответь на вопросы, чтобы материал закрепился
-
1. Что по определению отличает spec-driven development?
-
2. С кем автор сравнивает ИИ-ассистента по коду?
-
3. Что такое «зона Златовласки» применительно к steering-докам?
-
4. Кто отвечает за ошибки в процессе spec-driven development?
-
5. Только ли для новых (greenfield) проектов подходит SDD?
-
6. Что проверяют property-based тесты в этом процессе?
-
7. Какой трюк автор советует для быстрого рабочего результата?
-
8. Зачем MCP полезен в spec-flow?
Словарь терминов
Понять незнакомое простым языком
Показать 10 терминов Свернуть словарь
- Spec-driven development (SDD)
- Подход, при котором сначала пишут структурированные спецификации и дизайн-документ, и только потом по ним генерируют код.
- Vibe coding
- Разработка «на ощущение»: даёшь ИИ короткий промпт и правишь результат на лету, без заранее продуманных спек.
- Steering docs
- Файлы вроде agents.md или CLAUDE.md с правилами и контекстом проекта, которые направляют ассистента. Термин Kiro.
- Зона Златовласки
- Образ «не слишком много и не слишком мало»: правил в steering-доке должно быть ровно столько, сколько нужно.
- EARS
- Шаблонный формат записи требований («когда происходит X, система должна делать Y»), делающий их однозначными и проверяемыми.
- Property-based тесты
- Тесты, которые прогоняются много раз с разными случайными значениями и проверяют общее свойство (соответствие требованиям), а не один конкретный случай.
- MCP (Model Context Protocol)
- Протокол, позволяющий модели подключаться к внешним источникам данных — например, тянуть тикеты из Jira или Asana.
- Skills (скиллы)
- Файлы-инструкции для ассистента, запускаемые по требованию — по ключевому слову или слэш-командой.
- Greenfield / legacy
- Greenfield — проект с нуля; legacy — существующий код, которому уже годы. SDD применим к обоим.
- Kiro
- AI IDE и CLI от AWS со spec-режимом, реализующие spec-driven development из коробки (kiro.dev).
Критический взгляд
Объективно: с какими тезисами можно поспорить и что преувеличено
Это по сути презентация вендора, а не нейтральный разбор подхода
Значительная часть доклада — про Kiro и AWS. Автор честно оговаривает «это мои мнения», но выбор акцентов и примеров всё равно продвигает конкретный продукт.
«SDD делает и быстрее, и качественнее» — верно не всегда
Написание и вычитка требований и дизайна добавляют время впереди. Выигрыш реален на сложных фичах и легаси, но на мелких задачах церемония спек может замедлить, что автор упоминает лишь вскользь.
Метафора «модель как стажёр» упрощает природу ошибок LLM
Стажёр учится и не выдумывает несуществующие API. Галлюцинации модели — иной класс ошибок, который «направлением» и спеками смягчается, но не устраняется; ревью остаётся обязательным именно поэтому.
Property-тесты и EARS поданы как почти всегда уместные
Для многих продуктовых задач это тяжёлая формальная церемония. Полезность property-тестов сильно зависит от того, есть ли у требований чётко формализуемые инварианты.
MCP рекомендуется завязывать в процесс, хотя сам автор признаёт его незрелость
Ханчетт говорит, что MCP «ещё созревает» и впереди долгий путь, особенно по безопасности. Строить на нём производственный spec-flow сегодня — ставка с оговорками, а не готовое решение.
Взгляни иначе
Новый угол, смежные области и потенциал на стыке — пища для размышлений
Спека — это многоразовый промпт, а не бюрократия
Разовый промпт живёт одну сессию, спека — версионируемый контекст, который переживает модель и команду. По сути это переход от «оператора чата» к инженеру, который проектирует контекст.
Тот же приём работает вне кода
Аутлайн до текста, сценарий до съёмки, бриф до дизайна — SDD переоткрывает старую истину: сначала структура, потом исполнение. С ИИ это просто стало обязательным, а не желательным.
Спека как живой контракт между продактом и агентом
На стыке product-менеджмента и разработки спека в EARS-формате плюс MCP превращает требования продакта в напрямую исполнимый агентом артефакт — граница «постановки» и «реализации» размывается.
Не возвращается ли водопад?
Спеки до кода звучат как классический waterfall, который Agile когда-то похоронил. Разница в цикле обратной связи: раньше между спекой и рабочим кодом были недели, теперь — секунды, и итерация спеки почти бесплатна.
Тесты как исполнимая спецификация
Если property-тесты пишутся против требований и генерируются ИИ, граница между «спекой» и «тестом» исчезает: спецификация становится исполнимой и самопроверяемой, а не просто документом для чтения.
Похожие разборы
Строй системы, а не код: как проектировать агентов инженерными навыками
Проектирование агентов — это не новая дисциплина, а те же инженерные навыки: системное мышление, декомпозиция, контракты, управление состоянием и безопасность. Разница только в примитивах — вместо классов и сервисов у вас промпты, скиллы, скрипты и сабагенты, но дисциплина ровно та же.
Читать → РазборКак писать сильные скиллы для ИИ-агентов: чеклист из четырёх осей
Скиллы для ИИ-агентов расплодились, но нет рубрики, чтобы отличить хороший от плохого, — и люди тонут в «скилл-аде». Доклад даёт чеклист из четырёх осей (триггер, структура, стиринг, прунинг), а главный приём — «ведущие слова», которыми агента направляют небольшими, но точными формулировками.
Читать → РазборПромпт — это всё ещё перфокарта: почему мы до сих пор учимся говорить с ИИ
Модели поумнели невероятно, но протокол общения с ними остался пакетным, как у перфокарт 1950-х: собери всю просьбу, отправь, жди ответ. Настоящий следующий шаг ИИ — не более умная модель за тем же окном ввода, а интерфейс, который сам участвует в разговоре и снимает лишнюю ношу с человека.
Читать → РазборLoop Engineering: как перестать быть оператором LLM и начать проектировать циклы
Если ты общаешься с агентом больше, чем принимаешь инженерные решения, ты превратился из инженера в оператора LLM — и упёрся в потолок ручного промтинга. Loop Engineering предлагает проектировать не отдельный промт, а цикл вокруг модели: с внешней памятью, изоляцией, независимым чекером, измеримым контрактом и лимитами — но внедрять его по нарастающей, оставляя финальную ответственность на человеке.
Читать →