Ещё примерно год назад нам обещали, что разработка с приходом ИИ ускорится в 10 раз. Однако все понимают, что прогнозируемого роста за это время не произошло. Почему — сейчас попробуем разобраться.
Привет, Хабр! Я Влад Шевченко, CTO по ИИ в redmadrobot. Сегодня поговорим об анатомии ИИ‑агентов, критериях готовности компании к работе с ними и кризисе жизненного цикла разработки ПО, а также ответим на вопрос, почему нельзя просто написать запрос агенту и ждать результата.
Мы в компании взаимодействуем с искусственным интеллектом уже достаточно давно и в данный момент занимаемся трансформацией бизнеса: смотрим, что меняется в клиентах, где‑то помогаем, а где‑то учимся у них. Я разделил SDLC на два подхода. Начнём с разработки классических систем без искусственного интеллекта, но с применением его как помощника.
Статья написана по следам доклада на конференции «Млечный путь». Полностью ознакомиться с этим и другими выступлениями можно в записи.
SDLC в эпоху ИИ
Летом прошлого года мы решили провести масштабный эксперимент по автоматизации внутренних процессов и, чтобы разгрузить проектные команды от рутины, приобрели подписки на Cursor AI. Идея была в том, чтобы проверить, насколько ИИ‑помощники способны ускорить написание локальных скриптов и утилит, не затрагивая при этом основной контур коммерческой разработки продуктов.
Эксперимент принёс неожиданные инсайты. Как вы думаете, какой режим использования ИИ‑ассистента стал самым популярным среди участников?
Большинство пользователей ожидаемо полагалось на режим «Auto» (автоматический выбор моделей и контекста), работая исключительно со стандартными настройками по умолчанию, и мало кто пытался кастомизировать инструмент под конкретные инженерные задачи.
Этот кейс подвёл нас к важному выводу: одного лишь ИИ‑инструмента для работы сейчас недостаточно. Чтобы агент выдавал предсказуемый и качественный результат, его нужно тонко настраивать: понимать, как он взаимодействует с MCP, какие контекстные навыки ему доступны и как правильно выстраивать промпт‑инженерию. Для этого существуют системные подходы, такие как Plan‑Act или SDD.
Кроме того, руководителям важно трезво оценивать кривую обучения. Даже если у вас уже имеется продвинутый стек, инженерам требуется от 3 до 6 месяцев, чтобы органично встроить ИИ‑ассистентов в свои привычные рабочие процессы без потери качества кода. Самый экологичный способ преодоления барьера на пути к использованию агентов для автоматизации работы — системное обучение сотрудников. Мы в компании опираемся на методологические материалы от Anthropic и OpenAI, а также проводим собственный внутренний образовательный курс по ИИ‑агентам.
Образовательные материалы и курсы Anthropic Academy. Падение стоимости кода и кризис «чистой архитектуры».
И всё же почему инженерное сообщество до сих пор относится к кодогенерации с долей скепсиса? Дело в том, что себестоимость написания отдельной строчки кода стремительно падает из‑за тех несопоставимых с человеческими скоростей, которые способен демонстрировать AI.
Профессиональные разработчики, привыкшие к парадигме «чистой архитектуры», декомпозиции на изолированные компоненты и строгому код‑ревью, смотрят на этот процесс с опасением. Контролировать код, сгенерированный агентом, классическими методами становится невозможно: вы физически не можете вычитывать строчку за строчкой, когда модель на лету создаёт, тестирует и переписывает огромные файлы.
В этой точке парадигма управления меняется. Мы неизбежно переходим с уровня построчного контроля кода на уровень архитектурного менеджмента AI‑агентов, однако это требует высокой инженерной зрелости. Возникает закономерный вопрос: как в такой реальности развиваться джуниор‑разработчикам, если вместо написания базового кода нужно сразу выступать в роли квалифицированного инженера, способного валидировать написанную архитектуру?
Пока этот вопрос остаётся открытым для всей индустрии. Наш промежуточный ответ — жёстко удерживать в зоне ответственности человека ключевые точки контроля: дизайн API, проектирование архитектурных контрактов и схем баз данных. Вокруг этих аспектов кодогенерация может быть гибкой и вариативной, но сами архитектурные слои должны оставаться под абсолютным контролем опытного инженера. Доверять проектирование базы данных или ядра системы агенту в автоматическом режиме сегодня нельзя.
Обратная связь. Во время полёта воздушное судно непрерывно отклоняется от заданного курса, и его траекторию необходимо корректировать на основе актуальных данных. Для точного сбора информации применяются гироскопы и акселерометры — сложные и дорогостоящие приборы. Использование внешнего источника данных, например GPS, позволяет летательному аппарату ориентироваться с помощью более простых и дешёвых бортовых датчиков, так как погрешность компенсируется постоянной внешней корректировкой.
В контексте взаимодействия с искусственным интеллектом разработчик выполняет роль именно такого внешнего источника обратной связи. На текущем этапе развития технологий ключевая задача — определить оптимальную степень участия человека в корректировке работы AI‑агентов.
Автономный контур разработки ИИ с внешним управлением со стороны человека. Рассмотрим эту схему на примере работы системы «тёплый пол». В стандартных условиях установленная температура в 20 °C может быть комфортной. Однако если пользователь возвращается после пробежки, его субъективное восприятие меняется: 20 °C кажутся избыточными, и возникает необходимость снизить температуру. Система не может самостоятельно узнать об изменении контекста во внешнем мире, пока пользователь не введёт новые данные.
Агенты ИИ работают по аналогичному принципу: они не способны предугадать внешние изменения и нуждаются в информации, поступающей извне. Таким образом, на данном этапе полностью исключить человека из контура управления невозможно, но агентам необходимо предоставить максимально доступную степень автономии.
Команды потеряли свою эффективность. Если проанализировать, почему ИИ не дал индустрии мгновенного ускорения, мы упрёмся в неожиданный барьер: классический Agile, который годами служил для ускорения процесса разработки, в эпоху ИИ начал его замедлять.
Представьте такую картину: в команде есть аналитики, разработчики и продуктовый менеджер, и каждый из них вооружился ИИ‑ассистентом. Локальная скорость работы очевидно вырастает в разы за счёт оптимизации рутинных задач, однако старые регламенты передачи ответственности, согласования и бесконечные созвоны остаются на прежнем уровне. И тогда мы получаем ситуацию, когда скорость создания смысловых частей проекта кратно повышается, а скорость их интеграции внутри команды — нет.
Вторая проблема заключается в психологическом факторе. Сталкиваясь с новой сложной сущностью в виде ИИ‑агентов, люди инстинктивно уходят в зону комфорта — к понятным им рутинным процессам. Команда начинает множить задачи в Jira и до бесконечности детализировать требования вместо того, чтобы инвестировать время в проектирование и обучение агентов.
Сегодня в качестве ответа на кризис классических Agile‑структур активно заявляет о себе феномен продакт‑инженеров. В вакууме это выглядит как идеальный сценарий: агенты мгновенно пишут код, а один специалист, обладающий продуктовым видением и сильными инженерными навыками, валидирует результат, направляет ИИ и за пару дней собирает работающий прототип приложения или сайта. Скорость продакт‑инженеров на этапе проверки гипотез и создания MVP действительно может достигать космических показателей. Но в масштабах enterprise‑продуктов таких мультифункциональных специалистов критически мало, да и в одиночку закрыть все вопросы долгосрочной архитектуры, безопасности и отказоустойчивости не представляется возможным чисто с физической точки зрения. В классической же громоздкой схеме легко уйти в другую крайность и за месяц совсем не продвинуться в разработке из‑за обилия побочных процессов и согласований.
Классический линейный процесс разработки ПО против ИИ‑ориентированного цикла продакт‑инженера. Находясь в поиске баланса между высокой скоростью прототипирования и стабильностью enterprise‑систем, рынок сейчас нащупывает решение в виде микрокоманд с высокой степенью T‑Shaped компетенций. Компании идут по пути сокращения Agile‑команд до 2–3 человек, роли которых достаточно размыты — благодаря чему специалисты могут взаимно перекрывать зоны ответственности друг друга. В таких условиях ИИ берёт на себя рутинный кодинг и первичную проверку: живые разработчики валидируют качество, а задержки при передаче задач значительно уменьшаются за счёт минимального коммуникационного окна. На сегодняшний день это выход из ситуации, когда нужно двигаться быстро в условиях неопределённости. Нельзя сказать, что вариант идеальный, но, по крайней мере, рабочий.
Трансформация классической структуры Agile‑команд в компактные T‑Shape микрокоманды. SDLC для вероятностных систем.
При переходе к вероятностным агентным системам возникает вопрос распределения ролей: кто должен заниматься разработкой агентов?
Опыт показывает, что если делегировать эту задачу бэкенд‑разработчикам, они часто отказываются от готовых решений (например, от OpenAI) и начинают с нуля создавать собственные фреймворки — на это могут уходить месяцы.
На первый взгляд, поручить задачу AI‑инженерам логично — они специализируются на машинном обучении. Однако я сам видел ситуацию, когда в команде из продакт‑менеджера и NLP‑инженера бэклог проекта состоял из задач по авторизации, интеграциям и работе с базами данных. В итоге NLP‑инженер всё время тратил на выстраивание классической инфраструктуры, а менеджер не понимал, почему разработка агента не продвигается.
В большинстве компаний разработку AI‑агентов по инерции передают классическим продуктовым командам либо этот процесс держится исключительно на инициативе отдельных энтузиастов.
Две зоны ответственности.
Процесс создания AI‑агента объединяет две составляющие: инженерную — она обеспечивает контроль над системой, и исследовательскую — она отвечает за качество её поведения.
Инженерная часть сфокусирована на интеграции. Агент должен корректно взаимодействовать с внешним окружением — например, через MCP. При этом возникает сложная задача разграничения прав доступа. С появлением агента в системе формируется полноценная третья сторона взаимодействия. Если правила работы для обычных пользователей и классических сервисов понятны, то принципы авторизации самого агента и объём его полномочий каждая компания сейчас вынуждена определять самостоятельно.
Задачи построения инфраструктуры, проектирования API и интеграции баз данных традиционно ложатся на бэкенд‑разработчиков и DevOps‑инженеров. Однако, поскольку агент является вероятностной системой, нужно регулярно собирать датасеты пользовательских запросов, настраивать бенчмарки, а также создавать методологии для расчёта и отслеживания бизнес‑метрик. Этот пласт задач относится исключительно к исследовательской деятельности.
Структура разработки AI‑агента.
Таким образом, для эффективной разработки AI‑агентов нужны как минимум две компетенции: инженерная и исследовательская. Если обе роли совмещает один сотрудник, он может самостоятельно вести весь цикл разработки. Если такого специалиста нет, задачи нужно разделить как минимум между двумя профильными экспертами.
Анатомия и язык описания агента.
Попытка описать AI‑агента и логику его интеграции с точки зрения классического системного и бизнес‑анализа часто вызывает сложности. Если применять стандартные подходы, финальные формулировки становятся непонятными и для бизнеса, и для технической команды.
Обычно верхнеуровневая задача формулируется абстрактно — например, «Создать агента‑аналитика». Из‑за отсутствия конкретики внутри команды возникает множество противоречивых трактовок, и каждый участник представляет работу системы по‑своему.
Для формализации описания целесообразно разделять архитектуру агента на два ключевых контура:
- инструменты управления поведением агента: промпты, доступные навыки (скиллы) и агентский цикл принятия решений (например, паттерн Re‑Act или его аналоги);
- базовые компоненты взаимодействия: подключённые субагенты, сама языковая модель (LLM) и память агента.
При таком разделении архитектура сводится к понятной схеме с фиксированными входными и выходными данными. Такой подход хорошо соответствует методологии IDEF0, которая описывает систему через набор бизнес‑функций. Когда обсуждение с аналитиками смещается с технических особенностей агентов на конкретные бизнес‑функции, подлежащие автоматизации, коммуникация с заказчиком упрощается. Клиент понимает логику бизнес‑процессов, что позволяет команде и бизнесу общаться на
Одним языком. Кроме того, декомпозиция помогает проектной команде преодолеть неопределённость на старте: если неясно, с чего начать проектирование, достаточно расписать целевые бизнес‑функции, а затем определить задачи и интеграции агента, необходимые для их реализации. Этот метод эффективен и в ситуациях, когда агент оснащён избыточным количеством инструментов, но не приносит реальной пользы. Чёткое описание приоритетных функций позволяет выявить и безболезненно удалить лишние инструменты, упростив общую архитектуру системы без потери качества. Подробное описание применения методологии доступно на GitHub.
Конфликт Agile и исследовательского процесса
Техническая реализация базового функционала агента не является трудоёмкой задачей. Однако классический Agile‑процесс не рассчитан на обязательный исследовательский цикл, который возникает при внедрении AI, — в итоге это существенно замедляет вывод продукта на рынок.
Рассмотрим сценарий: менеджер констатирует работоспособность агента на базовых тестах и согласовывает релиз в производственную среду. В процессе реальной эксплуатации пользователи сталкиваются со сбоями в логике ответов агента, после чего заказчик начинает массово регистрировать инциденты в Jira. С точки зрения менеджмента этот процесс выглядит стандартно, однако инженеры и исследователи заходят в тупик: исправление единичных багов в вероятностных системах по классической схеме не приносит результата.
Ошибки вероятностного агента следует рассматривать не как изолированные дефекты кода, а как источник эмпирических данных для его дообучения и настройки. Разработка таких систем требует постоянного проведения серий экспериментов для поэтапного достижения целевых продуктовых метрик. К управлению этим непрерывным исследовательским контуром многие руководители проектов оказываются не готовы.
Интеграция циклического исследовательского процесса в классическую линейную схему разработки ПО
Как на практике эти изменения трансформируют структуру планирования: если в рамках классического спринта команда реализовывала 10 чётко описанных фичей, то в агентной разработке к ним добавляется аналогичный объём гипотез и экспериментов. Формирование прозрачной отчётности для заказчика по результатам таких экспериментов — отдельная методологическая задача, поскольку гипотезы могут не подтвердиться. Тем не менее это объективная реальность, с которой сегодня сталкиваются все команды, создающие системы на базе LLM и AI‑агентов.
Как создать исследовательский контур
Для адаптации к новым условиям необходимо формализовать исследовательские процессы и внедрить метрики эффективности агента. На основе бизнес‑требований настраивается сквозной мониторинг: оцениваются время выполнения задач, точность ответов, информационная безопасность и соотношение стоимости вычислений к результату. Системное измерение этих параметров позволяет чётко определять вектор развития проекта. В результате коммуникация с заказчиком переходит на язык проверки гипотез, где каждый спринт становится серией контролируемых экспериментов.
Методология построения исследовательского контура
Нам в прошлом году очень помог такой инструмент, как ML System Design Doc, который мы применяли именно в исследовательских процессах. Самое полезное в решении — то, что можно записывать туда все проведённые эксперименты. Клиент видит проведённую работу, что делает процессы более прозрачными: становится сразу понятно, почему одни решения приняли, а другие отклонили. Инструмент действительно полезный, но требует определённой культуры ведения.
Агенты живут в мире, спроектированном для людей
Традиционно программные системы и сервисы проектируются для взаимодействия с человеком. Однако в текущих реалиях AI‑агент становится самостоятельным актором, который напрямую подключается к внешней цифровой среде. Для такого взаимодействия необходимы принципиально новые точки входа и изменённые сценарии интеграции. Вокруг агентов начинает формироваться собственный протокольный слой, к работе с которым существующая серви
Цифровая инфраструктура пока не готова. Архитектура взаимодействия AI-агента с цифровой средой.
Возникает множество новых вызовов в области информационной безопасности: например, как действовать в случае компрометации агента, как защитить инфраструктуру и как обезопасить конечного пользователя. Ограничение доступа клиентов к агентным технологиям не является жизнеспособным решением, поскольку на рынке существует высокий спрос на персональных AI‑ассистентов. Однозначные индустриальные стандарты для решения этих проблем пока отсутствуют, что стимулирует экспертные дискуссии. В частности, специалисты OpenAI сейчас активно развивают и обсуждают концепцию тестовых сред и систем ограничений для контроля безопасности AI‑систем.
Выводы.
Подводя итог, можно выделить несколько ключевых аспектов трансформации SDLC: разработка AI‑агентов требует обязательного соблюдения дуализма инженерных и исследовательских задач; необходима формализация описания агента, обеспечивающая единое понимание архитектуры проекта всеми членами команды; требуется проектирование специализированной среды для взаимодействия самих агентов, поскольку существующие инструменты (например, Jira) создавались исключительно под потребности человека.
В перспективе производственный процесс изменится: постепенно агент становится стандартным системным компонентом, а роль человека смещается от построчного контроля и написания кода к исследованию границ возможностей моделей. Фокус смещается на управление контекстом, так как именно он определяет качество работы вероятностной системы.
Основной задачей инженеров станет поддержка агентного слоя, трансформирующего идеи продакт‑оунера в готовые фичи. За человеком останется создание визуальных интерфейсов (UI‑kit) для обеспечения целостности клиентского опыта, а также администрирование инфраструктуры (контроль объёма баз данных, оптимизация вычислительных мощностей и ограничение неконтролируемых действий AI).
На данном этапе главным препятствием на пути к десятикратному ускорению написания кода, на мой взгляд, остаются устаревшие подходы самого человека. Инженерам необходимо адаптироваться и найти новое место в производственном цикле, где с рутинными задачами агенты уже справляются эффективно.
А в чём вы видите главное препятствие на пути к ускорению разработки? Мешают ли индустрии старые методологии управления, или же AI‑агенты пока объективно не готовы к enterprise‑нагрузкам? Поделитесь своим опытом в комментариях.
Теги: selectel redmadrobot ml ечный путь вайб кодинг разработка искусственный интеллект
Хабы: Блог компании Selectel Блог компании redmadrobot Искусственный интеллект Управление разработкой Машинное обучение
Нравится +16 Не нравится
Добавить в закладки
7
Поделиться
Комментарии 0
256K+
Охват за 30 дней
Selectel
ВКонтакте
Telegram
Сайт
4K+
Охват за 30 дней
13
Карма
Владислав
@Welltraum
Пользователь
Подписаться
Отправить сообщение
Комментарии
Комментировать
Лучшие за сутки
Похожие
Сайт
slc.tl
Дата регистрации
15 марта 2010
Дата основания
11 сентября 2008
Численность
1 001–5 000 человек
Местоположение
Россия
Представитель
Александр Шилов
Подписаться в Макс
