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

AI-ассистенты переносят бутылочное горлышко SDLC с написания кода на сбор требований и верификацию. Спектр подходов — от vibe coding до agentic engineering — зависит не от модели, а от harness: правил, контекста, инструментов и quality gates. Инвестиции в инженерную обвязку окупаются за счёт снижения числа итераций и расхода токенов.

Материал основан на видео Кола о спектре AI-кодинга и объясняет, почему качество инженерной обвязки важнее конкретной LLM. Ниже — ключевые тезисы и их практическое применение.

AI-управляемый SDLC и смена узкого места

В классическом SDLC основное время уходит на реализацию: дни на требования и дизайн, недели на код и тестирование. AI-ассистенты сокращают этап реализации с недель до минут или часов, но узким местом теперь становятся сбор требований и финальная валидация. Разработчику приходится вкладываться не в написание строк, а в качество спецификации и проверку результата.

Спектр зрелости: от vibe coding к agentic engineering

AI-кодинг — это не переключатель, а три уровня зрелости, которые применяются под конкретную задачу:

Уровень	Спецификация	Верификация	Риск
Vibe Coding	Неформальный natural language	Поверхностная проверка	Высокий, подходит только для disposable-кода или MVP
Structured AI-Assisted	Детальные промпты без формального процесса	Ручное тестирование, выборочный спот-чекинг	Средний
Agentic Engineering	Формальные спеки, архитектурные документы, воспроизводимый процесс	Автоматические evals, CI-гейты, LLM-судьи, код-ревью агентом и человеком	Низкий за счёт системной верификации на каждом шаге

Разница между уровнями — не в модели, а в том, насколько формализованы вход и проверка результата.

Экономика токенов: CapEx против OpEx

Agentic engineering требует высоких капитальных затрат на создание harness заранее, но снижает операционные расходы: меньше итераций, меньше токенов уходит на бесполезный код и исправления. Vibe coding, наоборот, дёшев на старте, но дорого обходится в обслуживании, безопасности и повторных проходах. По оценкам из видео, agentic engineering в 3–10 раз надёжнее и дешевле vibe coding в долгосрочной перспективе, поэтому точка окупаемости наступает быстро.

Harness как основной актив: Agent = Model + Harness

Модель — это лишь около 10% системы. Остальные 90% приходятся на управляемый разработчиком слой: инструкции, контекст, правила, инструменты, гайдрейлы, оркестрацию и наблюдаемость. Такой подход совпадает с позицией Anthropic в Claude Code: harness значит не меньше, чем сама модель.

Harness состоит из трёх слоёв:

нижний — агент: LLM, инструкции, MCP-серверы, гайдрейлы и хуки для детерминированных действий в lifecycle;
средний — тестирование: evals, автономные итерации агента по тестам, CI/CD-гейты;
верхний — продакшен: наблюдаемость, трассировка, масштабирование и мониторинг.

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

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

статический контекст: правила, core-гайдрейлы и system prompt загружаются гарантированно каждый раз. Это надёжно, но дорого и быстро забивает окно;
динамический контекст: skills, конвенции кодовой базы и RAG-поиск загружаются по требованию. Это эффективно и масштабируемо, но агент может не подгрузить нужное вовремя.

Динамические навыки реализуют принцип progressive disclosure: лёгкий агент-дженералист по требованию превращается в специалиста — код-ревьюера, планировщика или другую роль. Это проще и надёжнее, чем строить сложную multi-agent систему из узких агентов.

Процесс: фабричная модель и разделение планирования и кодинга

В зрелом agentic engineering разработчик проектирует систему и harness, а агент производит код и документацию. Инвестиция upfront в спеки и гайдрейлы даёт воспроизводимый цикл Plan → Build → Quality Gates.

Принципиально разделяются две сессии:

planning agent получает спеки, контекст и требования, создаёт план как отдельный артефакт;
coding agent получает этот план, гайдрейлы и sandbox-окружение, реализует его.

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

После сборки цикл проходит через Quality Gates: тесты и верификация, автономные исправления агентом, затем обязательный human review в виде pull request. Гайдрейлы — лимиты токенов, security-политики — действуют на всём протяжении процесса.

Эволюция системы и два режима разработчика

При каждом сбое вместо точечного фикса нужно проводить ретроспективу с агентом: какие правила, воркфлоу или гайдрейлы изменить, чтобы проблема не повторялась. Harness эволюционирует как код — живёт в version control и улучшается с каждым циклом.

Разработчик может действовать в двух режимах:

conductor — микроменеджмент на уровне отдельных файлов и пошаговое управление; подходит для глубокой отладки и начального исследования;
orchestrator — агенты работают параллельно над целыми кодовыми базами, а разработчик ревьюит результаты, а не построчные изменения.

Google рекомендует перемещаться между режимами, но при зрелом harness можно постоянно жить в режиме orchestrator.

Практические выводы

Harness — главная инженерная инвестиция. Правильный harness способен компенсировать разницу между моделями: по данным из видео, LangChain получил прирост в 13.7 пункта на SWE-bench только за счёт правил и воркфлоу.

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

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

Для внедрения имеет смысл выделить forward-deployed команду, которая создаст harness, а затем масштабировать подход на всю организацию. Несмотря на высокий начальный CapEx, долгосрочно это надёжнее и дешевле vibe coding.