Что такое agentic engineering в разработке ПО

Agentic engineering — это подход к разработке, при котором код пишут ИИ‑агенты, а инженер управляет ими, проверяет результат и отвечает за качество. В отличие от «vibe coding», здесь ИИ используется как инструмент в строгой инженерной системе, а не как свободный генератор кода по настроению.

Как сегодня разработчики используют ИИ при работе с кодом

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

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

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

На практике ИИ чаще всего применяют для задач, которые:

• отнимают много времени;
• несут небольшой риск при наличии ревью;
• хорошо формализуются.

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

Что такое vibe coding и почему этого уже недостаточно

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

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

Неправильное использование LLM‑моделей в режиме vibe coding приводит к эффекту, который называют «AI slop»: код выглядит правдоподобным, но по сути бесполезен или даже ломает существующую систему. Часто нарушаются инварианты, игнорируются неочевидные ограничения, а в результат просачиваются мелкие расхождения, которые сложно отловить без внимательного анализа.

Последствия очевидны:

• растёт технический долг, потому что временное «решение» остаётся в кодовой базе;
• команда тратит время на разбор и отладку чужих ИИ‑фрагментов;
• падает доверие к любым инструментам с ИИ под капотом.

Vibe coding удобен на этапе чернового прототипирования или для личных экспериментов, но при работе в крупных продуктах нужен более формальный подход. Именно этот разрыв и закрывает концепция agentic engineering.

Определение agentic engineering: ключевая идея

Agentic engineering — это организованный процесс разработки, в котором оркестр ИИ‑агентов выполняет задачи по коду, а инженер системно управляет этим процессом и контролирует результат. Здесь акцент смещается с разового «промпта ради кода» к построению устойчивого агентного контура, встроенного в инженерный цикл.

В этом подходе важны сразу два аспекта — и оба заложены в названии:

«Agentic» описывает работу набора агентов (одного или нескольких), которые:

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

Ключевой элемент здесь — human-in-the-loop: человек остаётся в контуре, задаёт границы, проверяет критичные изменения и отвечает за итоговое состояние системы.

«Engineering» подчёркивает, что этим нужно уметь пользоваться так же, как любым другим инженерным инструментом. Требуется сформировать навыки:

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

Agentic engineering рассматривает ИИ‑агентов как часть инженерной системы, а не как магический «генератор всего». Это делает процесс повторяемым, поддающимся аудиту и улучшению.

Agentic engineering против vibe coding: главное различие

Различие между agentic engineering и vibe coding в том, что первый задаёт строгий рабочий процесс с ролями и контролем, а второй опирается на разовые, слабо формализованные запросы к модели. В итоге agentic engineering ближе к профессиональной разработке, а vibe coding — к экспериментальному прототипированию.

Если представить это в виде простой схемы, получится такая картина:

Таким образом, agentic engineering смещает фокус с «настроения» и креатива в сторону инженерной дисциплины: как настроен пайплайн задач, какие роли есть у агентов, где проходят границы ответственности человека и какие критерии качества приняты в команде.

Роль human-in-the-loop в agentic engineering

Human-in-the-loop в agentic engineering — это не декоративная проверка, а основной механизм управления рисками и качеством. Инженер работает как режиссёр и редактор: он не пишет каждую строку кода руками, но задаёт рамки, следит за целостностью и утверждает результат.

Контур участия человека обычно проявляется в нескольких точках:

• Постановка задач: человек формулирует цели, ограничения, форматы выходных артефактов, приоритизирует подзадачи.
• Настройка агентов: выбираются модели, задаются роли, описываются инструменты, которыми агент может пользоваться.
• Промежуточные проверки: для критичных шагов включаются ревью, approval‑gate, дополнительные тесты.
• Финальная валидация: инженер оценивает влияние изменений на систему в целом, сверяет результат с исходными требованиями.

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

Как организации могут внедрять agentic engineering

Внедрение agentic engineering начинается с пересмотра того, как команда относится к неопределённости и вероятностной природе ИИ‑моделей. Нужно не пытаться сделать агента полностью детерминированным, а научиться управлять рисками через процессы, данные и контроль.

Практически это затрагивает сразу несколько уровней: от управленческой политики до конкретных изменений в CI/CD‑пайплайнах и инструментах для разработчиков.

Политики и управление рисками

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

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

Такие правила позволяют использовать ИИ‑агентов системно, а не точечно, и при этом сохранять предсказуемость поведения продуктовой и инфраструктурной частей.

Навыки инженерных команд

Agentic engineering требует новых компетенций от разработчиков и архитекторов. Недостаточно уметь «хорошо промптить» LLM — нужно строить целостные сценарии работы агентов и вписывать их в текущий стек.

К ключевым навыкам относятся:

1. Понимание архитектуры агентных систем: как делить задачу на подзадачи, какие агенты за что отвечают, как они координируются.
2. Оркестрация агентов: использование фреймворков и инструментов, которые позволяют связывать вызовы моделей, внешние API и хранилища.
3. Валидация результата: разработка автоматических и полуавтоматических проверок для кода, тестов и документации, сгенерированных агентами.
4. Интеграция в CI/CD: включение этапов работы агентов в пайплайны, настройка триггеров и условий запуска.

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

Разбиение задач и снижение технического долга

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

Хорошо настроенная агентная система чаще всего работает в формате:

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

Это позволяет:

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

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

RAG и опора на реальные данные в agentic engineering

Многие команды используют RAG‑архитектуры (Retrieval‑Augmented Generation), чтобы агенты опирались на реальные данные проекта и меньше «выдумывали» детали. Это уменьшает количество галлюцинаций и делает поведение ИИ более предсказуемым.

RAG‑подход в контексте agentic engineering обычно включает:

• индексацию документации, спецификаций, ADR‑решений, комментариев к коду;
• поиск релевантных фрагментов под конкретную задачу для агента;
• подмешивание найденного контекста в запрос к модели;
• проверку того, что результат согласован с предоставленными данными.

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

Внутренние плейбуки и паттерны использования агентов

Чтобы agentic engineering не превращался в набор разрозненных экспериментов, организации формируют внутренние плейбуки. Это документы, которые описывают типовые сценарии использования агентов и общие правила безопасности.

Обычно такие плейбуки включают:

• шаблоны сценариев для разных задач (например, обновление зависимостей, миграции, генерация интеграционных тестов);
• требования к ревью и пороги, при которых необходимо вмешательство человека;
• стандарты качества для кода, написанного агентами (стиль, покрытие тестами, логи и ошибки);
• настройки «ограждений» (guardrails): какие действия агенту запрещены, где нужны дополнительные проверки.

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

Как меняется роль разработчика в парадигме agentic engineering

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

Фактически инженер берёт на себя три взаимосвязанные функции:

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

Для специалистов разных профилей (backend, frontend, data science, ML‑инженеры) это означает, что базовые компетенции в области системного мышления, управления рисками и понимания поведения ИИ становятся не менее важными, чем знание конкретного фреймворка.

Куда движется agentic engineering

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

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