Новый SDLC
с вайб-кодингом

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

Введение

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

Пришла новая парадигма, в которой разработчики выражают, что они хотят построить, а не как это строить. Реализацию берёт на себя машина. Человек отвечает за замысел, архитектуру и суждение. Это не далёкое будущее — это повседневная реальность для быстро растущего числа профессиональных разработчиков. На начало 2026 года 85% профессиональных разработчиков регулярно используют кодинговых ИИ-агентов, 51% — ежедневно, а по оценкам, 41% всего нового кода сгенерирован ИИ.¹

Этот сдвиг произошёл не за одну ночь. Всё началось с автокомплита — простого предсказания токенов в редакторе. Затем появились инлайн-подсказки кода, способные дописать целые функции. Дальше — чат-интерфейсы, позволявшие описывать фичи на естественном языке и получать рабочую реализацию. Теперь полностью автономные агенты могут клонировать репозитории, планировать изменения сразу в нескольких файлах, выполнять их в песочнице, прогонять тесты и отправлять пул-реквесты — и всё это без единой строки, написанной человеком вручную.

Последствия для жизненного цикла разработки ПО (SDLC) огромны. Каждый этап — от сбора требований до деплоя и поддержки — переосмысляется под возможности ИИ. Но эта трансформация не однородна и не проста. Спектр простирается от казуального «вайб-кодинга», где разработчик что-то промптит у ИИ и принимает всё, что вернулось, до дисциплинированной «агентной инженерии», где ИИ выступает мощным движком реализации внутри тщательно спроектированных систем ограничений, тестов и петель обратной связи, а человек сохраняет контроль над архитектурой, корректностью и качеством.

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

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

Зачем эта статья и почему сейчас

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

Для кого эта статья

Эта статья — для инженеров-программистов, инженерных менеджеров, архитекторов и технических руководителей, которые хотят понять, как ИИ меняет SDLC, и освоить эти новые возможности, не жертвуя дисциплиной, которой требует продакшен-код. Мы предполагаем знакомство с современными практиками разработки, но не с конкретикой ИИ или машинного обучения.

Сдвиг от синтаксиса к замыслу

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

ИИ-агенты: краткое напоминание

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

Любой агент, простой или сложный, состоит из пяти частей. Технический документ «Introduction to Agents» от ноября 2025 года разбирает каждую из них подробно.¹¹ Для наших целей — краткая версия:

• Модель — это движок рассуждения. Она читает текущий контекст, решает, что должно произойти дальше, и порождает следующую мысль, следующий вызов инструмента или следующее сообщение.
• Инструменты связывают модель с миром. Это API, которые агент может вызывать, код, который он может выполнять, базы данных, к которым может обращаться, и другие агенты, которым может делегировать.
• Память — это состояние. Она позволяет агенту вспоминать прошлые взаимодействия, доставать специфичные для проекта правила и удерживать контекст между сессиями, чтобы никогда не начинать с чистого листа.
• Оркестрация — это код, который крутит цикл. Он собирает контекст для каждого вызова модели, отправляет вызовы инструментов, фиксирует их результаты и решает, продолжать ли.
• Деплой — это то, что превращает прототип в сервис: хостинг, управление идентификацией, наблюдаемость и продакшен-инфраструктура, на которой работает агент.

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

Что такое вайб-кодинг?

В феврале 2025 года Андрей Карпатый опубликовал описание нового способа программирования, которое нашло широкий отклик в сообществе разработчиков. Он описал подход, при котором вы «полностью отдаётесь вайбу, ловите экспоненту и забываете, что код вообще существует». В этом режиме разработчик описывает желаемое на естественном языке, принимает ответ ИИ, а когда что-то ломается, копирует сообщение об ошибке обратно в промпт и просит ИИ это починить.²

Термин стал вирусным, потому что ухватил нечто реальное: многие разработчики уже работали так, но не имели для этого слова. За считанные месяцы «вайб-кодинг» стал расхожим обозначением любого процесса разработки с ИИ — и это породило путаницу. Можно ли назвать «вайб-кодингом» работу старшего инженера, который с помощью ИИ-ассистента реализует чётко описанную фичу? А команду, использующую ИИ-агентов для исполнения тщательно спланированной архитектуры? Термин применяли так широко, что он начал терять смысл.

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

Спектр: от вайб-кодинга к агентной инженерии

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

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

Контекст-инжиниринг (context engineering): настоящий навык

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

Разработчикам нужно учитывать шесть основных типов контекста:

• Инструкции: ключевая роль агента, его цели и операционные границы.
• Знания: найденные документы, архитектурные диаграммы и предметные данные.
• Память: краткосрочные логи сессии (что только что произошло) и долгосрочное постоянное состояние (что представляет собой проект).
• Примеры: few-shot-демонстрации поведения и эталонные паттерны из кодовой базы.
• Инструменты: точные определения API, скриптов и внешних сервисов, которые агент может вызывать.
• Гардрейлы: жёсткие ограничения, правила форматирования и проверки безопасности.

В генерации кода с ИИ контекст-инжиниринг состоит в тщательной балансировке: какие из этих шести элементов агент держит заранее, а какие может подтянуть по запросу. Это создаёт критичное разделение между статическим и динамическим контекстом.

Статический контекст загружается всегда: системные инструкции, файлы правил (AGENTS.md, CLAUDE.md, GEMINI.md), глобальная память и определения персон. Он задаёт, кто такой агент и как он себя ведёт. Статический контекст дорог, потому что каждый его токен присутствует в каждом взаимодействии независимо от релевантности.

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

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

Самый мощный паттерн для управления динамическим контекстом — скиллы агента (Agent Skills): структурированные, переносимые пакеты процедурного знания, которые агент загружает только тогда, когда этого требует задача.

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

Скиллы агента быстро прижились в крупных кодинговых агентах и корпоративных платформах, потому что решают четыре проблемы, которые давно мешали разработке ИИ-агентов:

• Деградация контекста (context rot) из-за перегруженных промптов
• Отсутствие процедурной памяти у LLM
• Операционные накладные расходы мультиагентных архитектур
• Потребность в переносимости между инструментами и вендорами

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

Сопутствующая статья этой серии (День 3) — «Context Engineering: Sessions, Skills & Memory» — развивает каждую из этих идей дальше: как проектировать и вести сессии, писать и оценивать скиллы, выстраивать постоянную память между взаимодействиями и оптимизировать экономику токенов для продакшен-систем.

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

Контекст-инжиниринг — это мост между вайб-кодингом и агентной инженерией. А ещё это мост между этим разделом и следующим, где мы посмотрим на структуру, которая окружает любую модель и делает её полезной.

Сместив фокус с написания синтаксиса на инженерию этого контекста, мы принципиально меняем узкие места в создании ПО. Мы больше не ждём, пока человеческие руки наберут шаблонный код; мы ждём, пока человеческий разум очертит границы. Это требует полного переосмысления традиционного жизненного цикла разработки ПО (SDLC), ведь системы, которыми мы строим софт, теперь диктуют и скорость его поставки.

Новый жизненный цикл разработки ПО

Традиционный SDLC под давлением

Жизненный цикл разработки ПО уже проходил одну крупную трансформацию. За последние два десятилетия большинство компаний перешли от последовательного «водопада» к итеративным моделям: спринты Agile, непрерывная интеграция, DevOps-пайплайны и быстрые циклы релизов. Этот сдвиг укоротил петли обратной связи, приблизил тестирование к разработке и превратил деплой из ежеквартального события в непрерывный процесс.

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

Замечание о темпе перемен: Поэтапная картина, описанная выше, отражает состояние SDLC на основе ИИ на середину 2026 года. Оно меняется быстро. Ранние признаки говорят, что сжатие распространится за пределы реализации: команды уже экспериментируют с процессами, где разработчики идут прямо от спецификаций к ревью, а ИИ-агенты в фоне берут на себя реализацию, тестирование и деплой. Границы, проведённые в этом разделе, через 12 месяцев могут выглядеть иначе. Неизменными останутся человеческое суждение, вкус и навык проверять результат ИИ по мере того, как машины берут на себя всё больше реализации.

Как ИИ преображает каждый этап

Требования и планирование

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

Современные ИИ-инструменты могут участвовать прямо в проработке требований: генерировать пользовательские истории из продуктовых брифов, находить краевые случаи, которые упускают люди, выдавать схемы API из описаний на естественном языке и собирать интерактивные прототипы из документов-спецификаций. Агентные среды разработки позволяют пройти путь от описания до рабочего прототипа за минуты, сжимая петлю «требования → прототип» почти до нуля.

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

Проектирование и архитектура

Архитектура остаётся самым упрямо человеко-центричным этапом SDLC, и не без причины. Архитектурные решения по сути своей о компромиссах: согласованность против доступности, сложность против гибкости, написать самим против купить готовое. Эти компромиссы зависят от бизнес-контекста, организационных ограничений и долгосрочных стратегических соображений, которые ИИ не способен полностью охватить.

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

Реализация

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

Картина тоньше, чем подсказывают громкие цифры. Исследование METR показало, что опытные разработчики с ИИ-ассистентами на некоторых задачах тратили на 19% больше времени — во многом из-за времени на проверку, отладку и исправление результата ИИ.¹⁰ ИИ не столько устраняет работу по реализации, сколько превращает её из написания в ревью, направление и проверку.

Тестирование и контроль качества

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

ИИ преображает и саму генерацию тестов. Агенты могут создавать тест-кейсы, включая краевые случаи и property-based-тесты, о которых человек мог бы и не подумать. Что важнее, тесты и эвалы становятся главным механизмом передачи замысла ИИ-агентам: хорошо написанный набор эвалов сообщает ИИ, что значит «правильно», и даёт автоматический способ это проверить.

Эти практики наиболее эффективны, когда встроены в непрерывный маховик качества: прогнать по эталонному набору, диагностировать сбои, кластеризуя первопричины, оптимизировать вызвавшие их промпты или инструменты, проверить исправления на регрессионном наборе и мониторить продакшен-трафик на новые виды сбоев. Каждый цикл усиливает эффект.

Ревью кода и деплой

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

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

День 5 этой серии разбирает, что меняется для рецензентов-людей, когда объём пул-реквестов растёт вместе с выработкой агентов: сгруппированные сводки, условный LGTM, скиллы для код-ревью под управлением агентов.

Поддержка и развитие

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

Это серьёзно влияет на технический долг. Код, который считался «слишком рискованным, чтобы его трогать», потому что его понимали только авторы, теперь можно безопасно рефакторить, модернизировать и расширять. ИИ-агенты могут систематически мигрировать кодовые базы между фреймворками, обновлять устаревшие API и модернизировать наборы тестов — задачи, прежде настолько нудные и рискованные, что они попросту никогда не делались.

Фабричная модель: строим систему, которая строит ПО

Мысленная модель, связывающая эти трансформации воедино, — то, что мы называем фабричной моделью. В ней главный продукт разработчика не код, а система, которая производит код. Эта система включает:⁸

• Спецификации и контекст, определяющие, что нужно построить
• Агенты, превращающие спецификации в реализацию
• Тесты и гейты качества, проверяющие корректность
• Петли обратной связи, возвращающие сбои агентам на исправление
• Гардрейлы, удерживающие агентов в безопасном, предсказуемом поведении

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

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

Если разработчик — управляющий фабрикой, то ИИ-модель — лишь обычный двигатель в цеху. Двигатель сам по себе не соберёт автомобиль; ему нужны ремни, шестерни, датчики безопасности и конвейер. В контексте разработки с ИИ эта окружающая машинерия называется харнессом (harness).

Харнесс-инжиниринг: что окружает модель

Когда разработчики начинают работать с ИИ-агентами, возникает соблазн считать, что система — это модель. Выходит новая модель — агент умнеет. Модель постарее — агент тупеет. Модель становится объяснением всего хорошего и плохого.

Эта интуиция неверна и ведёт к неправильным инвестициям. Модель — лишь один вход в работающего агента. Всё остальное — промпты, инструменты, политики контекста, хуки, песочницы, суб-агенты, наблюдаемость — это харнесс: скаффолдинг (scaffolding), обёрнутый вокруг модели, который и позволяет ей реально что-то доводить до конца.¹¹

Полезное уравнение:

Сырая модель — это не агент. Она становится агентом, когда харнесс даёт ей состояние, исполнение инструментов, петли обратной связи и принудительные ограничения. Поведение, которое разработчики наблюдают, работая с Claude Code, Cursor, Codex, Antigravity, Aider или Cline, определяется прежде всего тем, что делает харнесс, а не только тем, какая модель под капотом.

Что входит в харнесс

Если конкретно, харнесс включает:

• Инструкции и файлы правил: текст, определяющий, кто такой агент, что для него важно и что ему запрещено делать. Сюда входят AGENTS.md, CLAUDE.md, GEMINI.md, файлы скиллов и промпты суб-агентов.
• Инструменты: функции, MCP-серверы и API, которые агент может вызывать, плюс окружающий их текст, который говорит модели, когда и как их вызывать.
• Песочницы и среды исполнения: где на самом деле выполняется код агента, к чему у него есть доступ, до чего он дотянуться не может.
• Логика оркестрации: порождение суб-агентов, роутинг моделей, передачи между специалистами и правила, определяющие, когда срабатывает каждый из них.
• Гардрейлы или хуки: детерминированный код, выполняемый в определённых точках жизненного цикла: перед вызовом инструмента, после правки файла, перед коммитом. Хуки — место для того, что агент никогда не должен забывать, но часто забывает.
• Наблюдаемость: логи, трассировки, оценки, измерение стоимости и задержек. Без наблюдаемости нельзя понять, хорошо ли справляется агент или тихо дрейфует в сторону.

Если кажется, что это большая площадь ответственности, — так и есть. И это площадь ответственности команды, а не поставщика модели.

Харнесс в SDLC

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

Вот как харнесс активно работает на разных этапах нового SDLC:

1. Требования, планирование и архитектура (настройка харнесса)

Здесь харнесс настраивается и калибруется. Прежде чем ИИ напишет хоть строку продакшен-кода, разработчик должен настроить окружение агента.

• Настройка харнесса: предоставление инструкций и файлов правил (например, создание AGENTS.md и задание архитектурных ограничений), которые харнесс загрузит и сделает доступными модели.
• Действие: разработчик определяет инструменты, к которым у агента будет доступ (например, конкретные API или схемы баз данных), и задаёт фундаментальные правила, которые агент не может нарушить.

2. Реализация (запуск харнесса)

Во время активного написания кода харнесс выступает границей, которая удерживает ИИ-модель сфокусированной, безопасной и продуктивной.

• Используемые компоненты харнесса: песочницы, среды исполнения и инструменты.
• Действие: по мере того как модель генерирует код, она выполняет его в изолированной песочнице харнесса. Если модели нужно прочитать файл или поискать в вебе, она пользуется инструментами, предоставленными харнессом.

3. Тестирование и QA (петля обратной связи)

Тестирование в агентном воркфлоу сильно опирается на харнесс, чтобы обеспечить автономную самокоррекцию.

• Используемые компоненты харнесса: логика оркестрации и гардрейлы.
• Действие: когда агент пишет функцию, харнесс предоставляет среду исполнения (например, терминал в песочнице), позволяющую запускать автоматические тесты. Если тест падает, логика оркестрации захватывает сообщение об ошибке из этой среды и возвращает его модели, прося попробовать снова. Именно харнесс создаёт этот автоматический цикл «подумать → действовать → наблюдать».

4. Ревью кода, деплой и поддержка (наблюдение за харнессом)

Даже после того как код написан, харнесс гарантирует, что агент ведёт себя безопасно в боевых или близких к боевым средах.

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

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

Эффект такой осознанной настройки хорошо измерим. Публичные бенчмарки делают величину эффекта харнесса конкретной. На Terminal Bench 2.0 одна команда подняла кодингового агента из-за пределов топ-30 в топ-5, изменив только харнесс — без какой-либо смены модели. Отдельное исследование в LangChain подняло результат кодингового агента на том же бенчмарке на 13,7 пункта, настроив лишь системный промпт, инструменты и middleware вокруг фиксированной модели.

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

Меняющаяся роль разработчика: дирижёры и оркестраторы

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

Дирижёр: ручное управление в реальном времени

В режиме дирижёра разработчик работает в реальном времени с ИИ как с парным программистом. Он в IDE, смотрит, как появляется код, направляет ИИ промптами и правками и сохраняет детальный контроль над тем, что пишется. ИИ — мощный инструмент, но каждое движение активно задаёт разработчик.

Этот режим типичен для сложной логики, отладки заковыристых проблем или работы в незнакомых кодовых базах, где разработчику нужно понимать каждое изменение по мере его внесения. Инструменты вроде GitHub Copilot, Gemini Code Assist от Google, Cursor и Windsurf в первую очередь поддерживают этот режим через инлайн-автокомплиты, чат-интерфейсы и правки на месте.

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

Оркестратор: асинхронное мультиагентное делегирование

В режиме оркестратора разработчик работает на более высоком уровне абстракции. Он задаёт цели, назначает их агентам и проверяет результаты — но не смотрит, как код появляется строка за строкой. Агенты могут работать в фоне, параллельно, над разными частями кодовой базы. Разработчик периодически сверяется, проверяет результат и вносит коррективы.

Этот режим типичен для чётко определённых задач: исправления багов, реализации фич по устоявшимся паттернам, миграции кодовых баз и генерации тестов. Инструменты вроде Google Jules, агентного режима GitHub Copilot, фоновых агентов Cursor и Claude Code поддерживают этот режим через асинхронное выполнение задач, часто работая в песочницах с полным доступом к репозиторию, инструментам сборки и наборам тестов.¹³

Режим оркестратора требует иного набора навыков. Вместо глубокой экспертизы в синтаксисе и идиомах языка он требует сильных навыков в:

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

Проблема 80%

Устойчивая сложность в разработке с ИИ — то, что мы называем проблемой 80%: ИИ-агенты могут быстро сгенерировать примерно 80% кода фичи, но оставшиеся 20% — краевые случаи, обработка ошибок, точки интеграции и тонкие требования к корректности — требуют глубокого контекстного знания, которого нынешним моделям часто не хватает.¹⁴

Природа ошибок ИИ эволюционировала от простых синтаксических промахов к более коварным концептуальным сбоям: неверные предположения о бизнес-логике, неумение запросить уточнение по неоднозначным требованиям, упущенные краевые случаи и архитектурные решения, создающие тонкое долгосрочное бремя поддержки. Такие ошибки труднее заметить именно потому, что код «выглядит правильным» и может даже проходить базовые тесты.

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

Чтобы эффективно проходить эту проблему 80%, нужно применять правильный инструмент к правильному этапу работы. Разработчику в роли «дирижёра» нужен иной набор инструментов, чем тому, кто работает «оркестратором». Чтобы понять, как сопоставить эти режимы со своим ежедневным процессом, нужно классифицировать нынешний ландшафт ИИ-агентов по их автономности и интеграции.

Кодинговые агенты на практике

Разработчик, создающий агента сегодня, делает бо́льшую часть работы из терминала, часто на естественном языке и часто так, что печатает другой кодинговый агент. Это ново. Год назад та же задача означала фреймворки, SDK и облачные консоли. Пришедшие им на смену паттерны стоит назвать прямо — и для разработчика, который хочет использовать кодинговых агентов в работе, и для того, кто хочет строить собственных агентов.

Где кодинговые агенты вписываются в день разработчика

Кодинговые агенты появляются в трёх местах повседневной работы. Большинство разработчиков используют все три сразу.

В редакторе: инлайн-автокомплит, подсказывающее следующую строку по мере набора. Чат-панели, которые объясняют или меняют код на месте. Осведомлённость обо всей кодовой базе внутри IDE. Именно здесь большинство впервые встречает ИИ в кодинге и здесь работа остаётся в потоке. Примеры: GitHub Copilot, Cursor, Windsurf, JetBrains AI Assistant.

В терминале: кодинговые агенты, которых разработчик запускает из командной строки, ставит им цель простым языком и отпускает работать по всей кодовой базе. Полный доступ к файловой системе, правки в нескольких файлах, возможность запускать инструменты и тесты и итерировать по результатам. Именно здесь сегодня происходит серьёзный вайб-кодинг. Примеры: Antigravity CLI, Claude Code, Codex CLI, Open Code и Cline.

В фоне: агенты, которые берут задачу и работают автономно в облачных песочницах, нередко часами, часто выдавая на выходе пул-реквест. Разработчик передаёт задачу и проверяет результат позже. Примеры: Google Jules, агентный режим GitHub Copilot, фоновые агенты Cursor и специализированный агент Google AlphaEvolve для проектирования продвинутых алгоритмов.

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

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

Как вайб-кодинг доводит агентов до продакшена

Всё, о чём шла речь до сих пор, было про использование кодинговых агентов для создания ПО: написание фич, исправление багов, генерация тестов, рефакторинг. Но что происходит, когда то, что нужно построить, само по себе — агент?

Бот поддержки, обрабатывающий запросы на возврат средств. Исследовательский ассистент, который сверяет источники и выдаёт обоснованные отчёты. Внутренний инструмент, который следит за соответствием требованиям и помечает аномалии. Это не задачи, которые решаешь кодинговым агентом в терминале. Это продукты, которым нужны собственные инструменты, собственная память, собственная оценка и собственная инфраструктура деплоя.

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

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

Agents CLI от Google построен вокруг этой идеи. Это небольшой консольный инструмент, который собирает набор скиллов для создания агентов на Google Cloud и, что важно, работает с тем кодинговым агентом, которого предпочитает разработчик, — Claude Code, Codex или другим. После однократной установки кодинговый агент получает семь новых скиллов, покрывающих весь жизненный цикл ADK: каркас проекта, написание кода агента, его оценку, деплой в Agent Runtime и подключение наблюдаемости. Разработчик не учит новый SDK. Он описывает, что хочет, а кодинговый агент с помощью скиллов делает нужное на каждом шаге.

Если конкретно, весь цикл «собрать — оценить — задеплоить» выглядит так:

# Однократная настройка
uvx google-agents-cli setup
# Затем в вашем кодинговом агенте:
> Собери агента поддержки, который отвечает на вопросы по нашей документации.
> прогони эвалы на датасете FAQ
> Задеплой его в Agent Engine

Листинг 1. Настройка и сборка через Agents CLI.

За этой единственной инструкцией кодинговый агент создаёт каркас проекта из шаблона, пишет ADK-код, генерирует набор эвалов, прогоняет его на агенте, деплоит в Agent Runtime и отчитывается. Тем, кто предпочитает рулить напрямую, те же операции доступны как обычные CLI-команды (agents-cli create, agents-cli playground, agents-cli eval, agents-cli deploy).

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

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

Координация между агентами идёт через общее состояние сессии для простых случаев, через Model Context Protocol (MCP) для доступа к инструментам и через протокол Agent2Agent (A2A) для делегирования между агентами.¹⁵ В начале 2026 года инженерная команда Anthropic опубликовала эксперимент, в котором команды агентов на такой архитектуре за две недели собрали на Rust рабочий компилятор C.

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

Для разработчиков практический вывод прост. Тот же процесс вайб-кодинга, что сегодня выдаёт скрипт, завтра выдаёт продакшен-агента. Жизненный цикл — собрать, оценить, задеплоить, наблюдать, доработать — живёт в одном месте. Путь от идеи до работающего агента сжался с недель до часов, и бо́льшая часть работы теперь идёт на естественном языке.

Практики, которые делают этот процесс продакшен-уровня в масштабе команды — от spec-driven-разработки и структурированного код-ревью до гардрейлов, песочниц и zero-trust-разработки, — разобраны в сопутствующей статье Дня 5: «Spec-Driven Production Grade Development in the Age of Vibe Coding».

Экономика разработки с ИИ

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

Чтобы понять истинную стоимость разработки с ИИ, нужно посмотреть, как разные процессы перераспределяют финансовое и операционное бремя между капитальными затратами (CapEx) — первоначальными вложениями, чтобы что-то построить, — и операционными затратами (OpEx) — постоянными издержками на запуск, починку и поддержку. Важно, что в эпоху ИИ OpEx во многом диктуется экономикой токенов.

Скрытый долг вайб-кодинга (низкий CapEx, высокий OpEx)

На первый взгляд вайб-кодинг кажется невероятно экономичным. Барьер входа практически нулевой: стандартная месячная подписка на ИИ-ассистента и пара казуальных промптов. CapEx ничтожен, потому что разработчик целиком полагается на базовые способности модели, а не вкладывает время в проектирование системы.

Однако экономика вайб-кодинга скрывает огромное, нарастающее бремя OpEx:

• Расход токенов: каждое взаимодействие с большой языковой моделью (LLM) стоит денег в зависимости от входных и выходных токенов. В вайб-кодинге разработчики часто вываливают огромные, неструктурированные файлы в контекстное окно и раз за разом просят модель исправить её же непроверенные ошибки. Это создаёт дорогой «цикл промптинга», который сжигает API-токены при низкой доле успеха с первого прохода.
• Налог на сопровождение: код, написанный через бессистемный промптинг, часто лишён структурной согласованности. Когда через полгода всплывает баг, инженерам-людям приходится днями реверс-инжинирить неструктурированный, сгенерированный ИИ «спагетти-код».
• Устранение уязвимостей: без автоматического харнесса оценки быстрая генерация кода ведёт к быстрой генерации уязвимостей. Стоимость устранения дыры в безопасности в продакшене экспоненциально выше, чем поимка её на этапе проектирования.

Инвестиция агентной инженерии (высокий CapEx, низкий OpEx)

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

CapEx в агентной инженерии включает проектирование схем API, построение детерминированных наборов тестов и, самое главное, структурирование контекста агента. Хотя эти первоначальные затраты выше, предельная стоимость выпуска и поддержки фичи резко падает. ИИ работает внутри строго управляемой «фабрики», то есть его результат структурно корректен, заранее протестирован и согласован со стандартами компании.

Контекст-инжиниринг как финансовый рычаг

В экономике токенов контекст-инжиниринг — не просто технический навык, это финансовая стратегия. LLM берут плату за каждый кусочек информации, который вы им отправляете. Передавать целый репозиторий на 100 000 токенов в каждый промпт в масштабе финансово нежизнеспособно.

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

Масштабирование эффективности через динамический контекст и скиллы

Чтобы по-настоящему оптимизировать OpEx, продвинутая агентная инженерия опирается на динамический контекст через использование «скиллов» или вызова инструментов (например, серверов Model Context Protocol), что мы подробно разбираем в статье Дня 3.

Умный роутинг моделей

Кроме того, агентная инженерия позволяет умно роутить модели. В процессе вайб-кодинга разработчик обычно полагается на одну массивную фронтир-модель для каждого взаимодействия — платя премиальную цену за токены лишь для того, чтобы попросить ИИ исправить опечатку или сгенерировать базовый юнит-тест.

Хорошо спроектированная фабричная модель избегает этих трат. Она использует крупные, продвинутые модели для очень сложных задач (требования, архитектура и первоначальная реализация), но автоматически роутит детерминированные, менее сложные задачи (генерация тестов, ревью кода и мониторинг CI/CD) на меньшие, более быстрые и значительно более дешёвые модели. Оркеструя экосистему из нескольких моделей, инженерные команды могут удерживать пиковое качество результата, систематически снижая операционную стоимость токенов.

С чего начать

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

Для отдельных разработчиков

1. Заведите AGENTS.md (или эквивалент) для проекта. Выберите соглашение, которое подходит вашему кодинговому агенту. Начните с десяти строк: стек, соглашения, жёсткие правила, рабочий процесс. Добавляйте правило каждый раз, когда агент делает то, что не должен повторять.
2. Установите набор скиллов для своих кодинговых агентов (например, Agents CLI), чтобы собирать, оценивать, деплоить и оптимизировать агентов.
3. Выберите один повторяющийся рабочий процесс и сделайте его первым агентом. Исследовательский процесс, ревью кода, регулярный отчёт, регулярно создаваемый контент. Используйте кодингового агента для прототипа и доведите его до продакшен-агента через Agents CLI, когда он себя оправдает. Построить одного агента от начала до конца учит большему, чем чтение про сотню.
4. Пишите тесты и эвалы до генерации кода. Вместе они — контракт с ИИ. Хорошо написанный набор тестов и эвалов передаёт замысел точнее любого промпта на естественном языке и превращает разработку с ИИ из вайб-кодинга в агентную инженерию.
5. Проверяйте каждую строку, которую агент выдаёт в релиз. Скептически относитесь ко всему, что выглядит слишком умно. Проверяйте, что импорты ссылаются на реальные пакеты. Убеждайтесь, что обработка ошибок покрывает реалистичные сценарии сбоев. Код, которого команда не понимает, превращается в стоимость отладки, которую команда не может себе позволить.
6. Поддерживайте свои навыки разработчика. ИИ берёт на себя рутину, чтобы разработчик мог сосредоточиться на сложном. Это работает только при условии, что фундаментальные навыки — отладка, проектирование систем, чутьё на производительность и корректность — остаются острыми. Относитесь к ИИ как к способу применять экспертизу в большем масштабе, а не как к её замене. Регулярная практика сложной отладки, ревью результата ИИ и обсуждения архитектуры остаются необходимыми, чтобы расти как инженер.

Для инженерных руководителей

1. Сделайте контекст-инжиниринг полноценной инженерной практикой в команде. Относитесь к AGENTS.md, системным промптам, наборам эвалов и библиотекам скиллов как к коду: ревью в пул-реквестах, версионирование вместе с проектом, ответственность конкретных инженеров. Без этой дисциплины харнесс дрейфует, а поведение агента становится невоспроизводимым в команде.
2. Ставьте планку на эвале, а не на демо. Рабочее демо доказывает, что агент может добиться успеха один раз. Проходящий набор эвалов доказывает, что он добивается успеха надёжно. Но эвал без чёткой рубрики не измеряет ничего. Определите, что вы оцениваете: успех задачи, качество использования инструментов, соответствие траектории, галлюцинации и качество ответа. Требуйте покрытия эвалами с явными рубриками как условие выпуска любого агента в общий рабочий процесс — так же, как покрытие тестами решает судьбу деплоя сервиса.
3. Перестройте код-ревью под сгенерированный ИИ код. Сгенерированный ИИ код требует такого же или большего внимания, чем написанный человеком, с особым вниманием к галлюцинированным зависимостям, недостаточной обработке ошибок и тонким пробелам в корректности, которые на первый взгляд выглядят правильно. Обучайте ревьюеров видам сбоев сгенерированного кода и настраивайте чек-листы ревью соответствующим образом.
4. Разделяйте в командных нормах прототипирование и продакшен-работу. Вайб-кодинг — правильная скорость для исследования. Агентная инженерия — правильная дисциплина для продакшена. Сделайте границу явной: какие проекты, какие ветки, какие среды требуют какого режима работы. Команды, которые держат это различие размытым, выпускают прототипы по случайности.
5. Вкладывайтесь в компоненты харнесса как в общий актив команды. Переиспользуемые системные промпты, библиотеки скиллов, подключения MCP-серверов и харнессы оценки накапливают эффект между проектами. Относитесь к ним как к инфраструктуре: документированной, поддерживаемой и осознанно улучшаемой. Больше всего ценности из разработки с ИИ извлекают команды, которые строят свой харнесс один раз и доводят его много раз.

Для организаций

1. Относитесь к разработке с ИИ как к инженерной инвестиции, а не как к фиче продуктивности. Наибольший выигрыш получают команды, которые сочетают ИИ-инструменты с покрытием эвалами, наблюдаемостью и ясными архитектурными стандартами. Выкатывание кодингового агента без этого скаффолдинга даёт скорость без качества, что превращается в технический долг быстрее, чем любая команда успеет его погасить.
2. Вкладывайтесь в продакшен-инфраструктуру до масштабирования. Вайб-кодинговый прототип на ноутбуке — это не продакшен-система. Из одного в другое переводит операционная дисциплина вокруг него: эвалы траектории и финального ответа в CI, трассировки каждого запуска агента, ограниченные права на каждого агента и ревью безопасности, настроенное под виды сбоев сгенерированного кода. Постройте эту инфраструктуру до того, как выйдет первый продакшен-агент, а не после.
3. Принимайте открытые стандарты для инструментов и межагентного общения. Model Context Protocol (MCP) для доступа к инструментам и Agent2Agent (A2A) для делегирования между агентами сходятся в соединительную ткань мультиагентных систем. Выбор их сейчас сохраняет возможность смешивать вендоров и фреймворки и избавляет от смены платформы потом.
4. Планируйте под гибридные команды людей и агентов, а не под процессы только из людей или только из агентов. Самые сильные продакшен-результаты последнего года приходят из архитектур, где люди задают направление, агенты делают реализацию, а границу регулируют чёткие протоколы передачи. Процессы код-ревью, графики дежурств и структуры команд — всё это должно эволюционировать, отражая, что агенты теперь участники, а не просто инструменты.
5. Переориентируйте найм и развитие навыков на суждение, а не только на реализацию. По мере того как реализация становится быстрее и автоматизированнее, узкое место смещается к спецификации, оценке, архитектурному суждению и ревью. Нанимайте и развивайте именно эти навыки осознанно. Самыми ценными инженерами ближайших лет будут те, кто умеет хорошо направлять агентов, а не те, кто пишет больше всего кода.

Заключение: замысел как новый интерфейс

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

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

Три принципа выделяются как долговечные:

1. Структура масштабируется, вайб — нет. Вайб-кодинг — рабочий подход для исследования, прототипирования и личных проектов. Но для ПО, на которое полагаются организации, дисциплина агентной инженерии — спецификации, тесты, гардрейлы и человеческий надзор за архитектурой — не опциональна. Разрыв между «вроде работает» и «работает корректно при любых условиях» — это место, где живут продакшен-аварии, уязвимости безопасности и кошмары поддержки.
2. ИИ усиливает вашу инженерную культуру. Организации с сильными практиками тестирования, ясными архитектурными стандартами и здоровыми процессами код-ревью получают от разработки с ИИ несравнимо больше ценности, чем те, у кого их нет. ИИ — мультипликатор силы, и он умножает как ваши сильные стороны, так и слабые.
3. Роль человека эволюционирует, а не уменьшается. Строители, которые понимают архитектуру, умеют задавать точные спецификации, критически оценивать результат и проектировать эффективные системы ограничений и петель обратной связи, ценны как никогда. Важные навыки смещаются от реализации к суждению, от написания кода к проектированию систем, которые производят код.

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

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

Генерация решена. Верификация, суждение и задание направления — вот новое ремесло.