От vibe coding к Spec-Driven Development: как приручить скорость ИИ и довести проект до продакшена

На связи Алексей Коржебин, ведущий архитектор в Управлении развития продуктов искусственного интеллекта X5 Tech. В отрасли я уже больше 30 лет. Застал времена, когда код писали на перфокартах (почти), и прошёл путь от разработки софта в разных доменах до архитектуры крупных платформ. Сейчас занимаюсь проектированием корпоративных информационных систем на базе искусственного интеллекта. Также активно внедряю технологии ИИ-агентов в процесс разработки ПО.

Мы все видим, как ассистенты и агенты меняют правила игры. То, что недавно называли «умной IDE» с подсказками, рефакторингом и статическим анализом, сегодня лишь разминка перед сбором функциональности. Ассистенты и агенты могут пройтись по десяткам файлов, обновить тесты и даже оформить базовую документацию. Но вместе с бешеной скоростью генерации пришёл и хаос. 

Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.

Дежавю из 90-х: почему «не доверять модели» — это нормально

У меня есть стойкое ощущение дежавю. В 90-е инженеры часто не доверяли компиляторам. Критичные участки писали на ассемблере: так казалось надёжнее, потому что было понятно, что делает процессор.

Сегодня мы слышим то же самое про ИИ: «Он сгенерировал код, но я не понимаю, что там внутри!». И это рационально. Мы научились доверять компиляторам не по доброте душевной, а потому что выстроили систему опор:

• юнит-тестирование;

• статический анализ;

• CI/CD пайплайны.

С генеративным ИИ происходит то же самое: скорость появилась первой, а культура управляемости только догоняет.

Генерация стала «режимом работы», а не одной функцией

Сегодня это уже не история «одного ассистента». Инструменты условно делятся на несколько классов.

• Ассистенты в IDE — быстрые подсказки, чат по коду, генерация тестов, локальный рефакторинг.

• Agentic-редакторы/IDE — когда инструмент работает задачами и уверенно делает многофайловые изменения.

• CLI-агенты — когда удобнее управлять процессом через терминал и сценарии, а не через UI.

Во всех случаях есть общая закономерность. Когда задача нечётко сформулирована, система сама пытается додумать, что делать. Для прототипа это даже бывает удобно, потому что можно быстро получить рабочий вариант. Но в продакшене это уже рискованно! Так как система может добавить лишние зависимости, случайные архитектурные решения или «удобные» допущения, которые вы не просили.

Поэтому следующий шаг выглядит логично: если генерация стала дешёвой, значит самыми дорогими становятся намерение и контроль качества.

Spec-Driven Development: структура поверх скорости

Spec-Driven Development (SDD) — это подход, который добавляет к vibe coding недостающие элементы управления. В простом виде он выглядит так:

идея → спецификация → план реализации → декомпозиция задач → код → проверки

Смысл не в бюрократии и не в толстых документах, а в том, что спецификация становится артефактом намерения, который:

• хранится в репозитории и версионируется;

• ревьюится как любой другой change;

• легко превращается в критерии приёмки и тесты;

• служит стабильным контекстом для человека и для агента.

На практике SDD обычно поддерживается набором простых шаблонов: спецификация, план, задачи. Есть и готовые «скелеты процессов» (например, подходы в стиле spec → plan → tasks), а также инструменты и IDE, где спецификация встроена в workflow. Суть у всех одна: сначала фиксируем намерение и критерии успеха, потом быстро реализуем по шагам.

Фреймворки и инструменты для SDD: что есть на рынке

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

• GitHub Spec Kit. По сути, это набор шаблонов и команд, который помогает пройти путь от спецификации к плану, затем к задачам и реализации. Подходит, когда хочется стандартизировать работу команды и заставить агента двигаться короткими проверяемыми шагами, а не «сразу всё и одним коммитом». Часто используется вместе с CLI-утилитой, которая умеет создавать структуру проекта и типовые файлы для спецификации/плана/задач.

• OpenSpec. Лёгкий «каркас» для работы со спецификациями, ориентированный на то, чтобы согласовать ожидания человека и агента до написания кода. Обычно нравится тем, кто хочет минимализм: меньше ритуалов, больше фокуса на ясной спецификации и небольших итерациях.

• IDE/среды со встроенным SDD-workflow (например, Kiro и похожие подходы). Здесь ставка на то, что дисциплина поддерживается не только договорённостью в команде, но и самой средой: она ведёт по этапам (спецификация → план → выполнение задач), подсказывает структуру, помогает не перескочить через шаги, где обычно рождаются ошибки и «скрытые предположения».

• Корпоративные ассистенты и Dev-платформы, которые добавляют SDD как режим работы. На практике многие команды делают свой «Spec Kit внутри компании»: шаблоны документов, правила оформления задач, чек-листы для ревью и интеграции с CI (чтобы спецификация и критерии приёмки реально влияли на мерж).

Если обобщить различия, то они обычно не в «магии генерации», а в том, где живёт контроль: в репозитории (шаблоны и файлы), в инструментах (CLI-команды), в среде разработки (встроенный workflow), либо в корпоративных правилах и пайплайнах. Выбирать стоит не по бренду, а по тому, какой уровень дисциплины нужен вашей команде и насколько важно, чтобы процесс был воспроизводимым для всех участников.

Практический пример: простой интернет-магазин на Python + FastAPI

Возьмём типичный MVP: каталог → корзина → оформление заказа → простая админка заказов. И сразу обозначим границы, чтобы генерация не превратилась в «продуктовый фанфик».

Что делаем в MVP

• каталог товаров и категории;

• карточка товара;

• корзина (хранится на клиенте);

• оформление заказа без регистрации;

• админка: список заказов, смена статуса.

Чего НЕ делаем в MVP

• личный кабинет и история заказов;

• промокоды, сложные скидки, рекомендации;

• интеграции с реальными платёжками/доставкой (на старте).

Это важнее, чем кажется: негативный промпт задает рамки для модели, ограничивая генерацию излишнего кода.

1) Спецификация (1–2 страницы): specification.md

Спецификация должна быть достаточно официальной, чтобы по ней можно было принять результат, и достаточно короткой, чтобы её реально поддерживали.

# Интернет-магазин (MVP)

## 1. Контекст

Нужен базовый интернет-магазин для продажи ограниченного ассортимента.

Цель — быстрый запуск с архитектурой, пригодной для дальнейшего развития.

## 2. Цели

1. Пользователь просматривает каталог и карточку товара.

2. Пользователь формирует корзину и оформляет заказ без регистрации.

3. Заказ сохраняется в базе данных и имеет статус: created/confirmed/canceled.

4. Администратор просматривает заказы и меняет статус.

## 3. Не-цели

• Личный кабинет и история заказов пользователя.

• Промокоды, сложные скидки, персональные рекомендации.

• Реальная интеграция с платёжными системами и доставкой (в MVP).

## 4. Пользовательские сценарии

S1. Каталог: список товаров, фильтр по категории, сортировка по цене.

S2. Карточка: цена, описание, остаток.

S3. Корзина: добавить/удалить/изменить количество; корзина хранится на клиенте.

S4. Оформление: имя и телефон обязательны; адрес обязателен для доставки курьером.

S5. Админка: список заказов, детали, смена статуса.

## 5. Бизнес-правила

• Цена фиксируется на момент создания заказа.

• Нельзя оформить заказ при недостаточном остатке.

• Персональные данные не записываются в логи.

## 6. Критерии приемки

• Все сценарии S1–S5 воспроизводимы через UI.

• Интеграционный тест создаёт заказ из типовой корзины.

• CI проходит (линтер + тесты).

• Документация описывает API и структуру данных.

2) План реализации: plan.md

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

# План реализации (Python + FastAPI + PostgreSQL)

## Компоненты

• FastAPI (REST API)

• PostgreSQL

• SQLAlchemy/SQLModel, Pydantic

• Alembic миграции

• pytest (unit + integration)

## Модель данных (минимум)

Product(id, title, description, price, stock, category_id)

Category(id, title)

Order(id, created_at, status, customer_name, customer_phone, address, delivery_type, total_price)

OrderItem(id, order_id, product_id, qty, price_at_purchase)

## Основные решения

• Корзина хранится на клиенте (localStorage). Сервер получает снимок корзины при создании заказа.

• Сервер проверяет stock, фиксирует price_at_purchase и рассчитывает total_price.

• Админка защищена простым механизмом (токен/Basic Auth) без отдельной модели пользователей (в MVP).

## Качество и наблюдаемость

• Unit-тесты: валидация заказа, проверка остатков, фиксация цены.

• Integration: POST /orders создаёт заказ на тестовых данных.

• Метрики: latency запросов, счётчик созданных заказов.

3) Декомпозиция задач: tasks.md

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

• T1: каркас FastAPI + healthcheck

• T2: модели БД + миграции Alembic

• T3: API каталога (товары/категории)

• T4: оформление заказа + тесты

• T5: админка заказов + защита

• T6: метрики/логи/README

4) Как это выглядит в коде (короткий фрагмент FastAPI)

Это не полный проект, а демонстрация того, как спецификация превращается в интерфейс и проверяемое поведение.

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field
from typing import List, Literal, Optional

app = FastAPI()

class CartItem(BaseModel):
    product_id: int
    qty: int = Field(gt=0)

class CreateOrderRequest(BaseModel):
    customer_name: str = Field(min_length=1)
    customer_phone: str = Field(min_length=5)
    delivery_type: Literal["pickup", "courier"]
    address: Optional[str] = None
    items: List[CartItem]

class OrderResponse(BaseModel):
    order_id: int
    status: Literal["created", "confirmed", "canceled"]
    total_price: int

@app.post("/orders", response_model=OrderResponse)
def create_order(req: CreateOrderRequest):
    if req.delivery_type == "courier" and not req.address:
        raise HTTPException(status_code=400, detail="Address is required for courier delivery")

 # Дальше по спецификации:

    # 1) проверить остатки

    # 2) зафиксировать price_at_purchase

    # 3) создать Order и OrderItem

    # 4) вернуть created + total_price

    return OrderResponse(order_id=1, status="created", total_price=0)

Как работать с агентом, чтобы результат был предсказуемым

В SDD полезное распределение ответственности выглядит так:

• человек утверждает спецификацию и план (то есть принимает продуктовые и архитектурные решения);

• агент реализует задачи небольшими шагами;

• CI проверяет качество и ловит регрессии.

Процесс получается спокойным:

1. сначала ревьюите спецификацию и план;

2. агент делает T1 → PR → вы ревьюите → CI прогоняет проверки → мерж;

3. дальше T2…T6.

В результате мы сохраняем высокую скорость генерации, не теряя управление процессом.

Базовые проверки качества генерации кода

Чтобы «не доверяю модели» перестало быть аргументом, нужна простая база:

• линтер/форматирование;

• unit-тесты на ключевые правила;

• интеграционный тест оформления заказа;

• проверка зависимостей (минимум);

• правило: изменилось поведение — обновилась спецификация.

И отдельно про персональные данные: даже в маленьком магазине стоит заранее прописать запрет на логирование телефона и адреса в открытом виде. Это та мелочь, которая потом экономит очень много нервов.

Вывод: кем станет программист в 2026 году?

Писать код руками будут всё меньше. Не потому, что это не нужно, а потому что производство кода стремительно дешевеет, а центр тяжести смещается в сторону проектирования.

Роль разработчика становится ближе к инженеру-проектировщику. Главные навыки теперь:

• Умение переводить бизнес-хотелки в ясные контракты.

• Проектирование границ модулей, чтобы система была расширяемой и наблюдаемой.

• Построение контура качества (тесты, статический анализ, CI, метрики), который делает изменения безопасными.

• Управление агентами как производственной мощностью.

Vibe coding – отличный ускоритель для одноразовых скриптов и быстрых гипотез. Поэтому он может выродиться в класс «одноразовых программ», которые создаются на лету под конкретный запрос (иногда на несколько минут), выполняют задачу и исчезают. Такой софт будет напоминать «скрипт по требованию». Нужен отчёт — он собрался и отработал, завтра нужен другой — собрался заново. Но всё, что должно жить долго (сервисы, финтех, платформы), будет строиться через Spec-Driven Development. Потому что когда код становится дешёвым и быстрым в производстве, в узкое место превращается контроль качества — и цена промаха в продакшене резко растёт.

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

А как вы контролируете то, что «выплёвывает» ваш ИИ-ассистент? Пишете тесты или доверяете «вайбу»? Делитесь в комментариях!

А если вам интересна тема ИИ-агентов в энтерпрайзе, то мы готовим несколько материалов про наши внутренние бенчмарки LLM, и скоро они появятся в блоге, не пропустите.