Конец эры «вайб-кодинга»! Да здравствует SDD!

Несколько месяцев назад сообщество разработчиков было очаровано новым феноменом: вайб-кодингом (vibe coding). Его концепция была опьяняюще проста — вам не нужен был план, блок-схема или даже глубокое понимание синтаксиса; вам просто нужно было описать свои ощущения ИИ-агенту и наблюдать, как материализуется код. Это казалось магией, пока не появился первый серьезный баг. Внезапно этот безупречный опыт превратился в неистовый цикл из «исправь это» и «теперь сломалось то», оставляя разработчика в ловушке диалога с машиной, которая потеряла нить повествования.

Исторически мы тратили месяцы на шлифовку исчерпывающих документов с требованиями до того, как была написана хоть одна строчка кода — жесткий процесс, который часто подавлял инновации; сегодня же мы часто выпускаем код еще до того, как решили, что именно должен делать продукт — хаотичная привычка, создающая огромный технический долг. Это напряжение породило новую парадигму: разработку на основе спецификаций (spec-driven development, SDD). Это прагматичная «золотая середина», призванная дать ИИ-агентам необходимые направляющие, не возвращаясь к раздутым каскадным методам (waterfall) 1990-х годов.

Контракт намерений

В своей основе разработка на основе спецификаций заключается в создании «единого источника истины», который могут читать как люди, так и машины. Ден Делимарски из Microsoft описывает спецификацию как «контроль версий для вашего мышления», и на практике она функционирует как обязательный контракт. Вместо того чтобы бросать расплывчатые промпты в экран и надеяться на лучшее, разработчик пишет краткий структурированный документ, который точно определяет, как должен вести себя код.

Технически говоря, этот сдвиг решает проблему «дрейфа контекста». ИИ-агенты блестяще справляются с исполнением, но склонны забывать «зачем» нужна та или иная функция после пятидесяти раундов правок. Закрепляя процесс разработки в спецификации, мы гарантируем, что ИИ останется помощником, а не «неуправляемым орудием». Биргитта Бёкелер из Thoughtworks выделяет три уровня этой эволюции: сначала спецификация (spec-first), где план предшествует коду; закрепленная спецификация (spec-anchored), где документ продолжает жить для руководства обслуживанием; и амбициозная спецификация как источник (spec-as-source), где человек касается только спецификации, а базовый код остается полностью «под капотом».

Kiro: CLI для архитектора

Разработанный принципиальной командой внутри AWS, Kiro — это надежный инструмент, который относится к созданию программного обеспечения как к инженерной дисциплине, а не как к игре в угадайку. Он предлагает как IDE, так и CLI, но его реальная сила заключается в структурированных требованиях на языке Markdown. Kiro использует EARS (Easy Approach to Requirements Syntax) — нотацию, которая заставляет соблюдать ясность через простую структуру: КОГДА [условие], СИСТЕМА ДОЛЖНА [поведение].

С точки зрения пользователя, написание требований EARS меньше похоже на «кодинг» и больше на логическое картирование. Эта структура позволяет Kiro генерировать тесты на основе свойств (property-based tests), которые гораздо более комплексны, чем стандартные юнит-тесты, и улавливают пограничные случаи, которые разработчик-человек — или ИИ, ведомый «вайбом» — скорее всего, упустил бы. Кроме того, Kiro вводит концепцию «рулевых» файлов (steering files). Эти документы — product.md, tech.md и structure.md — действуют как невидимая инфраструктура проекта, гарантируя, что каждый фрагмент сгенерированного кода соответствует выбранному технологическому стеку и архитектурным соглашениям.

Spec Kit: стандартизация рабочих процессов агентов

Spec Kit от Microsoft использует другой подход, функционируя как мост с открытым исходным кодом между тридцатью различными кодинг-агентами и структурированным четырехфазным процессом. В то время как вайб-кодинг кажется неструктурированным мозговым штурмом, Spec Kit напоминает профессиональный воркшоп. Он вводит набор слэш-команд, таких как /speckit.plan и /speckit.analyze, которые заставляют агента остановиться и подумать, прежде чем начать печатать.

Парадоксально, но добавляя эти «точки трения», Spec Kit на самом деле ускоряет разработку. Он предотвращает «циклы галлюцинаций», когда агент пытается исправить ошибку, внося новую, более сложную ошибку. Независимо от того, строите ли вы новый проект с нуля или пытаетесь распутать фрагментированную легаси-базу кода, Spec Kit предоставляет проекту «конституцию». Он переводит разработчика-человека из роли машинистки в роль рецензента, фокусирующегося на высокоуровневой логике, в то время как агент берет на себя громоздкие детали реализации.

Tessl и реестр навыков

Tessl привносит в экосистему SDD захватывающий уровень: реестр пакетов. Если мы представим код как рецепт, Tessl предоставит стандартизированные ингредиенты и методы приготовления через свои «плитки» (tiles). Эти плитки содержат процедурные рабочие процессы (навыки), обязательные стандарты кодирования (правила) и документацию, которую агенты могут запрашивать по требованию.

Говоря простым языком, использование Tessl похоже на выдачу вашему ИИ-агенту библиотечной карточки и свода домашних правил. При установке плитки Tessl SDD и простом промпте агенту «используй разработку на основе спецификаций», рабочий процесс меняется. Агент перестает вести себя как покорный автодополнитель и начинает действовать как младший инженер, который задает уточняющие вопросы и составляет план перед тем, как прикоснуться к репозиторию. Эта прозрачность жизненно важна; она превращает непрозрачный «черный ящик» ИИ-генерации в видимый, проверяемый процесс.

Zenflow: оркестрация с верификацией

Если другие инструменты фокусируются на «что» и «как», Zenflow фокусируется на «кто» и «где». Разработанный командой Zencoder, Zenflow действует как уровень оркестрации, координируя работу нескольких ИИ-агентов параллельно без повреждения кодовой базы. Он рассматривает каждую функцию как рабочий процесс, используя изолированные рабочие деревья Git (worktrees), чтобы гарантировать, что изменения будут протестированы и проверены до того, как они попадут в основную ветку.

Если смотреть шире, на уровне индустрии, Zenflow представляет собой движение к «мультиагентным» системам. В этой модели один агент может писать спецификацию, другой — внедрять код, а третий — проводить кросс-агентское ревью кода. Эта система сдержек и противовесов имитирует высокоэффективную команду инженеров-людей. Для пользователя результатом является устойчивый цикл разработки, где неудачные тесты запускают автоматические исправления, а код «отгружается» только после того, как он прошел через все шлюзы верификации.

Тихий сдвиг в цифровой грамотности

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

В конечном счете, рост таких инструментов, как Kiro, Spec Kit, Tessl и Zenflow, свидетельствует о том, что будущее программирования заключается не в исчезновении технической строгости, а в ее эволюции. Мы уходим от эры «хакера-одиночки» к эре «технического архитектора». В этом новом мире наша ценность как людей заключается не в способности помнить синтаксис, а в способности определять четкие, этичные и эффективные спецификации для машин, которые строят наш мир.

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

Источники

• Документация AWS: Kiro Agent and EARS Notation Standards (2025-2026).
• Microsoft Open Source: Spec Kit Repository and 'Version Control for Thinking' by Den Delimarsky.
• Thoughtworks Technology Radar: 'The Three Levels of Spec-Driven Development' by Birgitta Böckeler.
• Официальный реестр Tessl: Tile and Skill Documentation for AI Agents.
• Инженерный блог Zencoder: Zenflow Orchestration and Verification Gate Mechanics.