red_mad_robot

Что уже можно менять в SDLC, если команда работает с ИИ-агентами

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

Собрали несколько практик из нашего опыта, которые позволяют двигать весь SDLC вслед за возможностями ИИ ↓

Закладывать 3–6 месяцев на адаптацию команды

В нашем внутреннем эксперименте большинство инженеров использовали Cursor в режиме Auto со стандартными настройками. Качественный результат потребовал более глубокой настройки: работы с MCP, контекстными навыками, промптами и системными подходами вроде Plan-Act и SDD.

Даже с продвинутым стеком на встраивание ИИ-ассистентов в инженерные процессы без потери качества кода уходит 3–6 месяцев. Этот период стоит учитывать при планировании эффекта от внедрения.

Переносить контроль с реализации на архитектуру

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

• дизайн API;
• архитектурные контракты;
• схемы баз данных;
• ядро системы.

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

Собирать команды из 2–3 T-shaped специалистов

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

Один из форматов, который сейчас нащупывает рынок, — микрокоманды из 2–3 T-shaped специалистов. Агенты забирают кодинг и первичную проверку, люди валидируют результат и могут перекрывать смежные зоны ответственности.

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

Встраивать исследовательский цикл в разработку

В агентных системах инженерная и исследовательская работа становятся частями одного SDLC.

Инженерная: инфраструктура, API, базы данных, интеграции через MCP, авторизация и права доступа.

Исследовательская: датасеты пользовательских запросов, бенчмарки, эксперименты и бизнес-метрики.

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

Проектировать от бизнес-функций

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

Архитектура раскладывается на две части: управление поведением — промпты, скиллы и агентный цикл — и компоненты взаимодействия — LLM, память и субагенты.

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

Превращать ошибки агента в датасет для следующего эксперимента

Для вероятностной системы отдельный сбой становится эмпирическими данными.

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

Поэтому в агентной разработке рядом с условными десятью фичами в спринте появляется сопоставимый объём гипотез и экспериментов.

Сразу определить четыре параметра мониторинга

Сквозной мониторинг можно строить вокруг четырёх параметров:

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

Так в одной системе координат оказываются качество работы агента, скорость, риски и стоимость вычислений. Сами результаты экспериментов можно фиксировать в ML System Design Doc.

Подробно разобрали эту модель и собрали схемы в новой статье на нашем не менее новом сайте.

red_mad_robot