От вайб-кодинга к спецификациям
В феврале 2025 года Андрей Карпатый (ученый и сооснователь OpenAI) предложил концепцию вайб-кодинга (vibe-coding). Человек, вдохновленный идеей, “на вайбе” рассказывает агенту о своем намерении, агент его реализует.
Вайб-кодинг выглядит заманчиво и действительно отлично работает для простых типовых задач. Прототип системы, лендинг, чат-бот или персональная утилита, например, обработка записей встреч или подготовка коммерческих предложений.
Однако, попытка создать что-то более сложное таким способом нередко приводит к проблемам.
- Угроза безопасности - согласно исследованиям, 30-40% кода, созданного ИИ, содержат известные уязвимости. В 2025 году несколько взломов (Base44, Tea App) произошли именно из-за потери контроля над безопасностью в vibe-coded приложениях.
- Галлюцинации - по мере роста сложности, ИИ теряет контекст, забывает сделанное, новое создает, а старое перестает работать
Управление через спецификации
Spec-Driven Development - ответ на проблемы вайб-кодинга. Чтобы агенты могли разрабатывать более сложные системы, необходимо управлять контекстом - что делается, по каким правилам, с учетом каких ограничений.
Выделяют три уровня управления через спецификации:
| Уровень | Описание |
|---|---|
| L1 - Спецификация для старта (spec-first) | Работа начинается с создания спецификации, которая определяет задачу, далее план и решение задачи. Напоминает поток задач в Redmine, Jira. Спецификация используется для более точного однозначного описания задачи, после завершения уходит в архив. |
| L2 - Спецификация как ориентир (spec-anchored) | Спецификации используются как ориентир, после изменения спецификация обновляется. Соответствует лучшим практикам поддержки актуальной документации |
| L3 - Спецификация как истина (spec-as-source) | Ключевой переход - источник истины переходит с кода на спецификацию. Код автогенерируется агентами. |
Ключевые отличия последнего уровня:
- источник истины - на первых двух уровнях источником истины остается код, спецификации используются как дополнительный инструмент. На последнем уровне источником истины становится спецификация.
- создание кода - на первых двух код может писаться совместно, человек тоже может принимать участие, делать ревью и вносить правки в код. На последнем уровне человек не касается кода, код на 100% создается агентами, может быть пересобран под другую технологию или инструментарий.
Пример L1 - Github Spec-kit
Классический представитель - Github Spec-kit. Первый коммит в истории репозитория был сделан в августе 2025 года, через год, в августе 2026 фреймворк получил версию 1.0.0.
Базовый рабочий процесс идет по цепочке:
| Шаг | Описание |
|---|---|
| Определить - specify | Определите, что хотите сделать, фокус на что и почему (spec.md) |
| Спроектировать - plan | Проработайте технические вопросы (plan.md) |
| Декомпозировать - tasks | Декомпозируйте на задачи (tasks.md) |
| Реализовать - implement | Реализуйте задачи (tasks.md) |
| Проверить - converge | Проверьте результат (tasks.md) |
Дополнительно, в подходе есть управление базовыми правилами через конституцию проекта, настройка процессов (workflow) и предложение управлять разработкой сложных фич через спецификацию спецификаций (spec of specs).
Подход отлично работает для создания новых несложных проектов.
Пример из практики - команда корпоративного заказчика по итогам первого дня интенсива уже создала первую рабочую фичу нового мобильного приложения.
Пример L2 - OpenSpec
Ключевое отличие OpenSpec в том, что он может работать как изменения к существующему проекту или ранее созданным спецификациям.
Его основной процесс похож:
| Шаг | Описание |
|---|---|
| Исследование - explore | Изучить, что есть и обдумать идею в контексте существующего проекта (опционально) |
| Предложение - propose | От идеи до первичного плана реализации |
| Проверка плана - review | Проверка спецификации, плана до начала реализации |
| Реализация - apply | Реализация плана |
| Архивация - archive | Архивация рабочих артефактов изменений и обновление основных спецификаций проекта |
Важные элементы:
- упрощение команд - меньше детализации, меньше текста спецификаций, больше свободы агента
- спецификации и изменение - две разные сущности - specs - обновляемые спецификации, changes - изменения
- обновление спецификаций - встроенный механизм обновления спецификаций при архивации изменений
- исследование - для существующих проектов процесс начинается с исследования
Подход применим не только для новых проектов, но и отлично работает с уже существующей кодовой базой, для которой нет хорошей документации.
Пример из практики - для заказчика необходимо было сделать инструмент для записи тестов, за основу мною был взят Microsoft Playwright, клонирован и на его основе через OpenSpec был создан расширенный вариант Playwright Codegen.
Пример L3 - ScLab
Создавая Гипотезную, по мере роста функций, у меня возникли вопросы:
- как управлять растущей сложностью продукта? Если в продукте будет 20 фич, у каждой 10 требований, как отслеживать выполнимость 200 требований?
- как доверить разработку целиком ИИ, ведь я консультант, а не разработчик, заниматься кодом не хочу, но продукт должен быть надежным и безопасным.
SDD L3 должны были помочь, но исследование с ИИ не нашло готовых решений. Упоминаемый в статье Understanding Spec-Driven-Development: Kiro, Spec-kit, Tessl как spec-as-source подход Tessl еще в январе 2026 перепрофилировался на агентскую платформу (Agent Enablement Platform), решающую другие задачи.
Пришлось создавать свой фреймворк для управления созданием цифровых продуктов.
Основные элементы подхода:
| Элемент | Описание |
|---|---|
| Источники истины | Источник истины определяет правила и рамки, это спецификация, отделенная от кода. Ответственность человека, агенты помогают. |
| Свобода реализации | Агент свободен реализовывать код в заданных рамках и ограничениях. Модели совершенствуются и избыточное управление может замедлять и ухудшать работу. Зона работы агентов, человек не мешает. |
| Верификация | Механизмы проверки качества, безопасности и соответствия источникам истины. Человек определяет инструменты валидации, агенты используют. |
Три источника истины, три ограничивающие рамки:
| Рамка | Описание |
|---|---|
| Бизнес | Domain Driven Design - определяем единую терминологию, бизнес-правила, контекст, сценарии использования |
| Техническая | Архитектура, архитектурные решения (ADR), контракты (Contract-Driven Design), решения по безопасности (Security-by-Design) |
| Визуальная | DESIGN.md и формальный проверяемый дизайн системы |
Чтобы агентам было проще ориентироваться в источниках истины, используется структура OKF (Open Knowledge Format) и онтология, определяющая взаимосвязь сущностей.
Пример из практики. Финтех-компания предложила провести эксперимент-исследование по возможностям разработки сложных решений с помощью ИИ. Необходимо было сделать личный кабинет пользователя: мультиязычность, оплата через криптоплатежи, интеграция с биржей, торговый терминал, риск-менеджмент, игровая механика, upsell-опции, требования по безопасности и работе с персональными данными. Мой результат - продукт был создан в одиночку за 10 недель при занятости в районе 30% (параллельно с другими проектами). На входе было классическое ТЗ, дизайн-макет, документация по внешним сервисам и ключи доступа к ним. На выходе - полностью работоспособный продукт, покрытый более чем 200 сценариями автотестов, прошедший проверку заказчика и независимый аудит. Аналогичный продукт команда классическим подходом вручную делала более года.
Какой подход выбрать?
Универсальных решений нет, все зависит от уровня сложности вашей конкретной задачи.
Попробуете навайбкодить финансовый терминал - скорее всего получите проблемы с безопасностью и можете потерять деньги и клиентов. Будете использовать спецификации третьего уровня для простого лендинга - потратите много времени и оплаты токенов на спецификации, без которых можно было обойтись.
Базовые рекомендации:
| Подход | Примеры использования |
|---|---|
| Вайб-кодинг | Прототипы, типовые задачи, лендинги, персональные утилиты для личного использования. |
| Spec-kit и аналоги | Небольшие продукты, создаваемые “с нуля”, пилоты (mvp). |
| OpenSpec и аналоги | Доработка существующих продуктов (legacy), более сложные, поддерживаемые и изменяющиеся продукты. |
| Спецификации Spec-as-source | Разработка сложных цифровых продуктов с 100% генерацией кода и тестов через ИИ. |
Если вы не знаете, как эффективнее подойти к решению своей конкретной задачи, обращайтесь за консультацией, подскажу, при необходимости, вместе сделаем пилот и создадим ваш собственный подход к разработке с ИИ.
Часто задаваемые вопросы
Что такое вайб-кодинг?
При таком стиле разработки человек фокусируется на намерении - что он хочет получить, а искусственный интеллект - на реализации намерения.
Плюсы в том, что разрабатывать таким способом может человек без опыта программирования. Обратная сторона - большинство технических решений скрыты от вас, вы слабо влияете на их качество. Большинство взломов и проблем безопасности ИИ-разработки относятся именно к таким системам.
Вайб-кодинг отлично подходит для создания прототипов, тестирования гипотез, решения типовых простых задач - создать лендинг, телеграм-бота.