«The New SDLC With Vibe Coding» — саммари на русском

Что это. 50-страничный whitepaper от Google (Day 1-материал для 5-дневного курса Google × Kaggle по AI-агентам). Авторы — Addy Osmani, Shubham Saboo и Sokratis Kartakis. Первый документ в короткой серии.

Главный тезис в одну строку: «Генерация кода в основном решена. Новое ремесло — это верификация, суждение и направление».

Ниже — ключевые идеи, собранные из авторского саммари Османи (он сам выделил из статьи то, что считает важным). Это не полный перевод whitepaper, а сжатая выжимка сути.

Первоисточники (оба бесплатные, без paywall):

• Полный whitepaper: https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding
• Авторское саммари Османи с 6 схемами: https://addyosmani.com/blog/new-sdlc-vibe-coding/

1. Вайб-кодинг и агентная инженерия — это спектр, а не два разных инструмента

Спектр от вайб-кодинга (слева) до агентной инженерии (справа). Различитель — не факт использования ИИ, а способ верификации результата.

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

• Левый конец (вайб-кодинг): casual-промпты, критерий корректности «вроде работает», одноразовый код, высокий риск. Нормально для прототипа или хакатона.
• Правый конец (агентная инженерия): формальные спецификации, автоматические эвалы, CI/CD-гейты, продакшн-системы в масштабе. Низкий риск.

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

«Тест CTO»: сказать CTO, что команда вайб-кодит платёжную систему, — должно (и обязано) включить тревогу. Сказать, что команда практикует агентную инженерию, где ИИ реализует под человеческими ограничениями и тесты гарантируют корректность, — совсем другой разговор.

2. Агент = Модель + Обвязка (harness)

Агент = Модель + Обвязка. Модель — ~10%, обвязка (правила, инструменты, оркестрация, guardrails, observability) — ~90%.

Формула, к которой автор постоянно возвращается. Модель — это лишь один вход. Всё остальное — обвязка:

• инструкции и rule-файлы;
• инструменты и MCP-серверы;
• песочницы, в которых агент работает;
• оркестрационная логика (порождение суб-агентов, роутинг между моделями);
• хуки, запускающие детерминированный код в заданных точках;
• observability, которая показывает, когда агента «уносит».

Грубая пропорция из статьи: ~10% — модель, ~90% — обвязка. Звучит завышенно, пока не потратишь неделю на отладку одной обвязки.

Публичные цифры, делающие это конкретным:

• На Terminal Bench 2.0 одна команда подняла кодинг-агента с позиции за пределами топ-30 в топ-5, поменяв только обвязку — модель под ней осталась той же.
• Эксперимент LangChain добавил +13.7 балла на том же бенчмарке, изменив лишь системный промпт, инструменты и middleware вокруг фиксированной модели.

Практический вывод: когда агент делает глупость — сначала дебажь обвязку, а не модель. Обычно причина — недостающий инструмент, слишком расплывчато написанное правило, забытый ограничитель или контекстное окно, забитое мусором. Большинство сбоев агента — это сбои конфигурации. И это хорошая новость: конфигурацию можно чинить прямо сейчас, не дожидаясь модели получше (её всё равно рано или поздно заменят под той же обвязкой).

3. Контекст-инжиниринг — то, что решает и качество, и счёт

Шесть типов контекста и деление на статический (грузится всегда, дорого) и динамический (по требованию, дёшево).

Если обвязка — это система, то контекст-инжиниринг — самая важная ручка внутри неё. Статья делит контекст агента на 6 типов: инструкции, знания, память, примеры, инструменты, ограничители (guardrails).

Ключевое (и влияющее на счёт) решение — что кладём в статический, а что в динамический контекст:

• Статический контекст грузится на каждый вызов: системные инструкции, rule-файлы (AGENTS.md, CLAUDE.md, GEMINI.md), глобальная память, базовые ограничители. Надёжно — и дорого, потому что платишь за него каждый раз.
• Динамический контекст грузится по требованию: скиллы, срабатывающие под конкретную задачу; результаты вызова инструментов; документы из RAG. Платишь только за то, что нужно данной задаче.

Перекос в одну сторону — жжёшь токены и хоронишь сигнал в шуме. Перекос в другую — агент забывает правила, которые держат его в безопасности. Совет статьи: относиться к этой границе как к настоящему архитектурному решению — ревьюить в пул-реквесте и версионировать как код.

Трюк, который позволяет динамическому контексту масштабироваться — Agent Skills с прогрессивным раскрытием: агент видит немного метаданных на старте, подгружает полные инструкции при совпадении с задачей, и тянет тяжёлый справочный материал только когда он реально нужен. Так один агент может нести десятки скиллов, но платить лишь за тот, что использует.

4. Верификация — это и есть граница между вайб-кодингом и инженерией

Есть два механизма проверки:

• Тесты покрывают детерминированные части: этот вход → тот выход.
• Эвалы (evals) покрывают недетерминированные части. Статья делит их полезным образом:
  • Оценка результата (output evaluation): корректен ли финальный результат.
  • Оценка траектории (trajectory evaluation): был ли здравым путь, которым агент к нему пришёл — вызовы инструментов и рассуждения.

Нужны оба. Ответ, который выглядит правильным, но пропустил свои проверки, опаснее очевидно сломанного.

Строка для руководителя: ставь планку на эвале, а не на демо. Демо показывает, что агент может сработать один раз. Набор эвалов с реальным rubric показывает, что он работает надёжно.

5. Как меняется каждая фаза SDLC

Традиционный итеративный SDLC против ИИ-driven: реализация схлопывается в минуты-часы, узкое место — качество спецификации, добавляется шаг эвалов (результата и траектории).

ИИ сжимает жизненный цикл, но неравномерно — и вся суть именно в этой неравномерности. Реализация падает с недель до часов. Требования, архитектура и верификация остаются медленными, потому что это работа суждения. Итог: качество спецификации становится узким местом, а верификация переезжает в середину процесса.

• Требования перестают быть документом, который передают между командами. Становятся разговором, который одновременно рождает и спецификацию, и первый прототип. Агент набрасывает user stories из брифа, вскрывает пограничные случаи, за минуты превращает описание в работающий прототип.
• Архитектура — самая упрямо-человеческая фаза. Компромиссы вроде «согласованность против доступности» зависят от бизнес-контекста, который модель не видит целиком. Задача разработчика — принимать и документировать структурные решения, которые агент затем реализует.
• Реализация — здесь живут и выигрыши, и оговорки. Опросы дают прирост продуктивности 25–39%. При этом исследование METR зафиксировало, что опытные разработчики на части задач были на 19% медленнее, если посчитать время на проверку и починку. Оба факта верны. Честная формулировка: ИИ превращает реализацию из написания в ревью.
• Тестирование и QA переворачиваются. Твои тесты и эвалы становятся главным способом объяснить агенту, что такое «правильно», встроенным в цикл: прогнать по бенчмарку → кластеризовать провалы → починить промпт или инструмент, вызвавший их → проверить по регрессионному набору → следить за продакшном на предмет новых.
• Поддержка — самая недооценённая, по мнению автора. Код, который был «слишком рискованно трогать», потому что его понимали только авторы, теперь может быть прочитан, отрефакторен и модернизирован агентом. Начинают происходить те миграции и чистки deprecation, которые раньше не делались из-за занудности и риска.

Потолок всего этого — проблема 80%: агенты быстро берут первые 80% фичи, а последние 20% (пограничные случаи и стыки между системами) всё ещё требуют контекста, которого у моделей обычно нет.

6. Экономика: контекст и роутинг — это финансовые рычаги, а не только технические

Совокупная стоимость владения во времени. Вайб-кодинг — низкий CapEx и быстрый старт, но крутой рост. За точкой пересечения он стоит в 3–10 раз дороже за фичу.

Цифра, важная для руководителя, — не скорость (velocity), а совокупная стоимость владения (TCO). И ИИ-эра делит её так, что переворачивает привычную интуицию о том, что дёшево.

Вайб-кодинг дёшев на старте и дорог в эксплуатации. Платишь почти ничего, чтобы начать (подписка и пара промптов). А потом платишь позже:

• token burn — от того, что кидаешь модели неструктурированные файлы и просишь чинить собственные ошибки;
• налог на поддержку — когда кому-то через месяцы приходится реверс-инжинирить ad-hoc код;
• чистка безопасности — быстрая генерация плодит уязвимости примерно так же быстро, как фичи.

Агентная инженерия переворачивает это: больше вложений на старте (схемы, тесты, структурированный контекст), меньше затрат на каждую последующую фичу.

Кривые CapEx/OpEx пересекаются в точке, за которой вайб-кодинг начинает стоить в 3–10 раз дороже за фичу. (Важно: цифра «3–10x» — иллюстративная, а не измеренная константа.) Сколько коду предстоит прожить — вот что решает, дойдёшь ли ты вообще до этой точки пересечения.

Практический рычаг: нельзя пихать репозиторий на 100 000 токенов в каждый промпт и ждать, что это отмасштабируется. Роутинг: тяжёлые рассуждения — на большую модель, рутину (генерация тестов, ревью кода, CI-проверки) — на маленькую и дешёвую. Качество держится, счёт падает.

7. Прототип становится продакшн-агентом

Тот же терминальный воркфлоу, что выплёвывает одноразовый скрипт, теперь может произвести продакшн-агента — в том же месте, часто просто разговаривая с тем кодинг-агентом, которым ты уже пользовался.

Раньше собрать, отэвалить и задеплоить настоящего агента (с персистентной памятью, ограниченными правами, покрытием эвалами и observability) — это был отдельный стек и отдельная работа. Теперь это сворачивается в тот же цикл. Пример из статьи — Google Agents CLI: после разовой установки кодинг-агент подхватывает скиллы на весь жизненный цикл, и ты управляешь им на естественном языке (собрать → отэвалить на датасете → задеплоить на managed-рантайм). Координация между агентами — на открытых стандартах: MCP для инструментов, A2A для передачи работы другим агентам.

Показательный эксперимент из статьи: команда Anthropic силами группы агентов за две недели собрала работающий компилятор C на Rust — люди задавали направление и ревьюили, а не писали код. Примерно так выглядит вектор развития.

Два режима работы (в статье — «дирижёр» и «оркестратор»):

• Дирижёр (conductor) — реального времени, в IDE, клавиша за клавишей. Хорош для исследования и для кода, который ты пока не знаешь.
• Оркестратор (orchestrator) — асинхронный: отдаёшь цель одному или нескольким агентам и ревьюишь результат. Хорош для чётко специфицированной работы — миграции, генерация тестов.

Переход от дирижёра к оркестратору — это в первую очередь сдвиг навыков, и только потом сдвиг инструментов.

8. Цифры для скептиков

Эволюция от автодополнения (~2021) к автономным агентам (~2025–26): по горизонтали — от синтаксиса и большего человеческого труда к намерению и большей автономии машины.

Данные по внедрению, которые обычно заканчивают спор «а это вообще уже реально»:

• 85% профессиональных разработчиков регулярно используют ИИ-кодинг-агентов;
• 51% используют их ежедневно;
• ~41% нового кода генерируется ИИ.

(Данные на начало 2026 года.)

Главный вывод

ИИ усиливает ту инженерную культуру, в которую попадает — и хорошие её части, и плохие. Генерация в основном решена. Оставшаяся работа — это спецификация и верификация, и системы, которые их держат вместе. Именно в этом стоит становиться сильным.