Привет! Я Влад Шевченко, CTO по AI в red_mad_robot. Сегодня поговорим об анатомии AI-агентов, критериях готовности компании к работе с ними и кризисе жизненного цикла разработки ПО, а также ответим на вопрос, почему нельзя просто написать запрос агенту и ждать результата.
Мы в компании взаимодействуем с искусственным интеллектом уже достаточно давно, и в данный момент занимаемся трансформацией бизнеса: смотрим, что меняется в клиентах, где-то помогаем, а где-то учимся у них. Я разделил SDLC на два подхода. Начнем с разработки классических систем без искусственного интеллекта, но с применением его как помощника.
Образовательные материалы и курсы Anthropic Academy
Автономный контур AI-разработки с внешним управлением со стороны человека
Рассмотрим эту схему на примере работы системы «теплый пол». В стандартных условиях установленная температура в 20 °C может быть комфортной. Однако если пользователь возвращается после пробежки, его субъективное восприятие меняется: 20 °C кажутся избыточными, и возникает необходимость снизить температуру. Система не может самостоятельно узнать об изменении контекста во внешнем мире, пока пользователь не введет новые данные.
AI-агенты работают по аналогичному принципу: они не способны предугадать внешние изменения и нуждаются в информации, поступающей извне. Таким образом, на данном этапе полностью исключить человека из контура управления невозможно, но агентам необходимо предоставить максимально доступную степень автономии.
Классический линейный процесс разработки ПО vs AI-ориентированный цикл продакт-инженера
Находясь в поиске баланса между высокой скоростью прототипирования и стабильностью enterprise-систем, рынок сейчас нащупывает решение в виде микрокоманд с высокой степенью T-Shaped компетенций. Компании идут по пути сокращения Agile-команд до 2–3 человек, роли которых достаточно размыты, благодаря чему специалисты могут взаимно перекрывать зоны ответственности друг друга.
В таких условиях AI берет на себя рутинный кодинг и первичную проверку: живые разработчики валидируют качество, а задержки при передаче задач значительно уменьшаются за счет минимального коммуникационного окна. На сегодняшний день это выход из ситуации, когда нужно двигаться быстро в условиях неопределенности. Нельзя сказать, что вариант идеальный, но, по крайней мере, рабочий.
Трансформация классической структуры Agile-команд в компактные T-Shape микрокоманды
Структура разработки AI-агента
Таким образом, для эффективной разработки AI-агентов требуются как минимум две компетенции: инженерная и исследовательская. Если обе роли совмещает один сотрудник, он способен самостоятельно вести весь цикл разработки. При отсутствии такого специалиста задачи необходимо разделять как минимум между двумя профильными экспертами.
Интеграция циклического исследовательского процесса в классическую линейную схему разработки ПО
Как на практике эти изменения трансформируют структуру планирования: если в рамках классического спринта команда реализовывала 10 четко описанных фичей, то в агентной разработке к ним добавляется аналогичный объем гипотез и экспериментов. Формирование прозрачной отчетности для заказчика по результатам таких экспериментов — отдельная методологическая задача, поскольку гипотезы могут не подтвердиться. Тем не менее, это объективная реальность, с которой сегодня сталкиваются все команды, создающие системы на базе LLМ и AI-агентов.
Методология построения исследовательского контура
Нам в прошлом году очень помог такой инструмент, как ML System Design Doc, который мы применяли именно в исследовательских процессах. Самое полезное в решении — то, что можно записывать туда все проведенные эксперименты. Клиент видит проведенную работу, что делает процессы более прозрачными: становится сразу понятно, почему одни решения приняли, а другие отклонили. Инструмент действительно полезный, но требует определенной культуры ведения.
Архитектура взаимодействия AI-агента с цифровой средой
Возникает множество новых вызовов в области информационной безопасности: например, как действовать в случае компрометации агента, как защитить инфраструктуру и как обезопасить конечного пользователя. Ограничение доступа клиентов к агентным технологиям не является жизнеспособным решением, поскольку на рынке существует высокий спрос на персональных AI-ассистентов. Однозначные индустриальные стандарты для решения этих проблем пока отсутствуют, что стимулирует экспертные дискуссии. В частности, специалисты OpenAI сейчас активно развивают и обсуждают концепцию тестовых сред и систем ограничений для контроля безопасности AI-систем.
Статья написана совместно с Selectel по следам доклада на конференции МLечный путь. Полностью ознакомиться с этим и другими выступлениями можно в записи.
SDLC в эпоху AI
Летом прошлого года мы решили провести масштабный эксперимент по автоматизации внутренних процессов и, чтобы разгрузить проектные команды от рутины, приобрели подписки на Cursor AI. Идея была в том, чтобы проверить, насколько AI-помощники способны ускорить написание локальных скриптов и утилит, не затрагивая при этом основной контур коммерческой разработки продуктов. Эксперимент принес неожиданные инсайты. Как вы думаете, какой режим использования AI-ассистента стал самым популярным среди участников? Большинство пользователей ожидаемо полагалось на режим «Auto» (автоматический выбор моделей и контекста), работая исключительно со стандартными настройками по умолчанию, и мало кто пытался кастомизировать инструмент под конкретные инженерные задачи. Этот кейс подвел нас к важному выводу: одного лишь AI-инструмента для работы сейчас недостаточно. Чтобы агент выдавал предсказуемый и качественный результат, его нужно тонко настраивать: понимать, как он взаимодействует с MCP, какие контекстные навыки ему доступны и как правильно выстраивать промпт-инженерию. Для этого существуют системные подходы, такие как Plan-Act или SDD. Кроме того, руководителям важно трезво оценивать кривую обучения. Даже если у вас уже имеется продвинутый стек, инженерам требуется от 3 до 6 месяцев, чтобы органично встроить AI-ассистентов в свои привычные рабочие процессы без потери качества кода. Cамый экологичный способ преодоления барьера на пути к использованию агентов для автоматизации работы — системное обучение сотрудников. Мы в компании опираемся на методологические материалы от Anthropic и OpenAI, а также проводим собственный внутренний образовательный курс по AI-агентам.Падение стоимости кода и кризис «чистой архитектуры»
И все же, почему инженерное сообщество до сих пор относится к кодогенерации с долей скепсиса? Дело в том, что себестоимость написания отдельной строчки кода стремительно падает из-за тех несопоставимых с человеческими скоростей, которые способен демонстрировать AI. Профессиональные разработчики, привыкшие к парадигме «чистой архитектуры», декомпозиции на изолированные компоненты и строгому код-ревью, смотрят на этот процесс с опасением. Контролировать код, сгенерированный агентом, классическими методами становится невозможно: вы физически не можете вычитывать строчку за строчкой, когда модель на лету создает, тестирует и переписывает огромные файлы. В этой точке парадигма управления меняется. Мы неизбежно переходим с уровня построчного контроля кода на уровень архитектурного менеджмента AI-агентов, однако это требует высокой инженерной зрелости. Возникает закономерный вопрос: как в такой реальности развиваться джуниор-разработчикам, если вместо написания базового кода нужно сразу выступать в роли квалифицированного инженера, способного валидировать написанную архитектуру?Пока этот вопрос остается открытым для всей индустрии. Наш промежуточный ответ — жестко удерживать в зоне ответственности человека ключевые точки контроля: дизайн АPI, проектирование архитектурных контрактов и схем баз данных. Вокруг этих аспектов кодогенерация может быть гибкой и вариативной, но сами архитектурные слои должны оставаться под абсолютным контролем опытного инженера. Доверять проектирование базы данных или ядра системы агенту в автоматическом режиме сегодня нельзя.
Обратная связь
Во время полета воздушное судно непрерывно отклоняется от заданного курса, и его траекторию необходимо корректировать на основе актуальных данных. Для точного сбора информации применяются гироскопы и акселерометры — сложные и дорогостоящие приборы. Использование внешнего источника данных, например GPS, позволяет летательному аппарату ориентироваться с помощью более простых и дешевых бортовых датчиков, так как погрешность компенсируется постоянной внешней корректировкой. В контексте взаимодействия с искусственным интеллектом разработчик выполняет роль именно такого внешнего источника обратной связи. На текущем этапе развития технологий ключевая задача — определить оптимальную степень участия человека в корректировке работы AI-агентов.Команды потеряли свою эффективность
Если проанализировать, почему AI не дал индустрии мгновенного ускорения, мы упремся в неожиданный барьер: классический Agile, который годами служил для ускорения процесса разработки, в эпоху AI начал его замедлять. Представьте такую картину: в команде есть аналитики, разработчики и продуктовый менеджер, и каждый из них вооружился AI-ассистентом. Локальная скорость работы очевидно вырастает в разы за счет оптимизации рутинных задач, однако старые регламенты передачи ответственности, согласования и бесконечные созвоны остаются на прежнем уровне. И тогда мы получаем ситуацию, когда скорость создания смысловых частей проекта кратно повышается, а скорость их интеграции внутри команды — нет. Вторая проблема заключается в психологическом факторе. Сталкиваясь с новой сложной сущностью в виде AI-агентов, люди инстинктивно уходят в зону комфорта к понятным им рутинным процессам. Команда начинает множить задачи в Jira и до бесконечности детализировать требования, вместо того чтобы инвестировать время в проектирование и обучение агентов. Сегодня в качестве ответа на кризис классических Agile-структур активно заявляет о себе феномен продакт-инженеров. В вакууме это выглядит как идеальный сценарий: агенты мгновенно пишут код, а один специалист, обладающий продуктовым видением и сильными инженерными навыками, валидирует результат, направляет AI и за пару дней собирает работающий прототип приложения или сайта. Скорость продакт-инженеров на этапе проверки гипотез и создания MVP действительно может достигать космических показателей. Но в масштабах enterprise-продуктов таких мультифункциональных специалистов критически мало, да и в одиночку закрыть все вопросы долгосрочной архитектуры, безопасности и отказоустойчивости не представляется возможным чисто с физической точки зрения. В классической же громоздкой схеме легко уйти в другую крайность и за месяц совсем не продвинуться в разработке из-за обилия побочных процессов и согласований.SDLC для вероятностных систем
При переходе к вероятностным агентным системам возникает вопрос распределения ролей: кто именно должен заниматься разработкой агентов? Опыт показывает, что делегирование этой задачи бэкенд-разработчикам часто приводит к тому, что они отказываются от готовых решений (например, от OpenAI) и начинают создавать собственные фреймворки с нуля, на что могут уходить месяцы. На первый взгляд, поручение задачи AI-инженерам выглядит логичным, так как они специализируются на машинном обучении. Однако я сам был свидетелем ситуации, когда в одной из команд, состоящей из продакт-менеджера и NLP-инженера, бэклог проекта состоял из задач по авторизации, интеграциям и работе с базами данных. В итоге NLР-инженер тратил все время на выстраивание классической инфраструктуры, а менеджер не понимал, почему разработка самого агента не продвигается. По итогу большинстве компаний, как правило, разработку AI-агентов по инерции передают классическим продуктовым командам, либо же этот процесс держится исключительно на инициативе отдельных энтузиастов.Две зоны ответственности
Процесс создания AI-агента объединяет в себе две составляющие: инженерную, которая обеспечивает контроль над системой, и исследовательскую, отвечающую за качество ее поведения. Инженерная часть сфокусирована на интеграции. Агент должен корректно взаимодействовать с внешним окружением, например через MСP. При этом возникает сложная задача разграничения прав доступа. С появлением агента в системе формируется полноценная третья сторона взаимодействия. Если правила работы для обычных пользователей и классических сервисов понятны, то принципы авторизации самого агента и объем его полномочий каждая компания сейчас вынуждена определять самостоятельно. Задачи построения инфраструктуры, проектирования API и интеграции баз данных традиционно ложатся на бэкенд-разработчиков и DevOps-инженеров. Однако, поскольку агент является вероятностной системой, возникает необходимость в регулярном сборе датасетов пользовательских запросов, настройке бенчмарков, а также в создании методологий для расчета и отслеживания бизнес-метрик. Данный пласт задач относится исключительно к исследовательской деятельности.Анатомия и язык описания агента
Попытка описать AI-агента и логику его интеграции с точки зрения классического системного и бизнес-анализа часто вызывает сложности. Применение стандартных подходов приводит к тому, что финальные формулировки становятся непонятными как для бизнеса, так и для технической команды. Обычно верхнеуровневая задача формулируется абстрактно, например, «Создать агента-аналитика». Отсутствие конкретики порождает множество противоречивых трактовок внутри команды, и каждый участник начинает представлять работу системы по-своему. Для формализации описания целесообразно разделять архитектуру агента на два ключевых контура:- инструменты управления поведением агента: промпты, доступные навыки (скиллы) и агентский цикл принятия решений (например, паттерн Re-Act или его аналоги);
- базовые компоненты взаимодействия: подключенные субагенты, сама языковая модель (LLM) и память агента.
Конфликт Agile и исследовательского процесса
Техническая реализация базового функционала агента не является трудоемкой задачей. Однако классический Agile-процесс не рассчитан на обязательный исследовательский цикл, который возникает при внедрении AI, что в итоге существенно замедляет вывод продукта на рынок. Рассмотрим сценарий: менеджер констатирует работоспособность агента на базовых тестах и согласовывает релиз в производственную среду. В процессе реальной эксплуатации пользователи сталкиваются со сбоями в логике ответов агента, после чего заказчик начинает массово регистрировать инциденты в Jira. С точки зрения менеджмента этот процесс выглядит стандартно, однако инженеры и исследователи заходят в тупик, поскольку исправление единичных багов в вероятностных системах по классической схеме не приносит результата. Ошибки вероятностного агента следует рассматривать не как изолированные дефекты кода, а как источник эмпирических данных для его дообучения и настройки. Разработка таких систем требует постоянного проведения серий экспериментов для поэтапного достижения целевых продуктовых метрик. К управлению этим непрерывным исследовательским контуром многие руководители проектов оказываются не готовы.Как создать исследовательский контур
Для адаптации к новым условиям необходимо формализовать исследовательские процессы и внедрить метрики эффективности агента. На основе бизнес-требований настраивается сквозной мониторинг: оцениваются время выполнения задач, точность ответов, информационная безопасность и соотношение стоимости вычислений к результату. Системное измерение этих параметров позволяет четко определять вектор развития проекта. В результате коммуникация с заказчиком переходит на язык проверки гипотез, где каждый спринт становится серией контролируемых экспериментов.Агенты живут в мире, спроектированном для людей
Традиционно программные системы и сервисы проектируются для взаимодействия с человеком. Однако в текущих реалиях AI-агент становится самостоятельным актором, который напрямую подключается к внешней цифровой среде. Для такого взаимодействия необходимы принципиально новые точки входа и измененные сценарии интеграции. Вокруг агентов начинает формироваться собственный протокольный слой, к работе с которым существующая сервисная инфраструктура пока не готова.Выводы
Подводя итог, можно выделить несколько ключевых аспектов трансформации SDLC:- разработка AI-агентов требует обязательного соблюдения дуализма инженерных и исследовательских задач;
- необходима формализация описания агента, обеспечивающая единое понимание архитектуры проекта всеми членами команды;
- требуется проектирование специализированной среды для взаимодействия самих агентов, поскольку существующие инструменты (например, Jira) создавались исключительно под потребности человека.
Оригинал статьи опубликован на Хабре