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