AI-driven SDLC: почему спецификация и harness решают всё

AI-ассистенты сокращают этап реализации с недель до часов, но сбор требований и финальная валидация остаются узким местом. Поэтому решающим фактором становится не выбор модели, а harness — правила, контекст, инструменты и quality gates вокруг неё.

Спектр подходов, а не переключатель

Уровень зрелости выбирается под задачу, а не только как эволюция разработчика.

Уровень	Характеристика	Спецификация	Верификация	Риск
Vibe Coding	Промпт без планирования, «выглядит — работает»	Неформальный natural language	Поверхностная проверка	Высокий, только для disposable-кода и MVP
Structured AI-Assisted	Детальные промпты, спот-чекинг	Детальные, но без формального процесса	Ручное тестирование, выборочное ревью	Средний
Agentic Engineering	Спроектированная система ресурсов и workflow	Формальные specs, архитектурные документы	Evals, CI-гейты, LLM judges, ревью агентом и человеком	Низкий, верификация на каждом этапе

Harness — 90% системы

Модель даёт примерно 10% результата, всё остальное — контролируемый разработчиком слой: инструкции, контекст, правила, инструменты, гайдрейлы, оркестрация и observability. Формула простая: agent = model + harness.

• Нижний слой (агент): LLM + инструкции + MCP-серверы + гайдрейлы + хуки для детерминированных действий.
• Средний слой (тестирование): evals, автономная итерация агента через тесты, гейты в CI/CD.
• Верхний слой (продакшен): трассировка, мониторинг, масштабирование.

Статический и динамический контекст

Контекстное окно — самый дефицитный ресурс, поэтому его наполнение разделяют.

• Статический контекст: правила, core-гайдрейлы, system prompt. Загружается всегда — надёжно, но дорого.
• Динамический контекст: skills, конвенции кодбазы, RAG-поиск. Загружается по требованию — эффективно, но агент может не подтянуть нужное вовремя.
• Правило: статический слой держим максимально lean, остальное отдаём в динамический через progressive disclosure.

Отсюда же следует отказ от сложных multi-agent систем: один агент-дженералист с динамически подгружаемыми навыками закрывает роли планировщика, кодера и код-ревьюера.

Процесс: factory model

Разработчик перестаёт писать код и PRD вручную — он проектирует систему, а агент производит код и документацию.

• Planning-агент и coding-агент работают в разных сессиях: первый превращает specs и требования в план-артефакт, второй реализует его в sandbox-окружении. Разделение защищает от context rot и накопленного bias.
• Цикл: build → тесты и верификация → автономная итерация агента → human review в pull request → deploy. Гайдрейлы (токен-лимиты, security-политики) действуют на всём протяжении.
• Два режима работы: conductor (пошаговое управление на уровне файлов, уместен при отладке) и orchestrator (параллельные агенты, ревью результатов). При зрелом harness можно жить преимущественно в режиме orchestrator.

Эволюция системы вместо разовых фиксов

При каждом сбое агента полезнее не «починить баг и пойти дальше», а провести ретроспективу: какое правило, workflow или гайдрейл предотвратит повторение. Harness живёт в version control и развивается вместе с кодом.

Экономика

Agentic engineering требует высокого CapEx — время на создание harness upfront, — но даёт низкий OpEx: меньше итераций и меньше сожжённых токенов на slop-код. Vibe coding устроен наоборот. Точка окупаемости достигается быстро: в долгую подход оказывается в 3–10 раз надёжнее и дешевле.

Практический вывод для команды: выделить небольшую forward-deployed группу, которая соберёт harness, и затем масштабировать его на всю организацию. Разницу между моделями (например, Sonnet и Opus) хороший harness во многом компенсирует — LangChain получил +13,7 пункта на SWE-bench только за счёт правил и workflow.

Источник

• AI-driven SDLC (видео)