Одна из самых дорогих встреч в нашем календаре выглядела совершенно обычно. Раз в неделю 20-25 человек собирались на 1,5 часа, чтобы оценить задачи. Раз за разом встреча повторялась, забирая время разработчиков и техлидов, а результат строился на уже известной команде информации: описаниях задач, истории похожих работ и прошлых оценках.
Мы отдали эту работу агенту, которого назвали Эстима. Через 1,5 месяца пилота сходимость его оценки с ручной достигла 95%. После этого встречу отменили, валидацию оставили техлидам и получили экономию около 20 человеко-дней в месяц.
Именно Эстима помогла команде поверить в практическую ценность AI. За ней появились агенты для работы с Jira, ревью кода, разработки, тестирования, аналитики и AppSec. Вместе они постепенно изменили наш PDLC.
Привет, Хабр! Меня зовут Михаил Чернов, я старший IT-лидер направления развития IT взыскания в Альфа-Банке. В этой статье расскажу о нашем опыте перестройки производственного процесса на AI-рельсы, включая пилоты, ограничения и вопросы, на которые мы пока ищем ответы.
Почему отдельного AI-инструмента мало
Контекст нашей работы задаёт масштаб. Мы развиваем CRM-систему для взыскания проблемной задолженности, у которой более 50 интеграций, около 1000 пользователей и команда примерно из 100 человек. Система обрабатывает портфель из миллионов кредитных договоров.
В таком окружении производственный процесс распределен между несколькими командами. Заказчик, бизнес-аналитики, системные аналитики, разработчики, тестирование, дизайн, нагрузочное тестирование, сопровождение и информационная безопасность работают по своим правилам и SLA. Ускорение одного участка быстро создает очередь на следующем.
Вообще до всей этой истории часть команды пробовала AI-помощников, но так как остальные продолжали работать по привычной схеме, то общая скорость почти не менялась. Тогда мы посмотрели на PDLC как на единый поток и начали перестраивать его по этапам.
Вопрос «как внедрить AI» давал слишком широкое поле. Мы заменили его вопросами о процессе:
Где команда теряет больше всего времени?
Какие действия повторяются по одинаковым правилам?
Где уже накоплен структурированный контекст?
Какой результат можно проверить человеком?
Какая локальная метрика покажет полезность через несколько недель?
Затем мы декомпозировали каждый проблемный участок. Большой этап разбивали на маленькие операции, для каждой определяли вход, ожидаемый результат, ограничения и владельца. Так появилась лестница быстрых улучшений: системный анализ, разработка, ревью, QA и AppSec двигались в своем темпе, а каждый законченный кусок приносил самостоятельную пользу.
Важным оказался и проактивный подход к команде и смежным командам. Ранние предложения в духе «давайте мы вам что-нибудь автоматизируем» не работали, так как звучали разного рода опасения, которые можно свести в к трём большим группам:
Первое касалось ответственности. Код, требования и тесты доходят до промышленной среды, а ответственность в крупной системе несёт человек. Заказчики, тестировщики и сопровождение хотели понимать, кто принимает результат агента и кто отвечает за ошибку.
Второе опасение было связано с рабочими местами. Люди слышали разговоры о замене специалистов и воспринимали AI как угрозу. Общие обещания о безопасности только усиливали тревогу. Команде требовался личный опыт, где агент снимает рутину и оставляет специалисту содержательную работу.
Третья причина выглядела как ожидание готового корпоративного решения. Большая компания действительно строит общую платформу и общих агентов. При этом локальный процесс, словарь команды, накопленная документация и конкретные ограничения остаются уникальными. Практический опыт работы со своими агентами впоследствии помогает точнее настроить общебанковские решения.
Мы договорились о простом принципе: ответственность остается у человека, а каждый пилот начинается с узкой задачи и явной метрики. Позже мы показывали уже существующие возможности, вместе искали подходящую боль и запускали маленький эксперимент за счет выделенного IT-капасити.
Итак — все всё обсудили, нашли боли, пора действовать. Мы провели внутреннюю стратсессию направления, где определили карту bottleneck'ов в PDLC и добавили шаги: SA → dev → QA → AppSec — начинаем по частям внедрять агентов, начиная с SA, чтобы есть слона по частям.
Эстима: первый результат, который увидели все
Мы начали с оценки задач, потому что стоимость процесса была видна в календарях. В еженедельной встрече участвовали 20-25 человек, сама встреча занимала полтора часа. Для оценки команда использовала хорошо описанные Jira-задачи, Confluence, ссылки на связанные изменения и историю фактических трудозатрат.
Эти данные стали контекстом для агента Эстимы. Агент находил похожие задачи, сравнивал их содержание и историю выполнения, а затем предлагал детализированную оценку.
Пилот шел параллельно с ручным процессом. Команда продолжала встречаться, Эстима считала свою версию, а мы сравнивали результаты и разбирали расхождения. Через месяц-полтора сходимость достигла 95%. Этого уровня хватило, чтобы оставить ручную валидацию техлидам и освободить всю команду от регулярной встречи.
Эстиме потребовался доступ к рабочему контексту. Так появился помощник для Jira, по сути MCP-сервер с расширенным набором функций. Сначала он обслуживал один сценарий: искал данные для оценки в Jira и Confluence. Затем вокруг него появился интерфейс для массовой работы с задачами. Им начали пользоваться бизнес-заказчики и смежные подразделения.
Эффект? Сократили 20 человеко-дней благодаря тому, что отменили встречи по оценке, а команда поверила в AI и стала писать агентов.
Этот кейс показал два важных свойства удачного старта: у задачи была измеримая боль, а у агента имелась качественная историческая база. Дополнительным эффектом стало доверие команды — первый заметный результат запустил новые инициативы снизу.
Разработка: Диана, Vibe и PR Dispatcher
Следующий набор агентов появился внутри разработки.
№1. Диана выполняет AI-ревью кода до человеческого ревью. Она анализирует diff, стиль, архитектурные паттерны и тестовое покрытие. Разработчик получает обратную связь раньше, исправляет часть замечаний и передает ревьюеру более подготовленный PR. Команда быстро стала воспринимать комментарии Дианы как рабочий инструмент. Позже Диана вошла субагентом в общебанковский агент код-ревью.
№2. Vibe смотрит шире отдельного изменения. Он анализирует репозиторий целиком и показывает участки, на которые может повлиять новый код. Сейчас этот агент проходит пилотирование.
№3. PR Dispatcher выбирает ревьюера. Он учитывает описание и diff, карту компетенций разработчиков и историю Git, включая авторов изменений в затронутом коде. Такой выбор ускоряет назначение PR и повышает шанс сразу попасть к человеку с подходящим контекстом.
Ночные пайплайны: от Jira до черновика PR
После ревью команда собрала два пайплайна разработки. Анжела работает с backend, Снежана с frontend. Мы запускаем их ночью и в выходные, когда корпоративные AI-ресурсы свободнее.
Пайплайн состоит из пяти шагов:
Лейбл в Jira. Разработчик ставит лейбл в Jira, после чего задача попадает в очередь автоматически.
Анализ задачи. Оркестр агентов читает описание, критерии приемки и контекст репозитория, затем готовит план реализации.
Написание кода. Код создается по корпоративным стандартам и архитектурным паттернам команды.
Тесты и ревью. Запускаются unit-тесты и внутреннее AI-ревью. Ошибка возвращает задачу на доработку внутри пайплайна.
PR в Bitbucket. В Bitbucket появляется PR, который разработчик принимает целиком или использует как основу.
Для типовых простых задач результат с первого прохода находится на уровне 80-90%. Лучше всего отрабатываются скрипты, миграции баз данных, простые формы и UI-элементы. На старте показатель был около 20%. Рост дали командные скиллы с корпоративными стандартами, архитектурными правилами и повторяемыми инструкциями.
Сложные изменения по-прежнему требуют активной инженерной работы. К ним относятся задачи с большим числом интеграций, логикой взыскания, требованиями регуляторов, несколькими командами и архитектурными последствиями. Мы расширяем границу применимости постепенно и проверяем каждый новый класс задач отдельно.
Ускорение разработки сразу проявило новую очередь
Разработка стала выпускать больше задач. Но объем изменений превышал пропускную способность команды QA и они буквально просили замедлиться. Так появился пилот агента Милана AI-first QA:
Она собирает контекст из Jira, Confluence и существующих ручных сценариев.
Разбирает требования, анализирует покрытие и предлагает набор новых или обновленных тестов.
На выходе получаются автотесты по требованиям, ручные сценарии и тестовые данные для прогона. QA-инженер проверяет результат и добавляет пограничные случаи.
Этот этап пока находится в пилоте. Для нас важна сама последовательность: ускорение одного звена меняет профиль нагрузки на весь поток. После каждого улучшения мы снова смотрим на карту PDLC и ищем новое узкое место.
Гермес: от одной строки до требований и оценки
В аналитике боль выглядела иначе. Заказчик мог принести идею в одной строке и попросить оценку к планированию. При подготовке мастер-плана таких идей было около 50. Команда тратила неделю на встречи и выясняла, какой смысл скрывался в этом массиве. Чтобы не тратить на этио время мы собрали Гермес — мультиагентную систему из 8 ролей. Часть агентов собирает контекст:
Split разбивает большую задачу или BRD на блоки работ.
Context ищет аналоги в Confluence и дополняет исходную запись.
Checklist формирует компактный опросник и запрашивает уточнения.
Analyze собирает ответы, зависимости и риски.
Вторая группа готовит оценку:
Historical Estimate берет трудоемкость и ролевую разбивку из задач-аналогов.
Solution предлагает быстрый, оптимальный и полный варианты реализации.
Estimate считает оценку по пунктам спецификации.
Describe собирает итоговое описание и таблицу оценок.
Теоретически аналитик способен задать десятки уточняющих вопросов, однако заказчик редко готов отвечать на длинную анкету. Гермес выбирает несколько вопросов с максимальным влиянием на оценку. Чем больше контекста дает заказчик, тем уже становится диапазон риска.
Пилот уже получил положительную оценку бизнес-заказчика и продолжает развиваться. В дорожной карте есть автоматическая подготовка мастер-плана, черновик BRD по транскрибации встречи и интеграция с архитектурной системой. Целевой сценарий выглядит так: заказчик валидирует подготовленное описание, схемы и требования, после чего задача быстрее переходит в системный анализ.
AppSecClient: агент для стыка со смежной командой
Проверка кода средствами информационной безопасности — это ещё одно бутылочное горлишко. Замечания SAST, SCA и Docker-сканирования требовали разбора; часть относилась к нашей системе, часть нуждалась в пояснении, критические находки блокировали выпуск.
AppSecClient получает список уязвимостей, помогает приоритизировать их, предлагает исправления и хранит контекст повторных запусков. У него два режима:
локальный режим использует git worktree и OpenCode,
pipeline-режим запускает задачу в Jenkins.
При неудаче агент может продолжить с сохраненным контекстом.
Для нашей команды это уменьшило количество замечаний и время срочных исправлений перед промышленным выпуском. Для смежной команды это был первый понятный пример агента, который приносит пользу на общей границе процесса.
Как выросло принятие внутри команды
Постепенно из отдельных инициатив сложился единый AI-контур:
Аналитика: Гермес — требования и верхнеуровневая оценка.
Оценка: Эстима — детаилизированная оценка задач.
Разработка: Анжела, Снежана, София.
Ревью: Диана, Vibe, PRDispatcher.
Тестирование: Милана — AI-first QA.
Управление: Жора — Jira, Митя — встречи.
Сейчас мы получаем черновик спеки за минуты, тест-кейсы по требованиям автоматически, а уязвимости исправляются без участия разработчика.. Но технологическая часть это только половина результата. На старте AI регулярно использовали примерно 15-20% команды. После серии внутренних активностей доля выросла до 80-90%, остальные участники как минимум увидели работающие сценарии.
Мы создали AI-штаб для обсуждения агентов и запустили «кружки» по вайб-кодингу. На встречах брали реальную идею, выбирали инструмент и вместе собирали прототип. После трех таких встреч появились еще 4 кружка по отдельным направлениям, потому что желающих стало заметно больше.
Сработали и имена. Эстима, Диана, Анжела, Снежана, Милана и Гермес звучали сначала как шутка, но потом команды начали воспринимать агентов как собственные продукты, заботиться об их качестве и предлагать развитие. Нейминг усилил чувство авторства.
Но что бы я сделал иначе, если бы сейчас начинал по новой?
Вовлекал бы смежные команды с первого дня, а не после пилота. Людям полезно увидеть собственную рутину, снятую агентом, принять участие в сборке и сохранить право финального решения.
Начинал бы культурную работу одновременно с первым пилотом, ведь применение AI это не столько про технологии, сколько про культурную трансформацию.
Не стал бы ожидать, что общебанковский агенты подойдут моей команде. Я бы проверял общих агенты на своем процессе и…Ну а дальше вы уже знаете.
Метрики: локальная польза уже видна, экономика ещё считается
На старте мы использовали слишком общие цели вроде «внедрить AI» и «стать быстрее». Они плохо помогают команде принимать решения. Позже для каждого сценария появилась своя короткая метрика:
Для Эстимы: сходимость с ручной оценкой и число высвобожденных человеко-дней.
Для Дианы: доля комментариев, с которыми согласен разработчик.
Для пайплайнов: доля типовых задач, давших пригодный результат с первого прохода.
Для QA: покрытие требований и объем ручной доработки сценариев.
Для AppSecClient: число закрытых находок и время до готового исправления.
Сейчас мы также собираем журнал сравнения: одинаковые классы задач проходят ручной процесс и AI-процесс, а команда записывает затраты времени и качество результата. Это даст основу для расчета полной экономики с учётом стоимости LLM, инфраструктуры, сопровождения и повторных прогонов.
Громкие обещания об ускорении на 40-50% мы пока не используем. У нас уже есть подтвержденные локальные результаты: 20 человеко-дней в месяц на встречах и 80-90% пригодных результатов на простых задачах. Для ответа о сроке окупаемости нужна более длинная серия наблюдений.
И немного про грабли (куда без них):
Попытка сделать сразу не работают: хотели запустить всё — не взлетело. Процесс был громоздкий, отладка каждого этапа требовала координации всей команды.
Недооценили сопротивление системных аналитиков на старте. Мы особенные говорили они. Нельзя передать ИИ творческий процесс. Регулярно приходилось слушать обоснование, почему ИИ не применим к системной аналитике.
Не определили метрики успеха до начала пилота. Процент применения ИИ в команде не дает ничего. Простые (иногда ручные) подсчеты дают наглядность как для команды, так и для руководителей.
Границы текущего решения
На сессии вопросов меня спросили про единого оркестратора. Мы планируем к нему прийти, когда этапы станут достаточно стабильными. Сейчас системный анализ и QA еще проходят пилоты, а весь процесс пока не образует надежную прямую линию. Ранний оркестратор просто связал бы несколько нестабильных участков.
Второй открытый вопрос связан с эксплуатацией самих агентов. Им нужны мониторинг качества, контроль галлюцинаций, журналирование, владельцы, обновление скиллов и понятная реакция на деградацию. Пока команда наблюдает за агентами вручную и дорабатывает их по результатам.
Третье ограничение находится за пределами разработки. Нагрузочное тестирование, сопровождение и промышленный выпуск живут в собственном ритме. Если аналитика, разработка и QA ускорились, общий lead time упрется в эти этапы. Поэтому следующая волна изменений должна включать смежные команды и их SLA.
Вайб-кодинг тоже имеет ясную область применимости. Хорошие кандидаты сегодня:
Скрипты и миграции базы данных.
Простые формы и типовые CRUD-модули.
Исправление замечаний SonarQube и SAST.
Генерация тест-кейсов по спецификации.
Задачи с пятью и более интеграциями, регуляторными требованиями, сложной бизнес-логикой, несколькими командами и долгосрочными архитектурными последствиями требуют ведущей роли инженера. Агент ускоряет отдельные операции, а человек удерживает целостность решения.
Что посоветую командам, которые начинают путь
Нарисуйте поток от идеи до промышленного выпуска и отметьте время ожидания между этапами.
Найдите одну регулярную боль с понятной стоимостью: часы встреч, очередь PR, ручной разбор сканов, подготовка тест-кейсов.
Декомпозируйте работу до операции с проверяемым входом и выходом.
Подготовьте контекст. История задач, ссылки, критерии приемки и фактические трудозатраты часто важнее выбора модели.
Запустите теневой пилот параллельно с ручным процессом и собирайте расхождения.
Назначьте человека, который валидирует результат и принимает решение о передаче на следующий этап.
Выберите одну локальную метрику, понятную исполнителю и владельцу процесса.
После ускорения снова измерьте весь поток и найдите новое узкое место.
Подключайте смежные команды с первого дня, особенно сопровождение, нагрузочное тестирование и безопасность.
Заранее проектируйте наблюдаемость агентов и собирайте данные для экономики.
Переходите к оркестрации после стабилизации отдельных этапов.
Вместо итога
Работающий AI в PDLC начинается с честного разбора собственного процесса. В нашем случае первым шагом стала дорогая встреча по оценке. Ее отмена дала экономию, доверие команды и энергию для следующих экспериментов. Затем возникли агенты разработки, ревью, QA, аналитики и AppSec, а вместе с ними новые очереди и новые задачи по качеству.
Сегодня мы умеем получать 80-90% пригодных результатов на ряде типовых задач, экономим около 20 человеко-дней в месяц на оценочных встречах и постепенно собираем сквозной AI-контур. Сложные изменения остаются зоной активной работы инженеров, а оркестрация и полная токеномика входят в ближайшую повестку.
Первый полезный шаг можно сделать за несколько недель: выбрать боль, подготовить контекст, запустить теневой пилот и измерить конкретный результат. Команда, которая начала позже, способна быстро сократить разрыв. Здесь важнее регулярность экспериментов и готовность менять процесс.
