# Как разработка на основе спецификаций (SDD) спасает от хаоса ИИ-кодинга Источник: https://www.youtube.com/watch?v=hy8UstR2NEg Канал: DeepLearning.AI Опубликовано: 22.09.2026 --- В эпоху стремительного развития нейросетевых помощников программирование часто превращается в хаотичный процесс, известный как «vibe coding» (программирование по наитию). Разработчики бросают в LLM быстрые промпты, надеясь на чудо, но получают горы неструктурированного кода и технический долг. В новом курсе от DeepLearning.AI и JetBrains эксперты предлагают дисциплинированную альтернативу — Spec-Driven Development (SDD), где центральное место занимает четкая спецификация, а агент становится исполнительным механизмом в руках инженера. ## 🚀 От «вайб-кодинга» к инженерной дисциплине [[JUMP:04:14]] Программирование на основе «вайбов» (vibe coding) дает быстрые, но поверхностные результаты: разработчик просит «создать кнопку», получает не совсем то, что хотел, и вступает в бесконечный диалог с моделью, пытаясь исправить ошибки [04:27]. Как отмечает ведущий курса Пол Эверитт (Paul Everitt), Developer Advocate в JetBrains, такой подход ведет к накоплению технического долга и созданию одноразового кода, который невозможно поддерживать в долгосрочной перспективе [05:05]. Spec-Driven Development (разработка на основе спецификаций) — это профессиональный ответ на хаос неконтролируемой генерации кода. Основная идея SDD заключается в четком разделении «что» и «почему» (спецификация) от «как» (реализация). В этой парадигме создается своеобразный контракт не только между людьми, но и между человеком и ИИ-агентом [05:30]. Пол Эверитт выделяет три ключевых преимущества SDD: * **Масштабируемый контроль:** небольшие изменения в спецификации могут приводить к масштабным, но предсказуемым изменениям в коде. Например, замена одной строчки «использовать SQLite» на «использовать MongoDB» автоматически перестроит сотни строк инфраструктурного кода [00:52]. * **Сохранение контекста:** LLM-агенты «забывчивы» (stateless). Спецификация служит внешним хранилищем контекста, предотвращая деградацию качества ответов при заполнении контекстного окна модели [01:17]. * **Точность намерений:** процесс написания спецификации заставляет человека четко определить проблему, критерии успеха и ограничения, прежде чем агент напишет первую строку кода [01:30]. ## 📜 Конституция проекта: фундамент разработки [[JUMP:09:48]] Любой серьезный проект в SDD начинается с создания «Конституции проекта» (Project Constitution). Это набор высокоуровневых документов в формате Markdown, которые определяют глобальные правила игры. Конституция независима от конкретного агента и служит общим источником истины для всех участников процесса [10:14]. Конституция состоит из трех столпов: 1. **Миссия (Mission):** объясняет «зачем» создается проект, описывает видение, целевую аудиторию и рамки продукта [10:27]. 2. **Технологический стек (Tech Stack):** фиксирует принятые архитектурные решения, выбор языков, библиотек и инструментов развертывания [10:40]. 3. **Дорожная карта (Roadmap):** живой документ, содержащий последовательность этапов, каждый из которых будет реализовываться через циклы разработки фич [10:52]. Эндрю Ын (Andrew Ng), основатель DeepLearning.AI, подчеркивает, что написание спецификации — это тяжелый интеллектуальный труд. По его мнению, если оставить принятие архитектурных решений на откуп агенту, это неизбежно приведет к созданию «странных продуктов» и плохой поддержке кода [01:56]. Вместо этого он рекомендует проводить предварительный диалог с агентом (например, Claude или ChatGPT), обсуждать компромиссы, а затем просить ИИ резюмировать принятые решения в файлы спецификации [01:44]. ## 🔄 Цикл разработки фичи: планирование, реализация, проверка [[JUMP:20:06]] После утверждения Конституции разработка переходит в итеративный режим. Каждая новая функция проходит через строгий цикл, изолированный в отдельной ветке Git [20:45]. Процесс выглядит следующим образом: * **Планирование (Plan):** Разработчик обсуждает с агентом конкретную задачу из дорожной карты. Результатом становится документ `feature_spec.md`, включающий план задач и «карточку проверки» (verification scorecard) [20:57]. * **Реализация (Implement):** Агент приступает к написанию кода, основываясь на утвержденном плане. На этом этапе Пол Эверитт советует использовать команду `/clear`, чтобы очистить текущий контекст агента и заставить его опираться только на файлы спецификаций, а не на предыдущие случайные реплики в чате [23:31]. * **Проверка (Verify):** Человек выступает в роли главного инженера или проверяющего. Вместо того чтобы вычитывать каждое имя переменной, он должен сосредоточиться на том, соответствует ли результат высокоуровневым требованиям [25:40]. Важным элементом является концепция «Человека в контуре» (Human-in-the-Loop). Если в ходе проверки обнаруживается ошибка, ее следует исправлять не вручную, а через обновление спецификации, чтобы агент сам переписал код. Это гарантирует, что документация и код всегда остаются синхронизированными [26:18]. ## 🛠️ Борьба с «ИИ-усталостью» и работа с Legacy [[JUMP:35:49]] Работа с ИИ-агентами может порождать феномен «AI fatigue» — усталость разработчика от огромного количества генерируемого кода, который нужно проверять [36:01]. Для борьбы с этим Эверитт предлагает несколько стратегий: 1. **Разделение этапов:** Никогда не начинайте кодинг до завершения планирования. 2. **Малые шаги:** Если задача слишком велика, просите агента выполнять ее по частям [38:46]. 3. **Использование под-агентов:** Можно попросить основного агента создать нескольких «виртуальных рецензентов» для глубокого аудита проекта. Это позволяет получить свежий взгляд на код, не перегружая контекстное окно основной модели [40:57]. Метод SDD применим и к существующим проектам (Brownfield). В этом случае процесс начинается с «обратной инженерии»: агент анализирует текущий код и файлы (например, `README.md` или `TODO.md`) и на их основе формулирует Конституцию проекта [47:01]. Это позволяет привести старый код в соответствие с новыми стандартами разработки и обеспечить преемственность знаний [47:14]. ## 🦾 Автоматизация и стандарты: Skills и ACP [[JUMP:33:40]] Для повышения эффективности SDD используются «Навыки» (Skills) — пакеты инструкций, которые обучают агента новым повторяющимся действиям, таким как автоматическое обновление лога изменений (changelog) или выполнение проверок качества кода [33:54]. В индустрии уже формируются стандарты для унификации работы агентов: * **MCP (Model Context Protocol):** Протокол для предоставления агентам доступа к внешним данным, например, актуальной документации библиотек через инструменты вроде Context 7 [52:26]. * **ACP (Agent Client Protocol):** Стандарт для связи агентов с различными IDE (например, WebStorm или VS Code). Благодаря ACP разработчик может легко переключаться между разными моделями (Claude Code, OpenAI Codex) в рамках одного и того же проекта, сохраняя все рабочие процессы [58:10]. * **Готовые наборы инструментов:** Проекты вроде **Spec Kit** от GitHub или **Open Spec** от Fission AI предлагают встроенные команды для реализации SDD-цикла [54:47]. Завершая курс, Пол Эверитт призывает разработчиков «вернуть инженерное искусство» в процесс создания программного обеспечения. В мире, где ИИ берет на себя роль «мускулов», человек должен оставаться «мозгом», определяющим цели и контролирующим архитектуру через качественные спецификации [08:56].