Raif Agentic Development: AI-трансформация разработки в Райффайзенбанке

Всем привет. Меня зовут Андрей Усавка. Я руковожу направлением разработки финансирования корпоративного бизнеса в Райфайзенбанке.

Мой основной фокус сейчас, это AI-трансформация нашего бизнес-юнита.

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

Три ключевых идеи, которые я хочу, чтобы вы унесли с этой встречи.

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

Как выглядит в 2025–2026 году типовое внедрение GenAI-технологий?

Чаще всего мы берем, например, команду продуктовой разработки, даем каждой роли своего AI-агента.

• Продакт у нас получит ChatVRD,
• Backender получит Codex или Claude, и каждая роль сразу увидит, что за единицу времени она может давать кратно больше Output. У продакта будет сильно больше спек за ту единицу времени, у Backender, сильно больше кода. И кажется, что каждый шаг у нас ускорился.

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

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

Интересно посмотреть на один из кейсов при инжиниринге процессов тоже начала 90-х годов прошлого века. IBM кредит, финансирование покупок для клиентов IBM. Классический кредитный процесс: регистрация кредитной заявки, кредитный анализ, установление условий и так далее. Несколько отделов, несколько ключевых ролей. Соответственно, исследователи посмотрели, сколько занимает реальная работа, совокупная всех сотрудников на протяжении этого процесса. Оказалось, что всего полтора часа. Однако клиент ожидает от подачи заявки до получения результата 144 часа. Это почти неделя. И оказалось, что если каждого сотрудника ускорить в два раза, то экономия для клиента составит всего лишь 45 минут, что, согласитесь, пренебрежимо мало по сравнению со 144 часами. И, в общем-то, один из исследователей, который занимался этим кейсом, сформулировал интересную мысль, что компьютерами пытаются автоматизировать процессы, которые следовало бы просто упразднить и сделать для них тотальный тотальный редизайн. И, в общем-то, в IBM кредит справились с этим даже без компьютеров. Там, по сути, все роли, которые были задействованы в процессе, свели к одной. Здесь я намекаю на продакт-инженера с прошлой встречи. И, в общем-то, это привело у них к тому, что 144 часа превратились в 4 часа для клиента.

Отсюда вывод, что единица AI трансформации, это не сотрудник, не роль, не агент. Единица трансформации, это сквозной процесс вокруг измеримого результата. Что у нас, какие возможности у нас появились по сравнению с 90-ми годами прошлого века? Помимо очевидного, что у нас произошло много итераций компьютерной революции, можно заметить, что любой бизнес-процесс в любой компании, это, по сути, путешествие информации между узлами принятия решений. Часть из которых, это какой-то стандартный классический софт, часть из которых, это люди.

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

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

Однако возникает вопрос: как мы поймем, что та трансформация, которую мы осуществляем, эффективна, полезна? Здесь я напомню классическую дилемму менеджмента output и outcome. В чем их различие? Output, это некие показатели, свидетельства того, что работа идет. Это могут быть субъективные ощущения ускорения от того, что я получил в руки AI-агента. Это может быть количество merge-реквестов, pull-requests, строк кода, написанных агентом. Все это необходимо в условии того, что работа происходит, однако это не гарантирует того, что происходящая работа является полезной и приносит полезный эффект клиенту. С другой стороны, outcome, это именно тот эффект, который мы и стремимся получить, например, когда пишем код. Это какие-то изменения, которые осязает наш клиент. Часто эта дилемма проявляется при постановке цели следующим образом. Можно увидеть, что команда или целая компания ставит перед собой цель внедрить AI во все команды. Или, например, построить харнес, или построить платформу, или добавить такую-то и такую-то возможность в наш платформенный оффер. К чему это приводит? Это приводит к тому, что действительно AI внедрили во все команды, действительно построили платформу, харнес и так далее. Однако к каким это эффектам привело сверх того, что мы что-то построили, чаще всего непонятно. Чаще всего бизнес-метрики остаются на том же уровне, что и до соответствующей постройки.

А вот outcome-цель формулируется иначе. Например, мы можем сказать, что мы хотим, чтобы любое изменение, любая фича, которую запрашивает клиент, клиент получал ее менее чем за 24 часа. Это тот outcome, например, на который нацелены наши команды и наша компания. Мы хотим, чтобы любое изменение, которое клиенту необходимо, он мог получить менее чем за 24 часа. Но более того, мы хотим, чтобы это изменение реализовывалось автономно, без участия людей. И хотим, чтобы качество и надежность не страдали.

Мы считаем наш time to market на текущем этапе упрощенно от заведения задачи в Jira и до приземления соответствующего изменения в продакшн. Это подразумевает под собой, что этот отрезок пути покрывает часть discovery-процесса. Однако значимая часть discovery-процесса пока что у нас находится за рамками этого измерения. Мы на ней будем фокусироваться скорее после того, как мы полностью автоматизируем весь наш delivery pipeline. А здесь у нас есть неплохие результаты по автоматизации. В частности, в результате редизайна нашего процесса разработки нам удалось медиану time to market уменьшить в 36 раз, 85 перцентиль, более чем в 40 раз. И сейчас уже у нас больше 50% задач выполняются автономно менее чем за 24 часа, и 85% всей вообще продуктовой разработки в рамках направления финансирования идет через агентный конвейер.

Мы шли к этому довольно долго, на мой взгляд. Можно увидеть на этом графике. Здесь, кстати, логарифмическая шкала. Еще в 2025 году у нас был доступ к передовым моделям, у нас были AI-агенты. Однако это, как можно увидеть, не приводило к тому, что наш time to market радикально снижался. Вплоть до августа это был, по сути, flatline. И в августе что-то такое произошло, и у нас time to market снизился драматически.

Можно увидеть корреляцию с графиком ниже, что с августа у нас резко выросла доля задач, которые выполняет агентный конвейер, и она продолжает расти. И, надеюсь, до конца года станет 100%. Можно задаться вопросом: может быть, мы купили скорость за счет качества или за счет того, что стали как-то особым образом нарезать задачи. Однако это не так. У нас есть контр-метрики для нашего time to market. Мы, конечно же, следим и за качеством, и за надежностью, и за тем, как у нас задачи нарезаются. И здесь важно заметить, что defect rate у нас остается примерно на том же уровне, что и ранее. Откаты и хотфиксы у нас даже, на самом деле, снизились в два раза. С точки зрения размера изменений его можно померить, например, в файлах, в строках кода и так далее. Мы видим, что эти метрики тоже находятся примерно на том же уровне, что и до внедрения агентного конвейера.

Чтобы понять, что такого важного произошло у нас в августе, почему такой драматический эффект произошел, надо объяснить, как мы смотрим на понятие harness, на какого Какие типы они бывают для нас? Мы для себя глобально, на верхнем уровне, делим, например, на два типа. Это inner harness и outer harness. Inner harness, это, по сути, OpenCode, Codex, Claude Code и так далее. Всё то, что вы можете скачать, купить, локально у себя установить и использовать.

Outer harness, это что-то, что превращает множество агентов в производственную систему, в промышленную разработку. Что такое промышленная разработка? Это инженерные практики, это стиль, это качество, это security, это reliability. Это всё то, как у вас принято в вашей компании подходить к процессу разработки. Эту экспертизу купить и установить невозможно. Она есть у вас, и только вы знаете, как для вас она должна работать. И вот наш outer harness, мы его назвали Atomic, он, по сути, реализует всю эту экспертизу в виде исполнимого процесса. То есть это не какой-то набор хендбуков, инструкций и так далее. Оно всё является частью какой-то единой такой подвижной машины. И эта машина, этот outer harness, реализует, по сути, производственный контракт. Производственный контракт, это ответы на пять ключевых вопросов:

• Кто ставит цель,
• каковы границы автономности,
• какие проверки обязательны в ходе процесса и как они исполняются,
• какой у нас definition of done и, собственно,
• как мы подходим, как мы реагируем на ошибки, которые возникают в ходе эксплуатации.

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

Собственно, у нас раньше были бэкендеры, фронтендеры, Тестировщиков, аналитиков у нас уже довольно давно не было, но, в принципе, с появлением LLM стало очевидно, что любой инженер может быть генералистом, если он обладает достаточной инженерной экспертизой и как минимум в части computer science. Продакт у нас ставит цель. По сути, это означает, что он говорит, для кого и зачем мы делаем, какую метрику мы хотим подвинуть. А product engineer берет это намерение, которое принес продакт, вместе с агентом превращает его в спецификацию, дает на реализацию агентной системе и осуществляет его приемку. Мы кратно отмасштабировали масштаб нашего инженера. То есть, если раньше, например, мы давали нашему бэкенд-инженеру Codex или Claude Code, и он превращался в такого, скажем так, сборщика усиленного мощным электроинструментом на конвейере, который сам вместе с этим электроинструментом осуществляет крупноузловую сборку конечного изделия. То есть, если вдруг с ним что-то случится или если мы хотим как-то масштабировать этот процесс, мы все равно упираемся в некий bottleneck, которым является человек. В противовес этому наш product engineer фокусируется на разработке, улучшении этого конвейера. То есть он строит и улучшает guardrails, задает границы и правила приемки, разбирает какие-то новые, исключительные случаи, обучает систему.

Как мы относимся к спецификациям и как мы вообще ставим цели агентной системе? Здесь у нас подход к спецификациям, они должны снижать неопределенность намерения, а не расписывать план реализации. Мы пробовали описательные спеки, но для нас они не сработали. Мы пробовали разные спецификации в фреймворке, SDD, спецификации в driven-девелопмент фреймворке. Однако в итоге мы пришли к довольно лайтовой версии, в которой у нас есть система, через которую продакт и инженеры взаимодействуют на этапе постановки задачи. В общем-то, прокатываются самоконтролем. Выглядит это примерно следующим образом. Продакт приходит в некий чат с агентом. У агента есть доступ к продуктовому монорепозиторию. И, соответственно, когда человек говорит «я хочу сделать вот такую-то фичу», у агента есть возможность сопоставить его намерение с тем, что уже реально работает в виде исполнимого кода. У него сильно меньше времени требуется на то, чтобы построить некую модель мира. Потом продакт отвечает на ряд вопросов, дает определенные комментарии, после чего у нас появляется некая спецификация намерения. После этого подхватывает работу продакт-инженер и, опять-таки вместе с агентом, проектирует дизайн-решение. По большому счету это тоже сводится к тому, чтобы ответить на ряд вопросов, дать какие-то корректирующие замечания, если это необходимо, и получить на выходе продакт дизайн-документ. Дизайн-документ не расписывает детально, какие файлы надо менять, какие надо там функции добавлять и так далее. Мы в это не верим. Мы верим в то, что агенту нужно, по сути, поставить понятный гоал, понятную цель, к которому агент может делать Kill Clearance. То есть здесь функциональные требования, нефункциональные требования, критерии приемки.

Самое важное, наверное, свойство, договоренность, которая позволила нам кратно забустить наш time-to-market, это договоренность о том, как выглядит наш definition of done.

Для нас весь типовой продуктовый код должен писать агент. Человек, если человек закоммитил что-то в мерч-реквест, который сделал агента или сделал работу руками, это, по сути, ухудшает наши перформанс-метрики. Поэтому у нас есть определенные стимулы для того, чтобы вся работа делалась агентом. В ходе проектирования агентного конвейера у нас было много разных попыток. Мы, по-моему, порядка четырех неудачных версий конвейера построили и освоили ряд уроков. Один из уроков, это то, что ролевые SDLC конвейеры не работают. Они не работают, на мой взгляд, и в классической разработке с людьми, и они плохо работают в том числе в агентной разработке.

Очень соблазнительной выглядела мысль построить конвейер, в котором есть планировщик, есть исполнитель, есть тестировщик, всякого рода критики и так далее. Оказалось, что такой конвейер работает сильно хуже, чем моноагентная система. Здесь наш опыт коррелирует с исследованием Google, которое установило, что на последовательных задачах мультиагентные системы дают результат хуже, чем моноагентные системы. Мы здесь для себя формулируем это как «важно обеспечивать когнитивную непрерывность для агента», чтобы он мог, как и человек, достаточно нелинейно двигаться в ходе реализации задачи, чтобы у него не было жестких ограничений, которые накладываются тем или иным этапом или конкретной ролевой маской. То есть он может поисследовать код, может написать код, запускать тесты в произвольном порядке, взаимодействовать с окружением, со средой, находить какие-то упущения в дизайне. И даже мы его, в принципе, фитим на то, чтобы, если он находит какой-то критический изъян в целеполагании или в ходе своей попытки, чтобы он не пытался довести ее любой ценой до конца, а скорее сдался, сказал, что «я зафейлился». И таким образом у нас появляется возможность критический изъян устранить.

На верхнем уровне наша система выглядит вот таким вот образом. То есть можно увидеть, что здесь есть несколько ключевых слоев. Есть агентный слой, это, по сути, те самые Inner Harness части. Там есть агент, который отвечает за постановку задачи. Есть агент, который отвечает за исполнение. Это самая большая часть именно вот этого Harness-компонента. Есть Refine-агент, задача которого, находить точки улучшения на историческом пласте трасс, комментариев и так далее. И у нас есть огромный, несопоставимо больший кусок. Это детерминированный код, я его называю «система». Классический питонячий код. Там есть такая сущность, например, как контроллер, которая отвечает за очень много очень важных вещей. Например, она удостоверяется в том, что агент-исполнитель действительно прошел, провел все те проверки качества, о которых он заявляет как о пройденных. То есть эта система исследует свидетельства работы, которые остаются после агента. Эта система отвечает за восстановление после ошибок. Например, мигнула какая-нибудь инфраструктурная компонента или, не знаю, вся система упала. Мы не теряем в этом случае стейт и накопленный прогресс. Мы восстанавливаем примерно с той точки, на которой мы упали. Эта же часть отвечает за бюджеты ошибок, за селф-хилинг и за много других вещей. Агент у нас сам не создает никаких MR. Это делает, опять-таки, детерминированный компонент. То есть, в принципе, мы можем увидеть, что система, это детерминированная надстройка над недетерминированной стохастической компонентой. Мы не верим агенту на слово. Несмотря на то, что у агента есть возможность запускать все возможные виды тестов, которые есть в проекте, запускать линтеры, чеки и так далее, у нас все равно эти проверки дополнительно потом будут прогоняться в ходе CI/CD-пайплайна и самим контроллером еще до того, как merge request будет создан. То есть мы пытаемся здесь, до момента передачи изменения в виде merge request на ревью человеку, провести все возможные автоматизированные проверки, которые нам доступны. И в конце у нас есть ревью. И понятное дело, что, когда мы так кратно забустили перформанс нашего конвейера, у нас стало сильно больше кода, который нужно ревьюить. И понятно, что фокус инженеров смещается на то, чтобы обеспечивать это ревью.

И такие объемы кода ревьюить прежним способом становится невозможно. Поэтому инженеры у нас фокусируются не на ревью самого дифа. Мы добавляем некую прослойку, которая эти дифы превращает в набор решений, которые агент принимал по ходу. То есть, по сути, такой некий отчет с какими-то, может быть, визуализациями, который может ревьюить человек. Если ему необходимо, он провалится и посмотрит конкретный диф. Но, в принципе, ревью непосредственно дифа у нас осуществляет тоже агентная система.

Так выглядит наш операционный дашборд, с которого начинает и заканчивает день наша команда. Собственно, тут видно, что уже больше 900 задач за август прошло через агентную систему. Это довольно старый скриншот. Там на самом деле сильно больше тысячи. И success rate у нас порядка 70% накопленный. Это за период 90 дней. Здесь видно такую важную метрику, как приемка с первого раза. Pass at one, 31%. Это, по сути, доля задач, в которых агент идеально справился с решением так, что ревьюер не нашел, к чему оставить замечания, и просто принял это решение. Эта доля у нас растет. Что нам вообще, в принципе, помогает обеспечивать, скажем так, рост ключевых для нас метрик? Несколько ключевых изменений в процессах. Например, раньше у нас было принято сервисы, фронтенды, тесты и так далее хранить в отдельных репозиториях. Ну, так исторически сложилось. Поэтому, когда тебе нужно сделать какую-то фичу, тебе нужно сделать несколько merge-реквестов и оркестрировать вливание этих merge-реквестов в соответствующие мастера и деплой. Мы перешли к концепции монорепозитория. То есть мы берем ограниченный продуктовый контекст и собираем все его сервисы, фронты, тесты, вики, все что угодно, в единый монорепозиторий. Это позволяет нам, во-первых, любое изменение фичи, любую новую фичу в этот продукт, в эту продуктовую область, добавлять всего лишь одним merge-реквестом. А во-вторых, это позволяет агенту в ходе исследования, при анализе и в ходе исполнения иметь доступ к самому широкому из возможных контексту для того, чтобы деливерить качественные решения, для того, чтобы понимать, с каким миром, с каким окружением он работает.

Один из важнейших уроков, который мы вынесли из всего нашего Harness-строения, это то, что преждевременная оптимизация, это зло. Не нужно на начальных этапах, когда вы строите конвейер, пытаться экономить на спичках, экономить токены, доллары и так далее. Это, к сожалению, приводит к тому, что вы просто растрачиваете свои ресурсы. Мы начинали с того, что действительно, конечно же, эту шишку набили. Мы начинали с того, что взяли слабую модель, попытались построить вокруг нее какой-то слишком заумный Harness, который ее пинал в нужном нам направлении. И мы боролись с энтропией, которая исчезла сама собой буквально через несколько месяцев в ходе релиза следующей версии модели того же семейства. То есть мы просто потратили много ресурсов на то, чтобы построить какие-то велосипеды, которые мы тут же выкинули. В общем, с тех пор мы такие ошибки стараемся не допускать. Мы берем готовую компонентную базу. Это агентные фреймворки, в нашем случае это экосистема LangChain. Готовые инструменты для workflow-менеджмента. Observability tools, LLM gateways. Из них мы собираем, моделируем наш Outer Harness-процесс. Моделируем при помощи этих кубиков наш внутренний производственный процесс, который мы, естественно, не можем взять готовым и купить.

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

Агент часто многословен, он часто делает тесты, которые тестируют скорее форму, а не содержание, они тестируют форму, а не поведение. И такие тесты сами по себе имеют очень низкую ценность. И для того, чтобы как-то системно полечить эту проблему, мы разработали автономный цикл самоулучшения. Он запускается раз в какой-то период, читает все ранее не просмотренные комментарии разработчиков к MR в продуктовую монорепу, дальше, собственно, агент анализирует, пытается выявить какие-то типовые повторяющиеся эпизоды и выдвинуть гипотезы относительно того, как можно было бы системно полечить это. После того как он эти гипотезы выдвинул, он предлагает в виде merge request изменения в продуктовую монорепу, в монорепу самого агентного конвейера, если, например, кажется, что можно полечить проблему изменением системного промпта.

У нас уже более 60 таких предложений было сформулировано и принято командой, и это привело к довольно приятному росту метрики решения с первой попытки.

Чтобы скорость поставки стала нормой, необходимо сфокусироваться на четырех ключевых областях.

• Первое и, наверное, чуть ли не самое главное, одна из двух самых главных вещей, это качество постановки в upstream. То есть с какой постановкой, с каким уровнем неопределенности задача приходит агенту в работу. То есть здесь важно всю значимую неопределенность устранить на самом начальном этапе.
• Второе, это стабильная среда проверки, стабильная среда, стабильное окружение, в котором работает агент. Необходимо, чтобы тесты не были flaky, необходимо, чтобы инфраструктура не моргала, необходима мокость зависимостей и так далее. То есть, в принципе, все стандартные инженерные практики здесь применимы.
• Третье, агент не может читать ваши мысли. Поэтому командные договоренности должны жить не в головах людей, а скорее должны перекочевывать, например, в скиллы, промпты, во что-то, до чего агент может дотянуться, чем он руководствуется при решении.
• Четвертое, все проверки, которые возможны, должны быть встроены в процесс. Детерминированные проверки крайне важны. Классические инженерные практики помогают нам выстраивать адекватные границы между продуктами, между системами. Здесь domain-driven design хорошо работает. Нужно иметь довольно высокий уровень покрытия интеграционными, юнит-тестами и так далее. Статический анализ подключить и так далее.

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

Я думаю, что здесь способ это полечить сводится к тому, чтобы работать с майндсетом команды, сводится к тому, чтобы работать над вовлечением команды в те изменения, которые кажутся вам стратегически важными. И, конечно же, на уровне definition of done вы тоже можете сказать, что работа с какого момента у вас считается принята, только если ее сделал агент. Можно не идти full-in, можно применить такое изменение на достаточно ограниченном участке. Например, мы начинали эту трансформацию с того, что одна конкретная команда из пяти пошла полностью в новый способ работы.

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

Поэтому ключевые решения, которые руководитель должен принять в ходе такой трансформации, это первое, сформулировать цель как outcome, то есть как что-то, что клиент может осязать, что он может ощущать. Сформулировать по этой цели амбицию такую, что старым способом работы она просто недостижима. Пересмотреть структуру персонала, то есть какие роли у вас есть в команде, нет ли у вас цепочки ролей, передач между разными этапами. Если есть, лучше сделать одного владельца изменений в процессе. Нужно поработать над тем, чтобы у вас появился контроль автоматизированный, чтобы все проверки были встроены в процессы, автоматизированы. И устранить ловушку демо. Я называю так ситуацию, в которой команда выступает перед менеджментом с красивой демонстрацией агента, который делает работу автономно, преза верстает, код пишет и так далее, а потом ты заглядываешь, как команда работает, а все там происходит так же, на ручном приводе, как и раньше. Эта ловушка демо должна быть устранена. Ну и, наверное, один из таких важных моментов, который неплохо сработал для нас, это вы берете свою North Star метрику, для нас это Time to Market, и какие-то различные его компоненты, и выносите ее на дашборд, за которым вы следите буквально в режиме реального времени, и начинаете каждый рабочий день с этого дашборда.

Я верю здесь в то, что руководитель отвечает за стратегию и делает стратегическую ставку. Но без того, чтобы команда эту стратегию выкупала, понимала и разделяла ваши ценности, эта трансформация не сработает. Потому что именно команда определяет, каким именно способом мы придем к цели. Поэтому, завершая, здесь хочется напомнить главный урок 90-х, это то, что люди пытались раньше автоматизировать при помощи компьютерных технологий процессы, которые следовало бы упразднить и сделать полный редизайн. Сейчас чаще всего мы точно так же используем искусственный интеллект, и мы, конечно же, склонны искать какие-то волшебные таблетки, какие-то инструменты, которые можно скачать, установить и получить решение всех наших проблем. Таких инструментов нет, придется проглотить горькую пилюлю и заняться сложной работой по редизайну существующих процессов. И для того, чтобы понятным образом начать, я бы здесь посоветовал выбрать тот процесс, без которого работу вашей компании представить уже невозможно, и задать себе простой вопрос: как получить тот же самый результат, не проделывая всю эту работу? Это и будет отправной точкой для вашей AI-трансформации. На этом у меня все. Спасибо.

Q1: Слушай, Андрей, а ты говорил, что у тебя там один моноагент, но при этом ревьюит человек. А не было идеи, например, заменить на панели, оркестрированные панели независимых агентов разных моделей, чтобы ревьюили код? И вот если человек ревьюит, bottleneck, он не стал ли новым bottleneck?

• Speaker 1: Ну да, конечно, человек стал новым bottleneck, но человек у нас не единственный ревьюер. У нас так или иначе есть агент-ревьюер, который поставляет какой-то дополнительный фидбэк, отдает его в первую очередь человеку, а не агенту-исполнителю, потому что иначе у нас возникают adversarial-петли, и работа может зацикливаться и не приносить результат. С точки зрения панелей, здесь, наверное, для нас это, во-первых, не сработало в наших первых итерациях, когда мы строили какие-то мультиагентные, мультиролевые системы. Это не приводило нас к нужному результату. И мы решили пойти путем, что будем добавлять сложность только тогда, когда она оправдана. То есть если мы увидим, что агент-исполнитель не справляется со своей работой, только тогда мы будем добавлять какие-то дополнительные роли, этапы и так далее.

Q2: Андрей, говоря о бизнес-юнитах и агентной разработке, на каком масштабе вы начали применять именно агентную разработку? На масштабе каких сервисов?

• Ну, здесь, наверное, несколько вещей играет. Во-первых, если говорить про масштаб нашего бизнес-юнита, это порядка 170 человек в сумме. Это и agile-команды, и операционное сопровождение. Если говорить про количество сервисов, которые разрабатывает агентный конвейер в том или ином виде, у нас было больше 200 продуктовых, сервисных репозиториев. Мы свели их в 10 таких продуктовых монореп. Поэтому масштаб у нас достаточно большой. Все эти сервисы тоже писались годами. Объем кода колоссальный. Здесь, наверное, нет универсального ответа на вопрос, как агенту дать возможность справляться с кодом. Это инженерные практики, то есть то, как у вас код задизайнен, как у вас написаны тесты. Это, опять-таки, вопрос тех инструментов, которые вы даете агенту для исследования кодовой базы. Например, мы какое-то время назад, когда у нас были чуть более слабые модели и немного другая архитектура нашего агента, делали семантический поиск по коду. То есть индексировали его и так далее. Потом мы от него отказались, потому что на текущем этапе для текущих моделей ripgrep дает сопоставимые результаты и не требует никакой upfront-индексации. То есть это все достаточно циклично. Мне кажется, тут вопрос скорее в том, что надо пробовать разное. С течением времени повторно возвращаться к тем практикам, которые не сработали. Возможно, они сработают в новой версии модели или того фреймворка, который вы используете.

Q3: А есть какой-то пример процесса, который вообще агент разработал? Если это не идея.

• Ну, наверное, про бизнес-процесс я тут прямо говорить не буду. У нас есть много разных сервисов, которые реализуют этот бизнес-процесс. По сути, наши agile-команды занимаются автоматизацией кредитного процесса корпоративного финансирования. Там есть разные вещи. Выпуск доверенностей, сертификация, то есть удостоверение подписи полномочных лиц и так далее. То есть там есть самые разные системы. И, по большому счету, если вопрос сводится к тому, насколько сложные изменения агент делает относительно того, что делает человек, то всю ту же самую работу, которую делал человек, теперь делает агент. То есть у нас нет такого, что мы какую-то часть работы оставили агенту, а сами делаем самые сложные задачи. Такого нет, у нас это в definition of done просто записано.

Q4: Привет, я тестировщик. Увидел на слайде, что вы отказались от ручных проверок, от ручного тестирования. И вы переложили это на автотесты: end-to-end, интеграционные и так далее. Интересно, как вы определяете сейчас необходимый масштаб валидации и верификации? Звучит это в крайне резком контексте, будто у вас там стало очень много end-to-end на каждый corner case. Как вы это решаете?

• У нас была какая-то подготовительная работа в части того, чтобы подготовить пирамиду тестирования, обеспечить оптимальную пирамиду тестирования для наших проектов. Мы этим занимались еще весь 2025 год, еще даже до того, как мы как-то массово внедрили агентов. В тот момент, когда мы пришли к продакт-инженерам и так далее, нам стало очевидно, что нам надо унифицировать как-то практики тестирования. Поэтому подготовительная работа какая-то у нас здесь была произведена. Сказать, что есть какой-то научный подход, который можно использовать для того, чтобы понять, что вот такая-то доля end-to-end тестов, такая-то доля UI-тестов, такая-то доля юнит-тестов, и тогда будет все хорошо, я о таком подходе не знаю. Мы здесь действуем скорее исторически. У нас человек так или иначе остается, но на текущем этапе значимая доля пользователей, это люди у наших систем на текущем этапе. И все-таки у нас человек как продакт-инженер досматривает эти MR. Сейчас мы еще не прошли ту точку, когда это физически делать невозможно. Поэтому так или иначе мы, наверное, и глазами, и путем фидбэка от пользователей, который они могут поставлять нам напрямую в чатах, плюс через какие-то SDK и так далее, видим, есть ли какие-то сигналы, которые говорят о том, что произошло падение качества. Пока таких сигналов у нас нет.

Q5: Ага, то есть правильно ли я понимаю, что на уровне команды решается то, что тот, кто ревьюит единоразовые MR, смотрит, проверяет, какого рода там написаны тесты, что они все достаточно хорошо справляются, соответственно, с бизнесовой задумкой, которая возлагалась изначально?

• Ну, прям совсем условно, да. И это тот же самый человек, который, в принципе, утверждал продакт дизайн этой бизнесовой задумки. То есть у нас нет же разделения, что один человек утвердил продакт дизайн, потом агент сделал, потом какой-то третий человек это ревьюит. Мы отказались от этой практики. Смысла в ней большого сейчас нет. Это, во-первых. Во-вторых, у нас уже есть наработанный какой-то набор скиллов, скажем так, инженерных практик, оцифрованных в виде скиллов, которые рекомендуют, какого рода тесты мы ожидаем видеть для наших изменений. То есть мы здесь уже тоже какой-то путь прошли. Естественно, инженеры на первом этапе смотрят на большое количество этого слопа, который генерируют системы, плюются, оставляют какие-то комментарии, переписывают скиллы. Это неизбежно, это так не наладить получится.

Q6: Очень интересный доклад. Два вопроса. Один коротенький, второй уже на размышление. Есть процессы, которые важны по букве закона. Комплаенс, различного рода регуляторика. Там успехи у вас есть или нет?

• Это крутой вопрос, спасибо. Здесь действительно пока что мы упираемся. Ведь это неизбежно, мы будем упираться в ригидность этой части системы. Она будет меняться медленнее, чем всё остальное. Но так или иначе, мы верим в то, что здесь тоже определённая... Во-первых, мы видим сподвижки у коллег в части того, чтобы меняться, внедрять сюда какие-то технологии. Во-вторых, у нас, в принципе, компания API First. У нас всё взаимодействие между подразделениями стремится в дизайне с API. И мы в это очень сильно верим. Ну и, в-третьих, я думаю, что в том числе и законодательство, какие-то там стандарты регуляторные, они тоже будут постепенно меняться, исходя из того, какие технологии нам доступны и что они enable в экономическом смысле.

Q7: Теперь сложный вопрос. В общем, мы агентизируемся, переводим нашу механику управления знаниями. Одна из проблем, это пип точка 0, когда знаний достаточно, чтобы сделать изменение, агенту дать контекста. Мне показалось, что, когда вы перевели всё в монорепозиторий, вы на самом деле убрали со стола тезис, что код, это комодити. Это у вас стало точкой истины, которая используется в контексте как часть базы знаний для того, чтобы агент что-то сделал. Правильно ли мой тезис?

• Правильный тезис, да.

Q8: Добрый день. У меня такой лаконичный вопрос. Вот по докладу вы рассказали, что смогли ускорить разработку в разы или даже в десятки раз. Как вы смогли ускорить своих продуктов на аналогичные цифры, чтобы они готовили описанные цели без неопределенности, и ваша разработка не запускалась еще в самом начале? Потому что у вас конвейер должен начинаться с такой же скоростью еще в самом начале у продактов.

• Да, это крутой вопрос. Я там тоже оговорку делал, что у нас часть дискавери на текущем этапе. То есть мы фокусировались на деливере, дискавери пока что значимой частью за скобками. То есть вот пример того интерфейса, который я показывал, это некий прототип того, как у нас продукт будет задавать задачу. Мы стараемся постепенно влево расширять вот эту часть системы для того, чтобы максимально покрыть, в том числе дискавери. Например, очевидно, что здесь имела место просто квалификация намерений, то есть для того, чтобы агент понял, что я имею в виду. Но ведь до того, как у меня это намерение появилось, тоже какая-то работа произошла. Мы верим в то, что эта работа тоже должна происходить в рамках этой системы при помощи разных коннекторов: какой-то скаутинг внешней конъюнктуры, анализ клиентов и так далее. Он должен происходить именно в этой поверхности. И мы пока что туда сильно прям не зашли. То есть у нас там, в принципе, в компании в этом направлении тоже работа идет за рамками бизнес-юнитс. У нас есть, например, договор о разделе зон влияния и зон фокуса. Мы фокусируемся больше пока что на деливери-части. Но опять-таки мы, в принципе, хорошо знаем, что нам делать. У нас этот бэклог собирался годами. Нам бы его сначала переработать.

Q9: ТМС-архитектор. Раньше была история о том, что происходит ТМС-ки, а потом это всё автоматизируется. Где вот это всё, остаётся ли этот след и кто потом разбирает комплейнты техподдержки и всё остальное?

• У нас эта ответственность принимается в силу именно того, как мы подходим к тому, за что отвечает команда на проекте. У нас эта ответственность никогда не была строго за автотестами. А что касается ТМС, то у нас ещё в прошлом году была вот эта дилемма, оставлять нам comp дивайд тмл, который у нас был, заводить туда это все или нет. Мы там написали какие-то хендлики, инструкции, чтобы инженеры тоже могли это делать. Инженеры на это посмотрели, сказали, что это все фигня, и от этого отказались. Это работу стали делать без ТМС-ки. В нашем случае, я не говорю, что это универсальный рецепт, применимый для всех, мы отказались и от ТМС, и от этой суперформальной части работы автотестера. Что касается тестировщиков, у нас простая дилемма: тестировщик должен стать продакт инженером.

Q10: Но, допустим, когда формируется техническое задание, идёт декомпозиция, и в целом мы можем оценить объём ТЗ на его покрытие тестовой документацией, чтобы понимать и говорить о качестве и с точки зрения тестирования его оценить.

• Да, я понимаю, о чём вы. Я тоже работал в такой компании, у который был вотерфольный подход, но сейчас у нас в компани agile, то есть у нас нет такого что мы ведем, пишем и актуализируем какое-то ТЗ. То есть у нас как-то иначе и по большему счету на агентах устроен процесс, у нас другой подход к разработке, у нас нет ТЗ. Даже сейчас, когда есть агентный конвейер, у нас не пишут детализированное ТЗ, какой то обьем тестов, тестирование.... У нас есть спека. Спека есть. Может быть, она и заменяет ту роль, которой вы наделяете ТЗ. А спека для нас отвечает на ключевые вопросы.. Опять таки форматов того, как её мтожно вести множество, это может быть ТЗ, PRD, ADR, SDD и прочие практики. Все по-разному это делали и делают, но у нас достаточно простая спека: функциональные и нефункциональные требования, non-goals, критерии приёмки. Но мы не прописываем в спеке, какие тесты надо делать: агент сам выбирает в рамках своей траектории исполнения, что сделать. В целом мы сейчас довольны выбором, исходя из того, что в скиллах тоже прописано, что конкретно нужно покрывать, в каком объёме и так далее.

Q11: У меня последний вопрос. Если задача очень сложная и затрагивает несколько продуктов, сервисов и так далее, то есть её нужно очень сильно прогруммить, и она в целом является поставщиком большого бэклога сама по себе. В этом случае агент может не справиться с такой большой историей, где нужно всё сразу сделать. Нужно либо подключать какого-то solution-архитектора, либо того, кто у вас отвечает за эту роль?

• У нас всегда за эту роль отвечают разработчики, у нас не было solution-архитекторов. У нас есть enterprise-архитекторы из компании, но у них фокус вообще в другой области. Если говорить про то, как подобные запросы решаются у нас, то в рамках той системы, которую я показывал, есть возможность декомпозировать. Там был happy pass показан, то есть простая задача, которая заводится, делается и все. Но для сложных задачь есть возможность декомпозировать, соответственно, в рамках delivery workflow, который у нас был. То есть это всё может быть сделано там, потому что у агента есть доступ ко всем продуктовым монорепам. То есть если задача возникает на стыке продуктов, то он может поисследовать все продукты.

Q12: Но в этом случае он должен в рамках своего delivery подготовить backlog и распределить владельцев решений. А кто должен контролировать вот эту историю? То есть это у вас выполнение?

• Агент сам выполняет все эти изменения. Агент делает MRs во все продуктовые монорепозитории. Опять же, он контролирует у себя весь контекст. Так или иначе, у нас же есть подходы. Сейчас любой harness, который вы используете, Claude Code, Codex и так далее, все хорошие harness'ы контролируют весь контекст всего кода, чтобы понять, что делать. Плюс контекст меняется динамически: там что-то загружается, что-то выгружается. Контекстное окно, это, по сути, ключевой элемент стабилизации в любом случае.

Q13: Используете ли вы какие-то инструменты, например subagents, которые выполняют узкие задачи?

• Мы прямо сейчас в моменте не уверены. У нас есть инструмент subagents, насколько он активно используется, надо посмотреть по траекториям, поизучать по traces. Вначале для нас это работало довольно плохо. В индустрии, в принципе, полярная точка зрения на subagents, если честно. Мы сначала приняли одну полярность: никаких subagents. Потом постепенно это разжали и сказали, что агент на своё усмотрение может, например, read-only активности загружать subagent. В принципе, этим пользоваться он может. Насколько это помогает или не помогает, мы каких-то экспериментов, которые бы показали как было и как стало, не проводили.

Q14: Есть ли вообще такая практика работы с долгими задачами, например, несколько часов работы?

• по поводу долгих тасков: у нас не бывает долгих тасков, которые завершались бы дольше, чем за несколько часов. То есть всегда меньше четырёх часов.

Q15: Можно по поводу тестов, точнее технологий тестов? Функциональные тесты всё-таки построены на каком-то фреймворке, в котором реально пишутся автотесты и располагаются в монорепо? Или агент сам берёт, не знаю, какой-нибудь Playwright и сам прогоняет?

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

Q16: Агент, типа, если кроме драйвера: «Ну давай, сделай кнопку на смартфон, раз а элемент не нашел, так?

• Да, у нас довольно мало UI-тестов, то есть они у нас в меньшинстве, просто потому что сам процесс не UI-heavy. Там есть как бы интерфейс. Чуть легче, чем, условно, если бы это был front-heavy интерфейс мобильного банка для retail-клиента. Тут уже нам надо было бы значительно больше инвестировать в эту часть.

Q17: Вопрос в том, каким есть обычный рабочий день такого инженера? С обыденной точки зрения. Понятно, что он строит эту обвязку агентов и в ее построении есть его ценность. Он только это делает либо еще что-то?

• Тут вообще надо сказать, что продуктовый инженер как некая роль оказался для нас движущейся мишенью. То есть, например, в конце прошлого года, когда мы ее внедряли, мы, по сути, отвечали себе на вопрос: актуальна ли существующая ролевая модель, бекендеры, фронтендеры, тестировщики, в мире победившего GenAI? Мы решили, что не актуальна, что нужны инженеры-дженералисты которые разбираются во всем стеке. И, по большому счету, инженеры-дженералисты превратились в продуктовых инженеров. Мы думали, что они будут заниматься в первую очередь тем, что будут писать функциональность руками или с кодинг-агентами. В итоге сейчас у нас инженеры пишут очень мало кода. Когда у нас появился агентный конвейер, они, по большому счету, перестали писать код, кроме написание кода самого конвейера. Поэтому, наверное, 70% их времени уходит на достаточно классические элементы командной работы, командного взаимодействия. Что мы делаем, для кого, зачем, как, почему и так далее. Дальше, конечно же, значимый фокус отнимают целеполагание и ревью. Сейчас в большей мере, наверное, ревью, потому что объем кода довольно большой. Мы стремимся любой ценой протолкнуть изменения меньше чем за 24 часа. Поэтому важно, чтобы они уделяли больше внимания качеству того, что получают. Соответственно, когда они это делают, они оставляют комментарии. Они тут же могут пойти доработать проекты и скиллы из фидбэка. Они тут же могут пойти пообщаться с Harness-командой, подумать о том, какие возможности можно дать агентам конвейера. То есть оно плавает. Q18: Если все так работает, то они должны следить, чтобы вносимые изменения не поломали предыдущие проекты?
• Тыимеешь в виду, чтобы новые правки, новые скиллы не противоречили? Да. Мы поняли, что у нас это происходит, что это drift. Мы отработали систему, которая анализирует эти дрифты, выявляет. И, собственно, это тоже в рамках того цикла агентского самоулучшения происходит. То есть он прям реально находит противоречия в скиллах. Q19: Получаются регрессии, и ты можешь на новой задаче те проблемы получить, с которыми она раньше справлялась. А теперь она стала деградировать?
• Там хуже: там взаимоисключающие параграфы в коде скилла могут выявляться, потому что, например, разные люди в разное время этот скилл писали. Разные агенты под разными ракурсами на это смотрели. Мы такие штуки сейчас выявляем, чиним, чтобы они были целостные. Скилл какой-то экспертизы, чтобы был оцифрован и не противоречивый.

Q20: Так, вы взяли, трансформировали команду. Роли убрали, всех превратили в продакт-инженеров. А дальше, получается, есть какая-то сложная фича. Она декомпозируется, насколько я понял, у вас по доменным областям. Причем кристаллизуется достаточно мелко. Потому что если я крупную фичу отдам команде, то у меня в канале будет поток вот этих продакт инженеров. Они сами будут как-то это все между собой договариваться, взаимодействовать. Получится ровно такая же штука, которая раньше была между ролями. То есть между вот этим большим количеством продакт инженеров тоже начнется взаимодействие и оно начнет занимать какое-то время. Потому что они в контексте какой-то своей доменной области и, возможно, со своим бэкграундом. То есть вы, получается, настолько мелко бьете задачи, потом их раздаете вот этим пяти инженерам по одной. Они потом как-то коммуницируют, а на выходе потом проверяют за собой MRs? Так это работает?

• У нас так не работает. Но, наверное, у нас просто таких крупных изменений, которые затрагивали бы сразу больше трех продуктовых монореп, каких-то смежных систем, мы, наверное, до такого еще не дотянулись. Так или иначе, наверное, просто продакты, может быть, даже с таким к нам в деливери и не приходят. Они сами стараются эти изменения как-то декомпозировать.

Q21: Работа декомпозируется так, чтобы она уложилась ровно на одного инженера. Кристаллизуется до минимума?

• Не кристаллизуется. То есть у нас есть агент, который отвечает за планирование. Ты можешь прийти к нему с намерением. Это намерение может быть раздроблено на составляющие части, если кажется, что оно слишком сложное. Даже вне зависимости от того, сложное оно или нет, мы это оценить на входе не можем. Мы скорее понимаем это по количеству и составу репозиториев, то есть сколько, например, должно быть задач определенного уровня. Чаще всего большинство работ укладывается в рамки, в границы одного продуктового монорепозитория by дизайн. Если у нас что-то появляется на стыке, то есть крупная работа в нескольких продуктах, тогда это будет раздроблено, например, на две-три задачи. За них будет отвечать тот же самый инженер, который, собственно, это изменение вместе с агентом планирует. То есть нет такого, что мы распределим это по трём агентам. То есть за крупную задачу отвечает один инженер. Одно изменение, один человек. Человек должен end-to-end отвечать за изменения, какими бы крупными они ни были. Но мы стараемся просто эту крупноту уменьшить. Q22: Это должно быть получается супер планирование, то есть задача должна быть всегда такой, чтобы один человек мог отвечать за неё end-to-end. Какое-то небольшое, так сказать, взаимодействие, выполнение. Это прямо надо просто идеальное планирование выполнить?
• Ну, я не слышал, чтобы команды с этим страдали у нас, честно говоря. Наверное, мы это побороли на каких-то еще более ранних этапах. Но у нас более такое... Короче, у нас не waterfall, у нас очень agile культура. И у нас мы стараемся, в принципе, ну, как это называется... Задачи, которые вообще непонятно, как сделать, да? Я хочу вот такую-то какую-то штуку, не знаю как она должна работать, но вот я ее поставлю вам в backlog, а вы там дальше разбирайтесь как хотите. Это один story point или это миллион story points? Но у нас такие задачи просто не оказываются в backlog. У нас мои продакт-менеджеры и команда достаточно адекватно подходят и устраняют неопределенность на этапе discovery, до delivery. Это все про discovery. Q23: Вкратце: прилетела какая-то задача от клиента, и он связан с пятью клиентами. Надо сходить до клиента, узнать, что происходит у второго, к дизайнерам, к аналитикам, к продуктам, все вот это собрать и вот эту фичу победить. И этим занимается реально один человек?
• Ну да, этим реально может заниматься у нас один человек, но это, в принципе, и раньше было. У нас один человек может разобрать это все.

Q24: По поводу дизайнеров. В этой связке я не увидел тоже дизайнеров. Если есть какая-то хотелка, ну, надо переделать, сделать новый дизайн из новых компонентов и так далее, как эта вся история происходит?

• Мы это относим скорее в часть discovery, по большей части. У нас есть дизайн-система, которая реализована в виде какого-то кита, которая доступна агенту. То есть агент уже, в принципе, может из UI Kit собирать интерфейс.

Q25: Ну, это должно быть ревью дизайнера?

• Ну, получается, что у нас на этапе discovery может появиться дизайн-макет. Опять, у нас UI довольно мало. Особенно того, который требовал бы выверки, потому что у нас на клиента непосредственно выведено очень мало каких-то там экранов. У нас большая часть каких-то экранов, это интерфейс для сотрудников. Положу руку на сердце, мы не готовы тратить ресурс дизайнера на вычитку интерфейсов для сотрудников.

Q26: Демо сейчас поменялось для клиентов, насколько я помню. И стали ли вы пересчитывать оплату за каждую сделанную фичу?

• У нас, наверное, просто мы не аутсорс в этом плане, да? То есть мы же не продаем там время и экспертизу in-house разработки. С точки зрения демо по внутренним клиентам, ну, оно, по большому счету, довольно похожим образом выглядит, как и раньше. То есть мы по-прежнему показываем какие-то фичи. Добавилась к нему секция harness-команды, которая показывает, ну, типа, успехи производственного процесса.

Q27: Нравятся ли бизнесу и сотрудникам эти изменения?

• У нас бизнес буквально прям смешан, каджый месяц подкидывает задач, регистрирует инвестиции, кредитные программы, новые пенсии. Поэтому здесь намного меньше работы приходится, все близко. Во-первых, с этой точки зрения. Во-вторых, у нас сами линейные сотрудники операционные. Они стимулированы, замотивированны. Активнее воспринимают людей. У нас у всех там общие цели. Наверное, для нас это чуть менее выраженная проблема. Мы стараемся делать все полностью.

Q28: В каком виде получает задачу человек, который ее потом исполняет? Какие то проработанные описания кто и что хочет или это буквально пару строчек типа "сделай красивую кнопку"?

• Раньше у нас был вопрос вариативности большой, когда люди собрали задачи руками, заводили их в Jira, все зависело от скорости человека. Где-то были вообще ванлайнеры, пару строк о задаче и так далее. Мы поэтому разработали эту систему, для того, чтобы она нам минимизировала вариативность. Поэтому от продакта мы получаем полностью конкретные намерения, что зачем, какая метрика, какая механика ожидается. Продакт с агентом сам все это уточняет и прорабатывает. И, соответственно, дальше инженер в таком виде подхватывает. И просто вместе с агентом уже это штормит, как это лучше реализовать

Q29: Какие модели используете? Вот сейчас все переходят на китайцев?

• Ну мы пробовали разные, мы и ChatGPT пробовали, и Kimi, и Qwen, и худшие, наверное, это Qwen, несмотря на то, что их чаще всего используют. У нас показывает себя сейчас Kimi K3. Она прямо просто нас устраивает, даже в сравнении с ChatGPT она дает более приятный код. Без какой-то словесной диареи, которые у нас есть по ChatGPT. У ни

Q30: У меня получилось так, что для разработки я использую DeepSeek 4.1, а верифицирует ее GLM 5.3. И получается так, что в последнее время они, правда, перестали друг друга понимать. Ладно, это не легко.

• У них у всех, типа, есть этот, джект, интеллидженс, то есть сильные и слабые стороны. GLM может найти то, что не нашла Kimi, и упустить то, что легко найдет GPT. То есть они все должны дополнить друг друга.

Q31: Второ вопрос, какая команда делала Harnes, и вытекающий из этого вопрос как она умудрилась это сделать? То есть я так и подумал, вы начали с лабораторий, не сразу, а по очереди, и как далее этот процесс оборудовался?

• Но разработка сама добилась команды а-ля 4 человека, плюс я, там разные инженеры, два классических инженера-женералиста, два NLP-инженера. Работа велась порядка полугода, наверное, по свободности, то есть за полугода мы построили четыре прототипа харнеса, которые не работали, потом за месяц построили, который работал, и начали вот в августе на него переводить всех. И у меня была там простая достаточно эвристика, я просто понял, что это работает. Вот когда я понял, что это работает, на примере, опять-таки, меня с командой, мы прогнали там много всего, имитирующего то, с чем мы обычно сталкиваемся в разных командах. Когда я понял, что это будет работать норм, но неизбежно мы столкнемся с какими-то ошибками, что без этих ошибок мы просто не улучшим агентную систему, мы, несмотря на то, что я рассказывал, что надо действовать ограниченно, мы пошли all-in. То есть все команды получили, скажем так, стимул для того, чтобы вся разработка велась через агентный конвейер, чтобы не писался код руками. У нас были там некоторые исключения. То есть мы сначала исключили проект, который находится на критическом пути деливери, общая, типа, worldwide миграция, по которому должен быть строгий дедлайн. То есть мы не хотели там что-то показывать, какие-то ошибки получить. Это буквально была одна команда из шести. И одна там система была, ее два человека поддерживали, и поддерживают, там комиссии, старые, винда и прочее. Мы просто не хотели, так скажем, возиться там с сендбоксом. Отодвинули в сторону, сказали, ребят, потом разберемся. Вот и все, все остальные пошли в эту историю.

Q32: У вас есть какие то вреймворки для организации контекста и памяти?

• Я понял. Блин, мы, короче, тоже на эту тему, я как раз говорил про велосипедостроение. Вот мы начали сначала велосипедить, мы такие думаем, надо бы нам как-то организовать контекст наших продуктов в том виде, в котором агент может его лучше понимать. Начали дизайнить свою собственную реализацию Deep Wiki. Получилось не очень хорошо. И в тот момент, когда мы поняли, что получается не очень хорошо, Lang Chain выпустил в OpenWiki, и мы перешли везде на OpenWiki. То есть у нас просто есть пайплайны, по ночам они анализируют Wiki продуктовых монореп. Это доступно агенту. А с точки зрения именно памяти какой-то, мы еще не подошли к тому, чтобы какие-то вот именно... То есть непонятно, зачем сейчас эта память? То есть какие конкретные решения она должна запоминать?

Q33: То есть мы, например, начали уточняющие курсы создавать для ролей. И это стало более реалистичным. (неразборчиво)?

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

Q34: Могли бы поделиться опытом. Вы пришли в команду и сказали... Теперь не бэкэнд, а фронтендер. Ты теперь просто инженер. Как работали с сопротивлением? Как реагировали команды? И как вообще вот эту среду перестраивали?

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

Q35: Это понятно. А вот когда уже непосредственно пришло время изменений?

• Мы туда шагнули сильно раньше, чем все остальные компании. Осенью прошлого года мы сказали, что ребята, например, тестировщики, фронты, что у нас было, опсы, вам надо будет делать продуктовые платормы. Мы вам готовы предоставить обучение, которое необходимо. Давайте все вместе сейчас сядем, то, что не хватает в части описания каких-то командных договоренностей, практик инженерных и так далее, сядем, стандартизируем. И мы занимались этой работой, стандартизацией. Через нее, по сути, какие-то инженеры, например, бэкендеры, осваивали какие-то нюансы тестирования, которыми они раньше не владели, не занимались. Сейчас все какое-то время заняло. По большому счету всю эту работу мы в итоге выкинули. Все то, что эти хендбуки мы написали, они в новых реалиях частично в скиллы уехали, частично просто им больше никто не пользуется. Но это было полезно с точки зрения постепенного adoption, для успокоения.

Q36: А остались ли какие-то эксперты, которые, допустим, архитектуру смотрят или все равно?

• У нас были очень неприятные кейсы, мы думали, что у нас есть эксперт, буквально должность называлась - эксперт, и они там даже отвечали на написание каких-то трендбуков и так далее. Пока они писали эти трендбуки и презентовали свою экспертизу, оказалось, что глубина этой экспертизы не настолько недостижима, как мы думали раньше. Она буквально осязаема и легко переносится в обычные классические инженерные роли. У нас есть сильные эксперты-дженералисты, у меня есть несколько таких дженералистов, которые могут абсолютно любую работу сделать, у них ризнинг мощный в любой области компьютер-сайенс. Но в остальном других экспертов у нас не осталось, и даже эти эксперты у меня используются не для того, чтобы верифицировать чьи-то решения, а для того, чтобы решить какую-то крайне типовую задачу в построении Харнесса или оптимизации какой-то его части, чем мы раньше не занимались, RnD короче.

Q37: Последний вопрос. Команды были большие раньше, вы начали проводить эту работу, у вас какой процент сокращений произошел или оптимизаций? Или не случилось, вы всем нашли новое место?

• на самом деле, мы не стремились как-то оптимизировать или сокращать косты, наша цель была и есть TTM. Там были примеры, что люди, например, сами выбирали, что это не для них. Я вот поработаю еще на тестировщиках в компании N. Или, блин, я не понимаю, как я там с тестировщика стану инженером, если я больше не пишу код. Такие люди сами принимали решение, что им не по пути с компанией. Мы никого не форсируем. У нас, по сути, наверное, адвишн рейт на уровне от 5% до 8%. Это супер нормально, с учетом тех радикальных перемен.

Q38: Вы говорили в докладе, что системного анализа у вас уже не было достаточно давно. А что делать компаниям где системный анализ был достаточно давно. И есть огромное количество мест, где что-то написано. БТС, ФОД. Там, я не знаю, какие-то пользовательские документации. И вся эта документация между собой противоречит. Нет какой-то единой точки входа. Она достаточно обширная. Кода тоже очень много, все это лежит разных репозиториях. Соответственно, мне, чтобы построить агентный конвеер... У меня сейчас такая проблема, что все мои агенты убираются в недостоверный контекст. Они мне что-то говорят, принимают решение на основании неистин. Вот как с этим побороться?

• Работа продукта важнее исчерпывающей документации. Простая телеметрия. Скорее всего, в большинстве случаев так и будет происходить в нашем мире. Но там, где у нас были... Мы сохраняли полезный контекст, например, на уровне бизнесового описания. Например, какая-то регуляторика, нормативка, описания сложных продуктов, она остается неизменной. Это осталось и просто перекочевало в условную продуктовую монорепу. Да, все остальное, какие-то вот эти там таблички, схемы, дизайны. Но это всегда было проблемой. Просто оно устаревало еще до того, как агенты и так далее. И нормального решения того, как... Ну, были решения, попытки, типа там: давайте мы сделаем архитектурный тест, сделаем там... Ну, короче, добавим какой-то слой тестирования и верификации. Это же сложно было, очень дорого. Мы этим не занимались. Мы такие вещи просто выкидывали и считали, что вот это является способом решения задач.

Q39: Какие у вас были серьезные инциденты с агентами?

• Вообще, до агентов всегда были... Не, у нас, если смотреть на incident rate метрику, я вот показывал: как бы там defect rate держится на том же уровне, что и раньше. Каких-то прям масштабных инцидентов именно в силу специфики корпоративного бизнеса, корпоративного кредитования. Ну, такие инциденты довольно маловероятны. Там, где, ну, короче, там, где у нас есть потенциальный blast radius довольно существенный, ну, мы прямо там делаем дабл-чек, трипл-чек. То есть мы стараемся. Ну, там реально можно косячить жестко в финансовых проводках каких-то, траншах и так далее. Здесь у нас эти системы еще до агентов были обложены какими-то условиями, тестами, проверками всех мастей. И они были настолько неплохо спроектированы, на мой взгляд,, мы прямо упарывались в этот их редизайн, что сейчас там не происходит никаких инцидентов. Ну, может быть, еще не время. Может быть, мы тут три месяца пожили, может, завтра как раз что-то случится.

Q40: Вопрос по метрике time-to-market. Параллельные модели разработки разных доменов. Вы говорите, что улучшили time-to-market, но смотрите параллельность-то при этом осталась, особенно конфликты merge requests и прочая всякая такая дичь. Если я правильно понимаю, допустим, хорошо спроектированная доменная модель, Да, но тем не менее продукт или ваш бэклог может чейнджить один и тот же домен, да, и при этом нужно конфликты решать. Они решаются у вас на уровне агентного слоя, они у вас решаются на уровне планирования продуктов, фич или как?

• Ну, точно не решаются на уровне планирования, по крайней мере, мне неизвестно о таком способе решения, может быть он где то существует, я просто не знаю о нём. Оно решается всё на уровне уже.... Сейчас вспомню как мы это сделали. То есть агент сам делает rebase. То есть, по большому счёту, у нас там trunk-based, у нас линейная история, у нас все эти конфликты должны как-то иначе решиться в MR-е. Люди уже сейчас не решают эти конфликты, по большому счёту, агенты решают конфликты, и в большинстве случаев с этип справляются.

Q41: А если это происходит просто параллельно, типа один уже отревьюили, уже готов к продакшену, второй ровно на том же домене тоже готов к продакшену?

• Ну, агенты, собственно... Там не совсем агенты, система сложная. Подходы, стратегии себя реализуют.

Q42: А с блокерами что делаете? Например блокировкой домена. Ну, типа мы не редактируем домены, пока идёт редактирование другого домена, и human approval не произойдёт.

• Я, честно говоря, не слышал, что у нас такие конфликты происходили...

Q43 В монорепе? В монорепе они же всегда будут возникать? Ну, когда редактируешь один домен, один продукт хочет фичу А, другой продукт хочет фичу Б?

• А, нет, у нас нет нескольких продуктов одного домена. То есть получается, на уровне управления структурирована вменяемая очередь решений. Можно сказать, правильно. А еще, кстати, важный момент такой: у нас в ходе того процесса, который я показывал, один из агентов в том числе исследует, не противоречит ли фича, которую ты хочешь, тому, что уже есть. То есть, условно, не хочешь ли ты вообще там нарушить границы работы, взаимоисключающие параграфы какие-т добавить в систему, которые не должны быть. Она уже by design работает иначе. Ты пытаешься сломать поведение, которое люди раньше коммитили. Это первое. Второе. Эта же штука у нас сканирует, в принципе, и существующие задачи, чтобы удостовериться, что противоречий уже нет. Потому что мы стараемся вот эти противоречия прямо разрешать сейчас. Я про эту часть уже забыл, потому что давно сделано. Потому что там уже много всего, много граней в этой части было сделано после. То есть в том числе резолв противоречий тоже может осуществляться вот здесь, в этой части системы. Таким образом, в агентский конвейере тебе реально поступает, по сути, готовая очередь задач, на которой pre-base является тривиальным и безопасным.

Q44: Я понял, потому что pre-base, это та самая штука, где агент хорошо ошибается периодически. И второй момент по моделям, инфраструктуре, температуре, reasoning и прочее всякое крутили?

• Мы в прошлом году активно игрались с температурами, reasoning. В текущем подходе мы стараемся не делать этого. Стараемся по умолчанию использовать настройки. Потому что непонятно, как сравнивать. Нужны какие-то довольно мощные инвестиции в бенчмарки, eval'ы, в судьей. Надо больше внимания инженеров на то, чтобы высматривать вот эту регенерацию, которую модели начинают делать. Опять-таки, это всё чаще всего плохо квантифицируемые сравнения. Это вкусовщина. И мы с этим не играемся. Мы стараемся сделать так, чтобы у нас на уровне каких-то инструкций приходило к результату, что для человека приемлемо.

Q45: Ну и потом модели независимы. Если, например, в третьих моделях получается из-за этого по сути не зависеть от того, кто такой. Если вам нужно будет сделать какой-нибудь очередной перебор.

• Мы здесь model-agnostic. Мы стараемся сейчас не спускаться и не делать даун скейлинг на простые модели. У нас есть деньги пока что на то, чтобы не заниматься этим. И чтобы этим заниматься, нужно еще мощно проинвестировать в бенчи. Но бенч у нас так или иначе, материала для него стало сильно больше, чем раньше. Раньше надо было собирать из исторического хвоста задачи разных проектов с разными инженерными практиками. Сейчас у нас плюс-минус функционирование коагентной системы. Практики, например, проектов подвыровнялись. Размеры задач плюс-минус подвыровнялись. Описание задач плюс-минус понятно. Везде одинаково. Поэтому материал для бенча сейчас более богат. Ну начнем заниматься, видимо, будем через какое-то время.

Q46: Получается, здесь SDD вообще не используется? Или как зеркало?

• Но OpenЦiki, скорее, не зеркало, я называю это упрощение навигации для агента. Уменьшить количество хопов, которые требуются ему, чтобы понять, найти нужное. То есть можно это разными способами решать, но мы не используем Semantic Search, мы полагаемся больше на какой-нибудь grep, ripgrep и прочее. Поэтому OpenWiki здесь помогает. А если говорить именно про SDD, это всё-таки сущность другого порядка. Мы там пробовали в своей разработке, еще в вайб-кодинге, например, использовать какой-нибудь OpenSpec, Spec Kit. Про Spec Kit я, честно, уже даже не помню, какие у нас там были результаты. В OpenSpec мы довольно долго жили внутри как раз Harness инжениринг команды. Но вот ребятам нравилось, части ребят. Потом я пришёл, посмотрел, как это выглядит. Думаю: блин, это сложно, честно говоря. Того же результата можно добиться сильно менее избыточным процессом. Это гоняние туда-сюда, по сути. Да, да. Идея понятна: чем больше токенов потратишь направленного брейншторма, тем лучше результат ты получишь, скорее всего, в каком-то вероятностном диапазоне. Но сейчас мы отходим от этой практики и скорее делаем очень лайтовый такой спек SDD в формате, ну, как вот у Anthropic недавно был Playbook. И они этот Playbook опубликовали, в котором говорили, что у нас там есть Intent.Markdown, Spec.Markdown, Design.Markdown, что-то такое. И там буквально эта система у нас реализована очень похоже. Все коммитится в тот же самый Git-репозиторий, что и основной код, но без какого-то там жесткого workflow, который свойственен, например, OpenSpec, и точно с меньшим уровнем вербоузити, чем у него.

Q47: Ну, то есть спека все-таки лежит как то?

• Да-да, конечно. Это важная часть.

Q48: Андрей, я, может быть, прослушал. Что вы именно называете группой ролевых команд и role policy? Это агент-аналитик, агент-разработчик, агент-тестировщик? Да, вот вы сказали, что мы поначалу разочаровались в ролевом конвейере, а потом стали делать так, как сейчас делаем.

• А, да-да-да. Там было... Я пытаюсь вспомнить, что у нас было. На самом деле, очень близко, мне кажется. Какие-то вот такие промпты, как Codex Planning, например. У нас был планировщик, который должен был дать детальный план реализации дать. У нас был имплементер, который план реализации должен был реализовать. Он не имел права, по-моему, у нас писать тесты. Был дополнительно тестописатель. И у нас, по-моему, на каждую фазу были adversary, которые должны были удостоверяться, перезапустить работу, если замечено что-то неподобающее. Да, у нас это не сработало.

Q49: То есть сейчас, получается, агент один?

• Ну, один ключевой исполнитель, который владеет, по сути, ядром end-to-end. Один такой самурай-воин. Есть еще у него, ну, такие, назовем... Не совсем советники, но, короче, может запускаться ревьюер. По завершении работы он запускается, может давать какой-то фидбэк агенту, и агент может один раз доделать что-то или проигнорировать. Он может не согласиться с этим фидбэком, и тогда это просто будет явно закреплено: оно было проигнорировано. Ну и, соответственно, у нас, по большому счёту, мы стараемся не выстраивать ролевые цепочки

Q50: Другой вопрос. Один инженер делает одно задание. Когда я спрашиваю про рабочий день инженера, когда он приходит в команду, и занимается там командной синхронизацией, и тогда в чём эта командная синхронизация?

• Ну, мне же важно понимать, наверное, условно, что я не должен быть с туннельным зрением, потому что я получил задачу, там, и пошел делать один, но это приводит к тому, что у тебя люди становятся шизиками, ну, во-первых, им не интересно работать, наверное, они чувствуют себя просто как исполнители, а кто-то потому что всю свою работу он теперь делает один. Поэтому здесь у нас все инженеры полностью погружены в продуктовый контекст, решают проблемы клиента. Придумывают, как рэтоеализовать. У нас такие команды. У нас такие команды, большие команды, каждый выполняет свою задачу. Сейчас у нас такие команды.