Saint HighLoad++ 2026: как крупный ИТ осваивает ИИ

Прошел очередной Saint HighLoad++ ^[1]. Онтико поменял формат, на конференции было три трека выступлений и два – мастер-классов. Превалировала тема ИИ, ей был посвящен отдельный трек, и еще ряд выступлений и много мастер-классов на других треках. Отмечу новое хайповое слово: harness – им называют обвязку вокруг ИИ – получение контекста, настройку скилов для агентов других правил работы, и так далее. Естественно, это делали и раньше, но на highload появилось модное название, которое на других конференциях не звучит или звучит гораздо меньше. Еще из хайпа следует отметить ai-native и ai-first – ярлыки, которые стремятся на себя повесить, как 10 лет назад вешали лейбл Agile чтобы выглядеть модно, молодежно и прогрессивно. Как и тогда, содержание может быть самое разное.

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

Еще я хочу отметить, что корпорации – консервативны и ждут готовых решений, фреймворков и методик. Они не готовы сами быть драйвером, они готовы лишь догонять. Мелкие компании – готовы, и энтузиасты в корпорациях тоже, потому что тренд ясный. А еще топы банков помнят успех Тинькова, который ворвался на рынок, пока остальные крупные сидели и ждали, и поэтому не ждут. Парадокс ^[2] в том, что без появления нового игрока больше всего шансов у удачливого второго, потому что первопроходец огребает максимум ошибок, при этом в нынешней открытой информационной среде спрятать свои методы первый не может. Впрочем, вырвавшись вперед второй становится первопроходцем, роли меняются, а путь – из многих этапов.

Комментируя выступления, я ссылаюсь на материалы других конференций, на которых я был этой весной. Там как раз более мелкие компании и гибкие делились своими успехами. На Highload и Teamlead они тоже были, и на Teamlead их было больше. Детали можно посмотреть в соответствующих отчетах: TechWriterDays-2026 ^[3], Merge-2026 ^[4], AIconf ^[5], SQAdays ^[6] AnalystDays ^[7], ЛАФ-2026 ^[8], отчет с TeamLead ожидается.

Впечатления первого дня

Первый день #HighLoad в Питере. Я был на треке, посвященном ИИ, выступлений на эту тему было больше одного трека. Многое из услышанного заслуживает подробного разбора, и он будет в моем отчете позднее. А сейчас я хочу по горячим следам зафиксировать несколько тезисов. В том числе для того, чтобы если позднее впечатление ^[9] изменится, эти следы остались. Ну и чтобы, возможно, обсудить это завтра и на Teamlead.

1. Spec Driven Development – это попытка инженеров построить водопад. Хотя бы на ИИ-агентах, если уж на людях не получилось. Не потому, что родился Agile, причина обратная: Agile родился именно потому, что классический подход (водопад, RUP и так далее) – не сработал. И SDD не сработает по тем же системным причинам, так что картинка, которую вы видите в посте по-прежнему актуальна.

2. Внедрение ИИ-агентов (а не ИИ-помощников) не совместимо с привычными способами работы. Даже в варианте SDD. Чтобы внедрить не формально, а получить реальный эффект, надо существенно перестраивать процессы.

3. Что такое «привычный способ работы» – вопрос отдельный. О них был роскошное выступление Даниила Подольского, где он назвал этот метод «колхозный скрам» и очень едко описал. Это когда разработчики делают непонятно что, потому что бизнес описал это невнятно, бесконечно это переделывают и правят ошибки ^[10]. И да, показал, что ему точно придет конец. Замечу, что этот метод от скрама получил только лейбл в то время, когда скрам стал модным. А исторически сложился он задолго до, и в agile-сообществе его называли Code-and-fix. Впрочем, реальный скрам ИИ-агентам тоже не подойдет, потому что он сконструирован для людей, и там команда держит в голове громадный контекст не документируя, в этом есть свои профиты, но ИИ так не может, а выгрузка в артефакты требует переборки метода.

4. По агентской разработки (agentic engineering) Highload не дает фронтира. Там сломались на том, что разработчики стали писать много кода, а как делать review как бы непонятно. Реальный фронтир я слышал на других конференциях, у аналитиков, тестировщиков и других. Там технологично: раскладываем pipeline на операции, выясняем, какие из них и для каких задач уже хорошо делают агенты, выносим на них, следим за процессом метриками, совершенствуем агентов. В результате одни агенты пишут по текстовой задаче acceptance criteria (которые человек проверят), другие – по ним делают тест-кейсы, третьи – делают их ревью, четвертые – по тест-кейсами пишут автотесты или проверяют вручную через mcp-плугин к броузеру и так далее. При этом для разных типов задач – разный уровень вмешательства человека, так что есть агенты или правила классификации задач и выбора pipeline. B надзор качества через мониторинг и выборочные проверки. На уровне общих слов в выступлениях об агентах это было, но вот конкретных кейсов – нет, так что выступления, скорее, об общих представлениях, чем об уже сделанном.

5. О главном изменении в будущем – изменении границы, которую SDD по-прежнему выстраивает по требованиям – никто не говорит. А она – меняется, при этом она кое-где изменилась давно, когда на команду сваливают задачу «наш продукт плохо идет на таком-то рынке, а есть потенциал – проведите анализ, найдите проблемы и решите», вместо классики «сделайте фичу». И бизнес начинает разбираться сам, вайбкодит приложения, а потом приносит команде, иногда со словами «я тут за вечер сделал то, на что вы хотели две недели, забирайте». В общем, это было раньше – разработка через прототипы и MVP, которые сразу идут в прод, если проверка дала успех, а потом развиваются. ИИ в это вдохнул новую жизнь. Это обсуждают в кулуарах в негативном залоге, а то, что именно в этом будет будущее – не видят. Впрочем, через полгода-год – увидят.

На этом пока все. До встречи на втором дне!

Впечатления второго дня

Второй день принес развитие впечатлениям первого. Выступление Андрей Неведин из Райфайзен «Context is a must: как мы системно управляем контекстом» корректирует мой тезис первого дня о том, что SDD (Spec Driven Development) – это давняя мечта инженеров построить водопад, пусть на ИИ-агентах, раз уж на людях не получилось. Все-таки, мечты у инженеров разные, одни мечтали построить совершенный метод разработки на основе тщательного проектирования, а другие – писать платформы вместо бизнес-задач. Для этого в свое время создавались системы, в которых, по задумке, бизнес сам должен был настраивать бизнес-процессы и все остальное, что требуется для них, а на долю разработчиков оставалось бы совершенствование этих систем. Теперь эта мечта переосмыслена: раз отдать бизнесу не получилось, давайте отдадим ИИ-агентам, а мы будем их настраивать, создавать harness, обеспечивая, чтобы они решали эти задачи сами.

И Андрей рассказывал о движении по этому пути. В эксперименте 5 команд, обеспечивающих большие сегменты бизнеса: кредиты, платежи и другие, у каждой такой команды есть команды агентов для discovery задачи, которая пишет спецификации и delivery для реализации, а люди не только подключаются к процессу там, где не получается, но и анализируют – чего не хватило агентам, чтобы сделать задачу. При этом люди не проверяют спецификацию, в отличие от классического SDD, а обсуждают ее с агентами при необходимости. Они в начале пути, агенты активно участвовали в 25% задач, а 4% сделано агентами без людей, при этом ряд областей кода, относящихся к критическим подсистемам, таких как процессинг и риски, агентов сейчас не допускают. И они полны оптимизма, и четко декларируют цель: 100% задач без агентов.

Я этот оптимизм не разделяю, это опыт ^[11] ИТ показывает: несмотря на богатые возможности генерации сайтов, дизайнеры и разработчики сайтов остаются, а описание бизнес-процессов не позволяет покрыть их полностью, так как процессы содержат множество точек с особыми ситуациями, разруливание которых не описывается языком процессов. Аналогично и здесь, агенты смогут взять значительную часть разработки, но не все. Возможно, соотношение будет описываться правилом Парето 80/20, почему бы и нет, только надо понимать, что из тех 80%, подвластным агентам, значительная часть уже сделана людьми без них, до появления этих агентов, так что на текущем потоке будет значительно меньше. При этом при надлежащей организации, которую постоянно поддерживает человек, агенты с нуля разрабатывают весьма сложные приложения, это факт.

Принципиальным вопросом является та часть процесса, которая обеспечивает выполнение задачи агентами. Андрей назвал два фокуса внимания создание контекста и тестирование, в которое они много вкладывают. Но выступление было с фокусом на контекст, про тестирование не говорили. Уже в кулуарах я услышал про выступление Виталия Левченко на Codefest, где он говорил именно о таком переосмыслении SDD: вместо проверки спецификации, которая все равно не читаема, мы проверяем тестовые сценарии и критерии приемки, это гораздо легче и быстрее, для них можно обеспечить читаемость. И тогда процесс едет. Идея понятная и рабочая. Понятно, что она не сработает для задач, в которых соль – в реализации, например, в сложной алгоритмике или декларативных описаниях, где надо сделать гибрид автомата и особых случаев, но доля таких задач в общем потоке не слишком велика.

Во второй день было много практических выступлений, этим он, на мой взгляд, позитивно отличался от первого. Это выступление Александра Иванова про ast-index – средство для быстрого формирования компактного контекста проекта, передаваемого агентам, техническое, со многими деталями и метриками. Были рассказы про конкретные кейсы: Никита Круглов рассказывал про text2sql, а Михаил Кацуба про разработку приложения для распознавания выкладки фруктов и овощей на витрину, впрочем, модельного, а не реального.

Алексей Гладков рассказывал про организацию harness, это была хороший обзор, хотя и без know-how. Вообще интересно: люди уже признают, что harness, который включает в себя контекст, набор агентов и правила их организации для обработки задач – важнее моделей, в кулуарах многие делятся тем, как круто у них получилось его организовать для собственной команды агентов, но вот рефлексии этого, описания устройства в выступлениях нет. Отчасти это понятно, тоже можно сказать про высокопроизводительные или масштабируемые решения: очень редко есть выступления, где показывают, за счет применения каких шаблонов и техник был достигнут успех. А тут область еще молодая, все это in-progress, интереснее доделать, а не рассказать другим.

Ну и в заключение обзора я хочу написать про выступление Леонида Новожилова и Яны Венериной из Сбера про сдвиг идентичности инженера, связанный с ИИ-разработкой. Я увидел в нем очень много внутренних противоречий, характерных для корпоративной культуры. Началось все с теории самодетерминации: для человека важны компетентность, автономность и сопричастность, а появление ИИ обнуляет компетентность, а также разрушает сопричастность, отменяя живой code review и наставничество. И задача потому компании – восстановить это, дав новое представление о компетенции «разработчика с ИИ» – новый взгляд на карьерную лестницу, по которой можно двигаться, обретая идентичность: 6 координат, три уровня.

Выглядит логично. Если не обратить внимание на то, что компетентность разрушил вовсе не ИИ, который никому не скажет «вы больше не компетентны». Ее разрушила корпорация, обнулив, введя еще один грейд и обязав всех разработчиков до конца года его достигнуть. Весьма жесткими методами: ты обязан пройти обучение, далее корпорация будет снимать твои метрики использования GigaCode, и если за 3 месяца они достигнут целевых величин – ты молодец. А если нет – с тобой проведут разбор ошибок и дадут еще месяц. А не справишься – включат запись экрана с автоматическим распознаванием твоих действий и начнут указывать на ошибки. При этом обучение обеспечивает уровень джуна, и по двум направлениям – мидла. То есть подтвердить мидла, не говоря о сеньоре, за счет обучения – не получится. Что для корпорации логично: надо карабкаться к своим вершинам на специфическом снаряжении: GigaCode отстает от топов, а использовать надо его. В выступлении было о том, что многие сеньоры сопротивляются потому, что заботятся о качестве своего продукта, и видят, что GigaCode его разрушит. Так что автономность тут тоже очень сильно нарушена, и тоже корпорацией.

И сопричастность тоже – люди чувствовали себя сопричастным к полезному делу, когда создавали свой продукт и заботились о качестве. А им, фактически, перенаправили на другое дело – соучастие в создании GigaCode в роли группы подопытных пользователей. Не давая выбора и поставив жесткие цели до конца года. Сбер как корпорацию, у которой доведение GigaCode до высокого уровня – одна из существенных целей, можно понять. Конечно, методы достижения цели мобилизацией всех в подопытные вызываю вопросы, но Сбер хорошо платит своим сотрудникам. Так что разработчики done, на очереди – аналитики и тестировщики. И оба выступающих понимают задачу смягчить восприятие таких изменений, чтобы ни не были красным насилием, потому что нынче времена другие, и мобилизация ученых на создание ракетно-ядерного щита родины организацией шарашек сейчас не пройдет. Впрочем, думаю, под «красным насилием» подразумевали не это, а красный уровень спиральной динамики.

Конечно, все написанное – моя интерпретация, я могу ошибаться. Но отчасти ее подтверждает дискуссия после выступления, когда к выступающим подошел разработчик Сбера и рассказал, как все это выглядит снизу. Они были удивлены и говорили, что ничего подобного себе не представляли и не хотели.

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

Про Сбер есть дополнение. В презентации они показывали схемы из документа «AI-Disrupt PDLC» – концепции Сбера по трансформации. Он ищется поиском (я проверил), а на конференции мне его переслали еще в первый день – о нем говорили в кулуарах, и я быстро посмотрел. С моей точки зрения, проблем у документа несколько: (1) он концептуально сохраняет существующий SDLC, а не меняет процессы, (2) он делает ставку на полный автомат исполнения по спецификации, а не на совместную работу человека и ИИ на этом этапе, что не реалистично и (3) он основан на убеждении, что с помощью спецификации можно качественно поставить задачу для гарантированного исполнения – то, на чем сломался RUP и PMBoK, то есть собрать гарантированный водопад на агентах.

Круглый стол Битва за бюджет: интеграция AI должна была сэкономить, а где?

Участники: Вячеслав Тарасов, Кирилл Адещенко РСХБ, Алексей Гладков, Эдвард Сипки. Дальше тезисы без авторства, в некоторых мои замечания, они помечены от первого лица «замечу, что…» или «на мой взгляд…».

Где бюджеты?

• Была задача начала года: сократить штат на 20-30%, не потерять в качестве и еще ускориться. Прошло полгода. Не видит ускорения и оптимизации.

• Сотрудников – не меньше, и добавились подписки.

• Бизнес стал быстрее работать. Но не факт, что больше зарабатывать. Я замечу, что это вопрос к бизнесу: если у него норма прибыли сохранилась, то стал зарабатывать больше. Или он мог уронить цены, чтобы заработать на обороте.

• Была задача начала года: сократить штат на 20-30%, не потерять в качестве и еще ускориться. Прошло полгода. Не видит ускорения и оптимизации.

• А другие – видят. В операционке люди начали решать задачи быстрее – в 3 раза отдел комплайнс, им хорошо заходит агентская аналитика. Цифры очень разуют, не ожидали. Сокращение – не планируется, просто работы делают больше. SDLC – пытаются внедрить, но пока не внедрили, вопрос второго полугодия. QA нравится автотесты генерить, а разрабы – осторожно, ревью – сложнее.

• Чем ближе к физику, тем хуже в реальных кейсах это работает. Много крупных компаний «давайте совершать финансовые транзакции с помощью ИИ». Регуляторнка и риски относятся негативно: как докажете? Возражения «люди тоже не ошибаются» – не принимается. Закона от регуляторов нет, но есть куча рекомендаций разных служб – и они приходят с проверками. И закон тоже.

• Агенты имеют ограниченное окно контекста. У людей тоже ограниченное, но лучше. На ChatGPT поддержку не построить. Но Human in the loop работает. Замечу, что на AIconf было выступление Яндекса о том, как на смеси людей и агентов собирать поддержку для бизнеса. Много уровней, каждого агента отдельно настраивают и мониторят качество. И все работает, агенты дают реальные деньги компенсации при проблемах, и не более щедро, чем люди.

• Стартап. Агенты, которые парсят конкурентов – блог, github и так далее. И это дает офигенное ускорение по придумыванию новых фич. А разработка – на людях, которые действуют с ко-пилотами. Написание кода ускорилось в 1.5-2 раза.

• Угорели больше всего как раз на кодинге – потому что запускали на ночь и агенты жрали все тикеты. Так не надо.

• Много успехов в операционке, генерации контента – персонализировнные предложения с картинками и видео, дизайнеры.

• У банков есть разграничение по персональным данным – их не выложишь в отрытые модели.

Все будет по-другому.

• 5-10% команд, где все хорошо, 60% – немного Qwen и так далее. И остальные – ИИ-диссиденты, бред. У всех performance review. Как будете делать performance?

• Пока performance – по-старому. И если ты за счет ИИ делаешь в 2-3 раза больше – у тебя все хорошо.

• Дмитрий. Тех.директор стал генеральным. И финдир спрашивает: у вас ИИ – расходы или инвестиции?

• Есть льготная подписка opus, которая по полной цене 6к долларов – вопрос когда придет. Поэтому был эксперимент – выдать современные макбуки и на них локальные модели – так тоже работает.

• Нужно изменение mindset!

• Процессы – они же мешают. Мы знаем, как было раньше, умеем прогнозировать (пообещаешь месяц – накинем два). Люди привыкли. А как в новой парадигме сделать процесс прозрачным и прогнозируемым – непонятно. На мой взгляд, вполне понятно – через метрики: если процесс по-прежнему пережевывает задачи или проверяет гипотезы, то метрики не меняются, если у него другой предмет – надо придумывать, но все равно понятно. С прогнозом может быть хуже, но он и раньше был плохой, если исполнители специально не докручивали.

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

• Вопрос: не проще ли подождать, а другие пусть ломают дрова. А мы будем пока по классике? Я замечу, что, может, и проще, но есть риск, что конкуренты съедят твой кусок рынка, банки помнят пример Тинькова. При этом статистически больше выигрывает удачливый последователь, следуя по следам первопроходца, но не совершая его ошибок. Впрочем, вырвавшись вперед второй становится первопроходцем, роли меняются, а путь – из многих этапов.

• Очень важно держать фокус на продукте. Но люди вместо это развивают инфраструктуру. Запретить инженерам оверинжиниирить. Не строить космолет, когда нужна тележка.

Как защищать стратегию на год, когда все быстро меняется?

• Убер и MS защищали бюджеты на год, сожгли за квартал и начали переносить на инфраструктуру или как-то еще. Можно лимитировать. Идея – покупать свое железо. Но оно тоже ограничено, это тоже лимиты.

• Можно представлять ИИ как R&D тему. Отмечу, что это самый простой способ – можно просто осваивать бюджет и не думать про эффект, но руководство уже хочет результатов – в виде сокращений или ускорения.

• В нашей компании Claude-first, и те, кто не умеет – не по пути. А внутри обсуждение, реально используется, проекты ускорились в разы, и люди – сокращаются.

• Да, в маленьких и средних командах это так – а мы отыгрывали, что происходит в больших компаниях.

Реплика. Да, мы работаем в секторе с регуляторами, нет проблем.

Вопрос. Тут фокус на кодирование, а есть еще этап требований. Используете ли для сбора и валидации, и как оно работает? Ответ. Был эксперимент собрать продукт через ИИ. Это было ужасно, комплексно начал ехать кукухой.

Отмечу, что на Highload, Teamlead и других конференциях были рассказы о том, что продукт вполне собирается, особенно с нуля, только надо настроить контекст и правила и присматривать, а не рассчитывать, что ИИ все сделает сам, он – не джинн.

Дмитрий Антипов из Сбер. AI-команда будущего: как меняется разработка продуктов и какие навыки нам нужны

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

Почему ИИ дает в разных командах разный результат? Есть даже две школы: одни говорят, что ИИ галлюцинацинирует и не справляется на нашей специфике, а другие – что программисты больше не нужны, ИИ ускоряет разработку в 100 раз. Разница в том, получается ли у команды правильно подготовить ИИ.

Аналогия «ИИ – армия джунов» уже неверна. ИИ – не джун, его не надо учить разработке, он знает языке. С джунами ты не поднимешься выше своих возможностей. Правильная метафора не джун, а «сеньор с амнезией»: каждое утро – с чистого листа. Он может все, но не знает, как устроена наша работа. LLM – stateless. Нужен harness – обвязка, контекст, в котором мы описываем нашу команду, проект и культуру – метод, которым команда работает над проектом). Эффект того, что получим от ИИ – функция от всего этого.

Между задачей на вход и мерже в прод есть процесс, и он сейчас перестраивается.

LLM видит все в виде токенов. Постоянство нейминга и форматирования – очень важная вещь. Понятный и емкий нейминг и отсутствие мусора в коде – это очень важно.

Столица России: Москва (83%) и Санкт-Петербург (12%) и 5% остального. Тут просто. А в других текстах, включая код – гораздо сложнее. Детерминизма нет.

Запрос «сделай фичу» проходит workflow: намерение → сбор кода вокруг → генерация → валидация. По намерению надо собрать harness: окружение, контекст, образцы, паттерны, которые обеспечат ИИ необходимым знанием. Недостаток или избыток ведут к проблемам: недостаток ИИ закрывает «из среднего знания», избыток ведет к использованию лишнего, а дальше он выдает такой результат, что вы говорите «ИИ – тупой». А он – не тупой, вы его не снабдили знанием.

ИИ дали запрос подвинуть кнопку и группу объектов рядом на 50px. LLM потратило 250к контекста и ничего не сделала. Потому что она подумала, что раз мы говорим про группу объектов, то в коде должен быть объект group, в ожидаемом месте его не нашла и пошла искать с помощью grep по всей кодовой базе. А у нас вообще никакой группы нет, мы просто имели ввиду объекты, визуально расположенные рядом с кнопкой.

Claude code ищет интересующие его места в тексте именно с помощью grep: оказалось, что в кодовой базе среднего качества и размера именно этот способ эффективен. Когда что-то нужно, порождает слова-кандидаты, потом ищет и анализирует, что нашел, идет по дереву – это модель умеет. Если у вас авторизация называется магическими словами, которые не про авторизацию – он ее не найдет.

Поэтому лучший подход – вместо grep использовать другие способы доступа к коду. Можно кодовую базу резать на чанки, и делать векторную базу, но тогда изменение любого файла меняет структуру и это дорого. Вообще способов найти код много, надо смотреть, какие у вас работают. Надо сделать систему такой, чтобы она могла по намерению выделить необходимый контекст.

Я тут, забегая по отчету вперед, отмечу что во второй день было очень хорошее выступление Александра Иванова про ast-index, который как раз решает эту задачу.

Мы даем сигнал в LLM, и дальше вопрос – сколько сигнала (содержания) в сообщении. Идея «закинем все, модель разберется» – работает плохо и дорого. Огромный контекст не значит, что он эффективный. Но все, чего не положили – модель не знает не видит. Есть компактизация. И там потеря смысла, надо не терять сигнал, не замещать шумом. А картина, которую claude code вытащил по grep может быть достаточно произвольной. И очень важно удалять неиспользуемый код – он попадает в grep и индексы. А вот паттерны архитектуры и другие правила разработки вашего проекта важно класть в контекст.

Что делать с SDLC и командой? Мы можем писать гораздо больше кода. А остальные процессы остались. Узкое место – ревью. Путь: Бизнес → Продукт → Разработка. Покрасили кнопку, посмотрели, вернули старый цвет – это быстро.

Раньше разработка была сложной. Теперь разработку может вести агент. Только ему надо больше передать – нужный контекст: почему, точки входа, бюджет, что не трогать; правила, стек, безопасность, конвенции, доступы. ИИ тоже может помогать в сборке контекста. Но не все, и спецификация важная, и ее надо ревьюить.

А еще код – если мы пишем в 10 раз больше, то тест-машина тоже должна работать в 10 раз быстрее. И там надо декомпозировать и все что можно делать автоматикой – автотесты, сборка кода и так далее. Как только это загорелось зеленым – второй слой, AI Review – свои гейты с оценкой. На смысл – соответствие задаче, безопасность, галлюцинации, risk-tier и так далее. И каждая оценка – отдельная. И там может еще отсекать и что-то отправлять человеку.

LLM не только используют при разработке, но и встраивают в приложения. И для их тестирования надо делать Evals, чтобы проверять вероятностное поведение ^[12]. А если мы используем ИИ-агентов в разработке, то для них тоже нужны Evals? которые проверяют их эффективность, оценивают траекторию решения и его бюджет. Для этого надо собирать логи и анализировать. И отсекать, например, ситуации, когда агент что-то пытался поднять в докере, а докер был просто занят – чтобы не тратился бюджет на бесконечные retry.

А гейты человека надо отодвигать в конец SDLC. Вот с этим тезисом я не согласен: агенты работают не бесплатно, при этом с энтузиазмом решат как нужные задачи, так и идут по неверному пути, поэтому на SDLC должны быть спроектированы места проверки, при этом важно обеспечить реальный объем для проверки. Например, уже понятно, что агенты пишут много кода и проводить review не реалистично, а вот архитектурные решения и acceptance criteria проверять можно – они компактны.

Итого. Надо знать свой harness и устройство LLM, оцифровать работу, иметь core-компетенцию проекта но уметь все, system design, думать про бизнес и экономику, нарабатывать инженерный вкус, писать на языке документации. К этому слайду была реплика: если на нем harness и LLM заменить на любую технологию – то это слайд про инженерную культуру, там нет специфики.

Harness и набирание кода в контекст – важнее, чем конкретные модели.

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

Вопрос. Часть контекста – они в головах команды, вне документации. Что с этим делать? Ответ. Важно собирать артефакты, чтобы контролировать следующие задачи.

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

Александр Поломодов из Т-банк. State of AI4SDLC

Массовое использование ИИ наступило, технология стала стандартом де-факто. На уровне инженера – эффект большой, с командой – вопросы, а организации – уже сомнительно. Надо менять процессы. Создание кода – исследовали, а остальные – менее понятно. Adoption высокий, но есть вопросы с доверием. Как ревьюить, тестировать, релизить. Gitlab готовит редизайн своей системы CI/CD.

В прошлом году – помощники, сейчас – автономные агенты. Узкое место переехало.

SDLC – гейтовый, по этапам, с каждым связана своя роль. И каждая профессия пыталась ускорить свои внутренние циклы. Каждый этап внутри создает работу, а передача – по-прежнему сложная. Хотели ускорить, и уменьшить количество людей на своем этапе. Когда про это думаешь, вспоминаешь RUP и V-модель. Spec-driven-development – там контракт для агента, который проверяет результат задачи.

Как выглядят изменения в крупном финтехе? У них все разнообразно.

• Масштаб: 10к инженеров, бесконечно репозиториев, библиотек, строк кода.

• Безопасность: банк, деньги, требования к инфраструктуре.

• Экономика: все инициативы требуют обоснования.

В прошлом году – добавляли помощников. В этом году – история с агентами. И тут метрики. Для бизнеса – скорость, пропускная способность и cycle time. И стабильность поставляемого на прод. И еще история не про сгенерированный код, а экономику в целом, оценить бизнес-эффект. Как считать ROI. Я отмечу, что смена парадигмы требует смены учета, в свое время это показал TOC, потребовав свой набор метрик, и тут надо делать тоже самое.

Пользовательский сценарий уезжает в агента, но платформа не становится тупой базой данных. IDP не умер, умерла монополия на GUI.

Три слоя agent-first-платформы.

• Шлюз для доступа к моделям. Агент не ходит напрямую, там шлюз с анонимизацией информации

• Инструментальный шлюз – чтобы агент достучался к LLM

• Реестр возможностей – что агент может попросить.

Уровни доверия read → recommend → act. Мы не доверяем внешней модели, что он сможет качественно запросить. Например, посмотреть данные по roi при том, что там 10к дашбордов.

Уровни зрелости. agent-first: GUI-only, API+GUI, Read для агентов, Recomend+Act, Governance at Scale (раскатка на компанию).

Модель угроз для агентской разработки. Prompt injection, Tool poisoning (многие устанавливаются локально и сливают дофига наружу), Data exfiltration, Overboard retrieval (как сделать, чтобы поиск не выдавал закрытую инфу), Secrets in context (утекание секретов), Confused deputy (агент действует от твоего имени, но с ограниченными полномочиями – надо настраивать).

Что у них есть.

• LLM-шлюз

• Инструментальный шлюз, часть зашита в платформу, есть MCP-hub, ролевая структура, делегация в ide и внутренние инструменты, ответы опираются на актуальное состояние системы, а не на общие знания модели.

• Spirit – агентский режим на платформе разработки.

• Общие агенты в SDLC-цикле. В тестировании, AI-ревьюер, дизайнер, агенты у безопасников, SRE-агенты для эксплуатации и разборки с инцидентами, и в инфраструткуре. Что-то – в общем использовании, что-то пилотируется на нескольких командах.

Метрики.

Доля AI-кода – соблазнительно, но вредно. Потому что количество кода вообще не влияет на бизнес-результат. Плюс надо ревьюить и так далее. И метрику легко накручивать.

Как измерить влияние AI на SDLC? Выступление Анны Громовой – они использовали для разработке с помощниками, для агентской – докрутили. И это измерение про пайплайну – скорость, качество, инциденты. Ребята смотрят, идут инсайты, например, по сравнению разных языков. Меряем сценарий целиком, и там смесь людей и агентов. Evals и telemetry вместо mau-портала.

Как влияет на работу инженера?

Результаты в разных командах отличается в разы. И хорошо работает там, где люди готовы менять процесс разработки. Часто стимул ^[13] – жесткие сроки. Платформа их помогает, чем является необходимым условиям – дает инфраструктуру. А не получается – у тех, кто поставил плугин в IDE и работает как раньше – ускорение, если есть, то локально.

Продуктовые требования – в git, задача – merge request и так далее. Инструментальное изменение. Многие люди сопротивляются, но это – стандартная часть change management: снимаем страхи, показываем быстрые победы и так далее. Те, у кого получается – им нравится, потому что результатов больше и они быстрее. И качественнее – больше тестов, качественнее сформулированы и проверены критерии приемки и так далее. Рутина уходит, больше времени на дизайн и сложные вещи – и усталость больше от когнитивной нагрузки.

Агенты разные: в локальные редакторе; встройка в CI/CD, например, code review или обработка merge request и так далее.

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

Вопрос не в том, что разрешить ИИ, а как управлять новой физикой разработки.

Материалы выложены на телеграм-канале «Книжный куб».

Иван Поддубный. Уровни зрелости внедрения AI в процессе разработки

В выступлении – модель зрелости, основанная на сценарии постепенной замены человека на ИИ-агента в стандартном процессе SDLC. С моей точки зрения, модель бесполезная, потому что предстоит кардинальная перестройка процессов, а не их сохранение. И человек тоже останется, в том числе на стадии исполнения и будет совместно с агентами решать сложные задачи. То же самое касается моделей от Gartner и Stanford: они преимущественно говорят об интеграции модели в процессы, хотя и только Gartner на 5 уровне говорит о трансформации, а в Stanford на 4 уровне, говорит об оркестрации агентов так, что можно предположить изменение процесса. И SDD тоже разработан в рамках существующей модели процессов и гейты на ней.

Но это не означает, что все выступление бесполезно. В нем очень много полезного о том, как создать работающую систему агентов, как оценивать работу агентов и строить процесс и инфраструктуру. Это – важно. Просто не надо прошивать существующий процесс.

ИВан – СТО вебпрактик, 150 человек. Путь fullstack – teamlead – СТО. И участник програмных комитетов многих конференций , где курирует ИИ.

На конец 2025 – 80% кода с помощью ИИ. Ландшафт – разный, есть начинающие, есть те, кто в космосе. Поэтому много шума. Выступление – попытка задать систему ориентиров.

Модели – Gartner и Stanford. С моей точки зрения, ничего интересного, консультантский флейм. Гартнер дает пять стандартных уровней освоения технологии: не знают, экспериментируют, эксперименты выводят в продакшн, затем интегрируют в процессы, и затем – трансформация. Стэнфорд – описывает распространение управленческой технологии в терминах покрытия процессов: точечное использование, системное использование, отчуждение агентов от людей в репозитории и оркестрация процессов агентами. Если так смотреть, то куча компаний фрагментарно прорвались на последние уровни, не освоив предыдущие потому что уже активно меняют свои процессы. Иван так резко модели не оценивал, но подробно в них не углублялся.

Процессная модель – уровень автономности, ориентирована на процесс и связана с инженерным уровнем.

• 0 уровень: аналитик – разработчик – QA, и артефакты: требования, код, тесты.

• 1 уровень: каждому дали чатик. И он в чатике работает, перенос в артефакты – вручную.

• 2 уровень – локальные агенты на свою машину, они работают с артефактами. claude, codex и прочее. Экзоскелет – усиливают роль. Насколько используют – ответственность человека.

• 3 уровень. ai-native, agent-first, background-agents – агентов переносят на свои сервера. Какие-то блоки или все задачи без человека, человек подключается по требованию human-in-the-loop. Можно масштабировать, за счет запуска большого количества агентов. В конце 2025 на podlodka crew рассказывали про 70% задач через второй уровень, а 30% – на третьем.

• 4 уровень – полная автономность, e2e-решение, бизнес решает задачу через все роли, не привлекая эти роли. Темная фабрика. Некоторые компании говорят, что достигли. AI-фабрика.

С моей точки зрения, уровни 0-3 – реальны. А вот 4 – путь в никуда. На третьем уровне появляется много агентов, и начинает выстраиваться гибридная команда людей и агентов. И следующий такт – кардинальная перестройка процессов, работа этой гибридной команды, которая и обрабатывает задачи и совершенствует себя, свой метод работы.

Можно ли остановиться на втором уровне? Тезис: третий уровень надо развивать параллельно. Сейчас есть инструменты, которые гвоздями прибьют ко второму уровню и вы не сможете перейти в принципе. Поэтому надо выбирать гибкие инструменты – отложенный архитектурный выбор.

Можно ли идти сразу в третий уровень? Нет, слишком много рисков.

Практики: сквозной SDD, quality gate перед merge, observation трейсов, изоляция sandbox, evals – автотесты агентов и так далее – там большой список. Я тут отмечу, что их не надо внедрять по площади, а надо понимать, что уместно для вас и в каком объеме – как и с любыми практиками.

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

Надо строить сквозной процесс, наример openspec – и настраиваем в нем. Аналитик дает спеку агенту, разработчик – ADR, запускает apply, и дальше делаем. Выступления: Подольский и Галкин. Отмечу, что это воспроизводства процесса, а не принципиальное изменение.

Практики.

• Полный тест-сьют зеленый, результат агента проверяет линтер, настроен контроль форматирования и типов

• LLM-judge – соответствие задачи, написаны ли тесты как надо, а не подогнаны под результат, потому что агенты часто подгоняют тесты под результат кода, а не наоборот.

• Observability – работа агентов логируется, логи анализируются, смотрим проблемы, улучшаем работу.

• Бэкенд – LangFuse, поиск, сравнение прогонов. Можно внедрять через личные подписки, а не корпоративными, Можно прикручивать плагин к локальным агентам, собирать со всех и анализировать статистику.

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

• Action policy – когда обязательно подключение человека. Когда агенты достаточно качественно делают определяем, когда все равно нужно review.

• Evals: покрываем автотестами AI-агентов. Проверяем агентов и пишем автотесты. Датасет ваших типовых задач, измеряем качество и регрессы на нем, и дальше – изменяем промпт, harness, skills – проверяем. Можно вносить изменения, не боясь деградации.

• Resource и cost limits. Лимиты на токены/задачу, тайм-лимит.

• Мультиагентная координация – чтобы не было гонок и переписывание. Не всегда они нужны, в один поток может быть лучше, потому что проще.

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

• AI-gateway: LLM-прокси. Там есть нюансы с подписками. Их много, можешь использовать общие токены, а каждому выдавать.

• Кодовый агент с выходом на L3. Многие агенты встроены в IDE, их нельзя запустить автономно – а это блокирует L3. Есть агенты, где IDE и SDK разные и несовместимые. Agents SDK, Codex sdk, pi.dev ^[14], openhands …

• Agent-first IDP. Это впереди. Gitlab duo пытается сделать, может быть и другие. Но рассчитывать не стоит, надо делать самим.

Зайти можно с легких сценариев: консультации по реализации (вопрос аналитика разработчику: а как это реализовано), первичное расследование инцидента, ревьюер, починка flaky-тестов, мелкие баги. Стратегически определите, куда идете. И будет ли L3 эволюция или революция.

Вопрос. Внедрили второй уровень, код порождают – но там очень много багов. Ответ. Есть много инженерных практик, внедрите evals. Отмечу, что тут работают все классические методы борьбы за качество: что делать, когда на проде слишком много инцидентов.

Вопрос. А на ком ответственность в L3? Ответ. На том, кто сделал harness.

И заключительный тезис: разработка стала быстрой, а тимлиды (и продукты) зашились. Это – актуальная проблема.

Даниил Подольский из YADRO. Битва за урожай: внедряем SDD в процесс разработки без его разрушения

Как я писал во впечатлениях первого дня, которые вынесены в начало отчета, в этом выступлении совершенно замечательное стебное изложение описание «привычного способа работы» большинства компаний, которое Даниил называет «колхозный скрам». Местами оно гиперболизировано, но не сильно. И этот процесс точно будет разрушен с приходом ИИ. А теперь – конспект выступления.

Внедряет ИИ в команде и частично в компании. Современным процессом ничего не сделаем, его надо перестраивать. Но для начала хорошо бы посмотреть на то что такое – современный процесс. Голосование: у кого в команде Waterfall, у кого итеративная разработка, у кого Kanban, у кого scrum – большинство. И во всем мире так, реально ничего кроме скрама не осталось.

Только везде это не скрам из руководства, а со множеством оговорок – колхозный скрам.

• Задача поступает как 1 строка в subject, критерии приемки (DoD) для них не описаны.

• Нет нормального цикла планирования – не декомпозируем на входе, оцениваем по той самой общей формулировке.

• Отказ от понимания задачи – нет того, кто знает как должно работать, то есть реальный Product Owner отсутствует.

• Отказ от понимания хода работ – фрагментация команд, разные люди занимаются разными задачами. В Scrum – полнофункциональная команда, по факту специализации и у большинства бас-фактор 1.

• Отказ от тестирования – потому что нет критериев приемки, тестируем собственный код.

• Нет понимания продукта. Есть только интуитивное понимание, что должно быть – а оно различается у разных людей – коллективное бессознательное.

Даниил ненавидит такой процесс всей душой, называет «колхозный скрам». Но у этого есть объективные причины. Методология скрам была придумана для автоматизации существующих бизнес-процессов: они уже работают, надо поставить автоматизацию – именно эта задача стояла в в эпоху нулевых, когда методология развивалась. Если процесса нет, если мы делаем исследование в процессе задачи – скрам не для нас. Отмечу, что это верно лишь отчасти, есть много техник, что делать для продуктовой разработки и в других случаях, когда задачи включают discovery, они были выработаны в 2010-х, я слушал много выступлений на эту тему, и scrum guide был расширен и адаптирован под это. Хотя, это действительно была адаптация, и реально надо выходить за его пределы.

А еще Скрам – методология, которая снижает издержек неудачного планирования и проектирования за счет увеличения усилий по планированию и проектированию, их коллективному проведению. Отмечу, то это тоже было актуально в нулевые: с появлением персоналок потребность ^[15] в разработке возросла, а программистов больше не появилось, потому надо было работать неквалифицированными командами.

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

Человек – равнинный падальщик. Он живет просто: ходит и ищет падаль, найдя – жрет, пока не начнет болеть живот. Тогда идет искать следующую. Так и колхозный скрам: мозг не любит задумываться, он ходит по саванне и ищет падаль. Теперь придется думать.

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

Метрики реального процесса. Планирование: velocity, throughput flow, cycle time, lead time, WIP. Качество: escape defects, technical debt и другие. Team satisfation и customer satisfation. Но это – сложно. Реально колхозный скрам использует всего три вещи: (1) что можно вгрузить в команду, (2) что можно обещать руководству и (3) счастье разработчиков, обеспечивающую чтобы люди не разбегались и не саботировали, которую меряют через текучку разработчиков. Удовлетворенности клиента нет, потому что нет реального PO. Именно об этих метриках мы реально беспокоимся.

SDD – комбинация TDD и DbC – dev by contract. Родом из 1960-х, стандартизован в 2010 до ИИ – предсказуемый результат по критическим путям, и денег на это надо очень много. Скрам дает сравнимый по качеству и гораздо более дешевый результат.

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

Смысл SDD: для начала делаем спецификацию, а потом ее скармливаем ИИ, чтобы он сделал код. Много тулов: Spec-Kit, OpenSpec, GSD, BMAD, можно писать свое или обходиться без этого. Ключевой момент – review человеком спецификации. Двойной расход токенов и тройной расход времени по сравнению с вайбкодингом. Внедрять будем именно SDD. Чтобы был хоть сколько-нибудь управляемый процесс. Спецификации – следы того, как мы мыслим над задачей. Они компактнее кода. И это выгружает наше мышление из головы, оставляет артефакты.

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

Объяснить, почему user story такие странные, зачем они такие подробные и так далее. Люди читать не будут. Что можно с этим сделать? Можно взять архитектора и посадить клепать хорошие задачи из однословных задач, сделанных аналитиком. Но! Архитектор работать над такими спеками не захочет. Вместо этого – нужна архитектура и хорошая постановка: что надо сделать без как надо сделать.

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

Когда задачу засунули в бэклог – надо оценить. Большинство не оценивает, работаем вслепую. Разработчики не умеют оценивать задачи, которые описаны без способа решения. Нежданчик. А это – декомпозиция.

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

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

Проблема. Набирают в спринт не то, что нужно сделать, а то, что знаем как сделать. А что не знаем – оседает в бэклоге.

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

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

Тестирование. SDD – шанс сделать индустрию лучше. TDD, разработка интеграционных и e2e-тестов. Проблема: нельзя проверить качество тестов ИИ. Проверить тесты человека тоже нельзя, но он их медленнее пишет. Можно проверять выборочно.

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

Итого. Попытка внедрения SDD трансформирует колхозный скрам в обычный – то есть ломает процесс. Можно наплевать на SDD и внедрить вайбкодинг – но он просто увеличит количество кода.

Колхозный скрам не спасем. Что будет – неясно. У нас поколения программистов, которые кроме колхозного скрама ничего не знают – это боль ^[16] и слезы. Но немного повысить эффективность – можно.

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

Игорь Дмитриев. DeepSeek и Qwen в enterprise-контуре: строим надежный Flow для классификации чувствительных данных

Это рассказ о применении ИИ для решения конкретных задач работы с данными. Во-первых, с его помощью с данными могут работать не технические пользователи, а не только аналитики, которые умеют писать запросы. Однако, для этого данные должны быть описаны в Каталоге, и там помечены чувствительные данные. И оперативное включение новых данных в Каталог тоже можно делать с помощью ИИ. А теперь – подробнее.

Базовый уровень работы с данными (rare) – безопасное предоставление доступа к данным, чтобы аналитик и могли с ними работать. А well-done – когда могут работать не технические пользователи через ИИ-агента.

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

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

Но агенты ошибаются и галлюцинируют. Для начала агент может просто взять не ту таблицу, о которой говорил человек. Может ошибиться при обогащении описания. Он не знает про ФЗ-152 и другие. А еще может потерять пару тегов при переносе описаний, или ошибитьсся другим образом.

Как с этим работать? Надо поставить процесс работы агента.

1. Описать процесс

2. Сделать методику – инструкции, как каждый шаг процесса выполняется

3. Разработка агента

4. Провести контроль качества

5. Начать эксплуатацию

6. Регулярно получать и обрабатывать обратную связь в ходе эксплуатации.

В начале процесса источник – каталог метаданных. Важно: не пропустить критического в данных, не пометить лишнего. Оценка – полнота, скорость, сравнение с ручной разметкой. Для классификации данных можно взять каталог чувствительных данных, порядка 270 пунктов – его можно взять за основу и доработать. И методику надо обсуждать с ИБ.

Получается Агент: системный промпт плюс перечень чувствительных данных плюс спецификация результата – формат Json. Агент делает бинарную классификацию: чувствительные и все остальные – это проще отладить, а потом уже наращивать категории. User prompt – просто таблица, которую надо описать. И при отладке температуру ставим в 0, это дает детерминированные ответы, без этого мы не знаем: сработала галлюцинация или мы улучшили настройки.

Первая проверка задачи – на мощной облачной модели, это критерий, решаемая ли задача вообще. Потом запускаем на локальной модели и доводим их качество до требуемого. На конкретном кейсе Gemini 3.1 Pro выдала 4% ошибок – это хорошая полнота, сопоставимо с ошибкой человеком. Дальше замеряем локальные модели – на старте они работают плохо, но если тюнить промпт – то качество повышается. Для локальных моделей тюнинг промпта актуален, для облачных – уже нет.

Как тюнить промпт? Даем примеры граничных случаев, выделяем разметкой блоки, описываем рассуждение – рассмотри таблицу, там поле – имя, это чувствительные данные по таким-то причинам. Не надо запугивать модель «нам важно не пропустить критичность» – это сбивает рассуждение, вопреки распространенному мнению Надо именно давать примеры хороших рассуждений в системном промпте.

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

Но у подхода есть предел – размер контекста, который прописываем в промпт – варианты обсуждений и так далее. Есть точка, где есть переполнение. Если повезло – то работает. А нет – разбиваем задачу на несколько, например, отдельно классификация чувствительных данных, а отдельно – другое. Можно доучить модель – для простых моделей fine tune – несложно.

И дальше встраиваем агента в процесс: вместо чата садимся на событие изменения описания таблицы. Тогда уже не надо искать таблицу, она точно известна. А pipeline запускаем через очередь событий. Циклы пропадают, может получиться retry, а если описание не получилось – можно записать в каталог «не смогли описать таблицу» для разбора человеком. Контракт – json, который вклинивается в процесс.

Результаты. – Трудозатраты по разметке сократили в 5 раз – Ошибку удалось выровнять: LLM ошибается не чаще человека. – Time to data сократилась в 5 раз до 1-2 дня. Когда новая таблица появилась – она появляется в каталоге. – Стоимость уменьшилась, работу людей переложили на железо. Работает это в закрытом контуре, где риски поменьше.

Выводы.

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

• Если проверяете гипотезу – проверьте сначала на топовых модельках. А потом уже локальную доводите.

Баттл. AI в продуктовой команде: быстро или правильно?

Задача – определить, где красная линия для AI-агентов в продуктовой команде участники сыграли баттл. Алексей Шерченко защищал позицию, что ИИ дает скорость, поэтому летим быстрее везде, кроме принципиальных решений. Юрий Бабак подсвечивал проблемы: быстрое накопление техдолга и другие. Федор Васильев был модератором.

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

1. Появились ли новые названия ролей?

Алексей.

• Пока – не появились, будет performance review – там новые названия раздадим.

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

• Технический координатор, бывший QA – ходил по командам и просил добавить фичи. Сейчас он большую часть простых задач выполняет сам – новая валюта, конфиги и так далее. Или в мок-сервер добавить путь.

• Дизайнер – у него есть открытый репозиторий, может сам собирать прототипы и отдать готовую штуку фронтендеру – и не надо ждать, пока фронтэндер сделает по описанию и сделанное пройдет пару дизайн-ревью.

• В европейской финтех-компании сделали бота, который знает, контекст проекта, и можно обращаться к нему.

• ИИ ускоряет коммуникацию и смену контекста.

Юра. Экспертиза никуда не девается. Дизайнер может сделать прототип или QA править код. Но у него есть знания про процесс и проект: человек должен понимать что делает. Иначе получается хаотическая фигня и эффект Даннинга-Крюгера.

Штампование прототипа – это хорошо, но когда у вас один прототип, о нем надо договориться, потому что у разных сеньоров свои мнения про хороший прототип. Когда размывается ownership и появляется много случайных контрибуторов – возрастает число ошибок, есть исследования на open source проектах. А это означает узкое горло ответственного – единый ответственный остается. Только раньше ему приносил результат сеньор, а теперь – восторженный дизайнер, поэтому нагрузка на узкое горло возрастает.

Алексей. Да, согласен по ownership. Поэтому задача ответственного – настроить сервис – контекст, тесты и так далее, чтобы приходил хороший результат.

Я тут поддержку Алексея. До ИИ распространенная проблема архитектурных ревью – когда архитекторы просто становятся ступором процесса, потому что требуют, чтобы попали в его личные вкусы и бесконечно отправляют на переделку. Правильная организация без узкого горла – когда архитектор определяет политики и правила, а в сложных случаях – сотрудничает в выработке ^[17] решений, затем дорабатывая политики на их основе. Теперь любой ответственный становится в роль такого архитектора.

2. Архитектура или прототипы.

Юра. Архитектура – важно. Цена написания кода упала, а цена ошибки – нет. И мы бездумным катанием всего подряд на прод сдвигаем ошибки вправо. А если там критический путь, реальный сектор, фарма? Сейчас модели могут содержать много сгенерированного кода. Тщательный анализ и проектирование. Деплой на живую – прекрасно. Агент удалил живую кодовую базу, и доказывал, что нельзя откатить. Работа с ИИ замедляет работу кода, активность выросла, а стабильность – упала, больше точек отказа и проблем.

Алексей. Согласен по многим пунктам, не надо вайбкодить прошивку ядерного реактора. Есть какое-то количество критических вещей, которые надо продумать хорошо. Но мы – преувеличиваем. И куча способов: фича-флаги, А-Б тесты, канареечные релизы и так далее. И переписывать мы тоже можем быстро.

Юра. Да, 80-20, но где гарантии, что ИИ правильно выберет 20 критичных. Переписывать одно и то же – играемся в инженерной песочнице, а не делаем задачи бизнеса.

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

3. Доступ к данным.

Юра. Замечательная идея – организовать с помощью ИИ доступ к данным, но она несет кучу рисков. Самсунг 2023 – инженеры слили в ChatGPT конфиденциальный код и протоколы совещаний. А это – чувствительное место, есть законы и оборотные штрафы.

А еще – вендор блокирует одним днем, и это – не обязательно политика, Антропик блокировал по лицензионным вопросам. Мы получаем кучу рисков остановки компании, как только доступ агентов по mcp включен в основной процесс.

Алексей. Дроп базы или деплой не туда – сплошь и рядом до ИИ было. У ИИ-агента должен быть такой же доступ, как у разработчика. Иначе просто удлинение петли, потому что разработчик делает copy-paste: тупо исполняет запросы, созданные агентом и копирует ему результат.

А еще агент может следить за агентом.

Доступ к логам и данным нужен, там много данных и способность найти в них трейс-ид у бага – сильно ускоряет и упрощает.

Юра. Так и разработчиков на прод не допускают. Агенты косячат больше людей и быстрее.

Алексей. Люди косячат, но мы не защищаем через отрубание доступа. И у агента надо так же как у разработчика.

Юра. Сегодня говорим про исследование инцидента, а дальше будет исправление последствий инцидента. И агент испортит данные прода.

Алексей. Но люди-то все равно могут.

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

4. Косты. Кто за все это будет платить.

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

Например, был сервис, который должен был отправлять события в кафку, но не отправлял, потому что это повышало нагрузку. Есть решение для таких случаев – outbox, но его надо написать, это 2-3 дня разработки. А ИИ может за пару часов, по токенам это дешево. И таких задач масса. Тулзы, админки и так далее – все до чего не доходили руки.

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

Нет исследований, что продуктивность компании выросла. Отдача бизнеса не растет, а капитальные затраты влет улетают. Токены за месяц – это джун-аналитик назад в команду.

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

Юра. А точно ли это место, где надо инвестировать в ИИ. Может, лучше подумать? Туда ли тратить бюджеты?

В конце они обсуждения вопросов вышли на конструктив: задача не воткнуть mcp или ИИ куда-нибудь, а разумно перестраивать процессы. И с этим я согласен.

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

Реплика. Токены – не дорогие, есть бесплатные чаты, есть подписка за 20$ и так далее – и она тоже помогает. Ответ. И надо экспериментировать, разным людям разные подписки, и где-то ставят Qwen, и большинство задач из разработки Qwen решает.

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

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

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

Ситуация.

• Год назад 44% считали, что от ИИ больше вреда, чем пользы, сейчас – наоборот. В мире цифры сопоставимы.

• Неопределенность: 80% людей не планируют будущее, 96% ИТ находятся в состоянии выгорания, 40% боятся, что их заменит ИИ, у 32% признаки депрессии.

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

Опрос разработчиков проективными вопросами в Сбер. Что считают сверхспособностью, и что отнимает ИИ.

·       Результат: ИИ подавляет все, что входит в самодетерминацию: компетеность, автономия, сопричастность. Про компетентность понятно, сопричасность уменьшается, потому что пропадает живой code review и наставничество. А автономия в большой корпорации и так сильно ограничена, а ИИ дает новые возможности следить.

• Джуны должны сами ревьюить код, хотя не готовы.

• У мидлов теряется кайф от работы: ИИ – все придумал за себя, нет момента победы.

• Сеньоры – не саботаж, а проявление лояльности, они знают цену качества и отвергают ИИ, чтобы сохранить продукт. А еще джуны к ним не приходят.

• При этом сеньоры не хотят использовать инструменты, потому что боятся, что несовершенные внутренние инструменты (GigaCode) разрушат, а доступ к профи остановлен. Они знакомятся и тащат внутрь запросы фич.

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

Они обратились к внутреннему сообществу и сделали группы компетенций: prompting, prompt engineering, content management, создание инструментов, создание и использование skills, управление командой агентов. И по этим осям – розочки для ИИ-джунов, ИИ-мидлов и ИИ-сеньоров, в презентации они есть. Сейчас у всех компетенции сброшены в ноль, даже ИИ-джуна их надо подтвердить.

И дальше ведут мониторинг динамики проникновения инструментов и повышения продуктивности команд по цифровым следам и артефактам: GigaCode снимает метрики, смотрят lead time, качество кода, повышение производительности, input-output по токенам. Прохождение назначенных курсов тоже фиксируется, можно оценить слияние на изменение метрик. Есть целевая картинка на конец года и текущая картинка, и с июня начинает работать автомат метрик. Я вижу, что наконец-то сбылась мечта HR – полный автомат online меряет компетенции сотрудников, думать – не надо.

Дальше была резкая смена тему. Когда у нас неопределенность, стоит посмотреть как работают живые системы. Есть парадигма стимул – реакция, так строится работа клеток, людей, организация. Однако, при нем вы всегда будете в отстающих. А чтобы быть лидером, у живой системы есть внутренняя цель – образ того, к чему стремимся. И живая система идет туда, предвосхищает и прогнозирует будущее.

Черные лебеди – стимул чтобы все пересобирать. Но если есть образ результата и он представляется по-прежнему достижимым, то все не разрушено, мы просто идем другим путем.

Архитектура (нейрофизиология) намерений. Есть мотивация ^[18], у нас есть инструментарий, мы выбираем и получаем результат. Мозг сопоставляет полученное и ожидаемое, и дальше стратегия закрепляется или отвергается. И они так же строят путь в рамках организации.

И схема: Intent loop, где намерение на языке спецификации настолько детально, чтобы implemented loop реализовал его агентами без человека. Намерение → Спецификация → (Декомпозиция → Код → Тесты + self-review) → Валидация. Среда дает Контент + Политики + Evals. SDD становится кодом, с которым работаешь. И вместо pull request – намерение + evals.

Отмечу, что схема есть в презентации, она – из документа «AI-Disrupt PDLC» – концепции Сбера по трансформации. Он ищется поиском (я проверил), а на конференции мне его переслали, и я быстро посмотрел. С моей точки зрения, проблем у документа несколько: (1) он концептуально сохраняет существующий SDLC, а не меняет процессы, (2) он делает ставку на полный автомат исполнения по спецификации, а не на совместную работу человека и ИИ на этом этапе, что не реалистично и (3) он основан на убеждении, что с помощью спецификации можно качественно поставить задачу для гарантированного исполнения – то, на чем сломался RUP и PMBoK, то есть собрать гарантированный водопад на агентах. НО вернемся к выступлению.

Этапы: AI-augment SDLC → AI-Native DLC → Agentic development. У них стабильный рост 10-15% производительности команд, они хотят рывок 25-50% и 90% проявленность AI-навыков.

Но надо не просто поставить цели – надо обучить. Нельзя давить и подгонять, иначе будет стресс ^[19], который отключает мышление, доступны только автоматические реакции, и это приведет к выгоранию. Чем больше давить – тем больше сотрудников останутся на старых подходах. При этом взрослых учить сложно, поэтому берем зону ближайшего развития по Выготскому. Как в дайвинге – неосвоенная глубина. Могу и умею → могу с поддержкой → когда-нибудь смогу.

Был честный запуск обучения. О компетенциях договорились в середине мая. Сначала сделали гайд в мае, увидели, что разработчики им не пользуются – и раскатили обучение на 1000 разработчиков, в середине июня запустили метрики. Вообще надо наоборот – сначала метрики, а потом дать инструмент, провести обучение, чтобы люди понимали – что с них будут требовать. Аналитики и тестеры – следующий шаг.

15 марта запустили агента, на конец апреля 37% освоили самостоятельно. В конце апреля запустили два курса. Назначили курсы не всем 14 тыс, а только 7 тыс. И на конец мая прошли 67%, а на вчера – 69%. Похоже уперлись в потолок проникновения у разработчиков. Но метрику сбрасывают в начале месяца в ноль, поэтому сравнение не очень честное. При этом курсы назначили только на разработчиков, но аналитики и тестировщики – тоже проходят курс. И токены быстро тратят. Увеличилось число agentic-пользователей.

Но курсы игнорят. Они смотрели, как прохождение курсов продвигают по навыкам: на ИИ-джуна выходишь, по двум осям они выводят на ИИ-мидла, по другим тоже продвигают. В презентации была конкретная таблица. Но люди все равно ленятся.

Но лень – это экономия энергии. У коллег времени никогда нет, время получаешь сейчас, а результат не очевиден. Мозг будет сопротивляться действиям. Заставлять нельзя, играют мотивацией ^[20] избегания неудачи и мотивация достижения. Избегание неудачи – там кортизол и низкая результативность. А достижение – растет тестостерон, любопытство. Вывод. Надо показывать реальную осязаемую выгоду.

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

Они обучают, проверяют метрику – и сразу сертифицируют, получаешь kpi своего года автоматом. Если за три месяца после обучения нет уровня – то проводят с человеком беседу и дают попытку еще на месяц. Если автомат не получается – то будут включать запись экрана и анализ поведения ^[21] с помощью ИИ-распознавания: применяешь ли надлежащие навыки в нужных точках.

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

Что с наймом? Сбер сократил число джунов, которых нанимает. Мидлов – точно нанимают. Будут менять мидлов с классическим скилсетом, и дальше адаптируют к агентскому кодингу. Кроме агентского кодинга – есть более широкий спектр скилсета, и там тоже идет развитие.

Вопрос. Как будет через год? И hard кандидаты против софтам не-ИТ. Ответ. Сейчас они требуют не ниже мидла по хардам – чтобы он мог ревью делать, а по агентик-кодинг они прокачают.

Вопрос для Яны. На какую биологическую систему разработчики похожи? Ответ: часть большой системы.

Вопрос. Меня обложили курсами, смотрят за обучением и действиями. Как вы объясняете, что треть не сократят, ведь пул работ ограничен. Ответ. Вопрос в доверии, в большой корпорации не доверяют, пытаются работать и восстановить. Суть в построении персональной траектории, чтобы ты был актуален рынку – чтобы внутренний сертификат мог забрать с собой. И чтобы раннее большинство переросло в позднее большинство, помогает внутреннее коммьюнити – именно оно строило компетенции. Не инструмент красной угрозы, а инструмент развития. Кажется, удается.

Александр Иванов. ast-index: как я ускорил агента в десятки раз и сократить расход токенов.

Хорошее, очень конкретное техническое выступление о подготовке кода для контекста ИИ-агентов – код структурируется и индексируется так, что поиск выдает сразу нужные фрагменты, имеющие отношения к решаемой задаче. При этом файлы выдаются не целиком, а тоже интересующий фрагмент и структура вокруг него в формате, которой агент может пользоваться, что существенно экономит токены. Решение выложено в open source. В выступлении было его сравнение с аналогами, там одна относительно долгая операция полной индексации, но далее можно достраивать по изменениям. Но при этом полная индексация все равно достаточно быстрая, чтобы строить индекс для конкретной ветке ,в которой работает агент и удалять его вместе с веткой: аналоги хранят индекс, и его строят только для основной ветки, а это означает, что локальные изменения ветки в нем не учитываются. А теперь подробнее.

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

Базовый поиск – grep, плоский текст. Человек смотрит начало выдачи, добавляет параметров в описание задачи – фокусирует поиск. Индексированный текстовый поиск – тоже самое, просто быстрее. Есть таговый поиск – он более структурный, но он не понимает структуру кода.

Есть инструменты поиска, которые используются в IDE – для подсветки кода, рефакторинга и других целей. Но они выдают тяжелый json именно для IDE. Еще есть code intelligence platform с индексацией – но там дорого держать все ветки. И есть структурный поиск ast-grep.

Агенты тратят большую часть токенов на поиск и чтение файлов. Они реально посмотрели трейсы, на это уходит 62% контекстного окна, а только 30% на кодирование – выполнение задачи. Поэтому надо фокусировать поиск. И инструмент должен выдавать сжатую информацию, а не json с кучей лишнего, быстро и стабильно, и выдавать не полный файл, а только нужный фрагмент.

Он начал разрабатывать с агентами в сентябре. И в декабрю пришла задача, где нужен архитектурный рефакторинг большого количества файлов. Сморит – агент ищет долго. Он полез в студию, там ищет классы и подсказывает агенту. И он задумался: почему он полез в студию, чтобы подсказать, где искать нужный класс. И тогда написал первую штуку, которая индексирует, агент вызывает ее с помощью mcp и ищет быстро. Потом mcp заменил на cli – и еще в 5-10 раз уменьшилось потребление токенов. Это было на python, поиск занимал полсекунды, и он переписал на rust – ускорение 100-200 раз, 8мс поиск. А дальше – развитие и масштабирование – добавление языков.

Архитектура

1. Интерфейс – cli. mcp не может использовать человек – сложно отлаживать. А cli ты вызываешь из консоли, можешь посмотреть трейсы и отлаживать запросы.

2. Контур поиска. Разбор команды, поиск в sql-lite базе, и дальше выдача ответа в компактном виде.

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

4. База – хранение индекса, она лежит отдельно, и можно индексировать отдельные ветки под задачу, с которой работает агент.

Проект 30к файлов индексирует за 30 секунд. А дальше – инкрементальное обновление по файлам, и это обновление можно включить в фоне, 8-10мс на файл. И там одна cli и около 30 сценариев-команд.

Внедрение в апреле, и сейчас около 3000 разработчиков, которые используют, распространяется по командам. Rebuild – недешевый, 10 сек 250к файлов и 2Гб памяти ^[22], но приемлемо. ast-grep – ближайший родственник, но дороже по времени и нагрузке – в презентации конкретные данные, ускорения в 1000 раз даже при прогретом кэше ast-grep. Был A/Б тест на одинаковых задачах. Получили, что на чтение и поиск затраты 22%, а 68% на реализацию, и сокращение токенов на 40%. Внутренняя телеметрия: что агент спрашивает на практике, 525к за месяц. Помимо поиска, агент читает файл структурно, а дальше вычитывает нужные строки точечно.

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

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

Выводы. Найдите боль агентов, делайте качественные инструменты, радуйтесь работе с агентом и рассказывайте другим.

Вопрос. А затем такие тысячи файлов, супер-монолит? Ответ. У них в Яндекс-Go 30к файлов, и еще бэк. А в финтехе – там по 170к файлов, а кто-то миллиона файлов выбрал. Фича – 50-150 файлов, которые не лежат в одной папочке, а распределены по разным веткам в дереве и связаны – такие микролиты….

Алексей Гладков. Harness на стероидах

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

Как перейти от 300$ за хаос к 30$ за систему? В октябре 2025 появился первый harness в claude и codex. Первые фичи успешно порождаются, но несовершенно. Ассистент пишет средний код, галлюцинирует зависимости и permission, не понимает контекст. Если вы не забили, то в декабре 2025 – первые циклы, 10-12 часов сессия, чтобы приносило value, автотесты, распределение нагрузки.

Harness – упряжка, у вас есть куча агентов, которую работают над задачей. И это – дорого, 12$ на среднюю стоимость одной задачи по api когда подписки уйдут. Дорого и неэффектино. Люди открывают один поток и там по всем ролям. Я тут замечу, что 12$ – это полчаса ставки разработчика, так что не слишком уж и дорого – если за это время реально делают задачу. Хотя, конечно, не ноль.

Агенты должны писать код, пока мы чем-то другим занимаемся. Но надо непрерывно дописывать промпты, дорабатывать harness. Что можно оптимизировать?

Токены. Основное – чтение файла и анализ контекста 50%. Caveman – нейронка многословная, это сжимает ее сообщение в фразу «я скачала логин» – в 5-7 раз меньше токенов. Ast-index, был в прошлом выступлении было. Не 100 файлов, а 3. Примерно в 40 раз экономия входных данных и быстрее. Caveman + Ast-index дает огромную экономию.

Субагенты. Мы работаем с разными слоями – фронт, бэк, безопасность, данные. И контекст выталкивается. Делаем субагентов: роль, контекст, правила как делать, запрещения что не делать (не класть файлы не туда), структура папок, как называются файлы, критические файлы зависимостей, – как будто у вас исполнительный, но тупой сотрудник.

Нормальный агентам на запрос «добавь фичу» берет нужную структуру и шаблон, получаем правильные тесты и так далее.

Нейронка вариативна, может галлюцинировать на сжатых контекстах. И надо потребовать «напиши идеально» – это 7-8 волн. Чем больше образцов – тем лучше. Если что-то не предусмотрели, будет системная ошибка. И такие ошибки можно выявить и исправить.

Багфикс. Ты не пишешь сценарий по разбору с истории, хорошему агентом – кинул скрин, а дальше он сам разберет трейсы.

Один агент – одна роль. Это нарушают часто. На котлине можно написать что угодно, нужно ли три агента для бэка, фронта и мобилок? Если там один репозиторий – то можно один. А если три продукта – то точно три агента.

Специализация агентов повышает точность первого входа, почти нет исправлений.

Consilium – совет экспертов. Собирать можно в начале или в других реперных точках: api-designer, architect, devops, secirity и другие обсуждают задачу и дальше получается результат – задание, которое агенты делают индивидуально. Например, есть задача «добавь экран оплат» – собираете консилиум, они обсуждают и делают промпт – крутое ТЗ, план работы. Там будут покрыты кейсы. Один агент может ошибиться, а шесть – они лучше сработают. Аналогично можно обсуждать результаты, делать задание на доработку.

Workflow profiles. Есть разные задачи: багфиксы, новые фичи и так далее, составьте для каждой свой план работ по шагам. Бизнес-фича: исследование – план – выполнение – проверка. Вы можете свой составить. А если баг, сначала его надо воспроизвести, и там есть много деталей. Reproduse – diagnose – fix – validation – report. И вы собираете трейсы и метрики. И потом – консилиум и обсуждение. Таких профилей много – рефакторинг, end2end тесты и так далее… На каждую – делаете свой план. И тогда будет магия.

Execution scope. На каждый агент видит только свои файлы. Иначе они могут начать драться, особенно если консилиум.

Не пихайте профили в глобальный конфиг – это тратит токены при чтении. В конфиге надо там только селектор: под такие задачи выбирай такой профиль.

Модели. Очень часто пихают все в opus. Вершина – fable на промпт “Привет” съели 200$ лимита. Он оркестратор. И без настройки там фигня, драка агентов. Opus нужен для архитектуры и сложных решений, например, security audit, с ним надо разговаривать и штурмить. А большую часть работ выполняет Haiku – самый тупой, гоняет код, пропихивает экраны. Sonnet – пишет код. Opus по факту в 60 раз дороже Haiku. Haiku больше всех работает и меньше всего стоит.

Идея в том, что никакой магии нет. Это рутинный процесс. Но 10 агентов, профили, консилиумы. Проблема в том, что если вся эта конфигурация на личных ноутах команды, то технически это отнимает много времени. Еще все прописывают все в основном файле claude.md ^[23], он прогружается весь и жжет токены. Поэтому там пишем базовый набор и простые правила, что делать с промптом. Дальше – project-файл, там специфика проекта, и профили для разных деятельностей, тоже отдельные, в основном ты описал – он выбрал, если не знает – он тебя спросил.

Как работает? Запрос «добавь оплату» – идет загрузка профиля и проекта, «добавить» – признак, что нужна новая бизнес-фича – подгружаем нужный профиль. И в результате там готовый нужный контекст. Мы экономим токены и контекст – не сжимаем его.

Он собрал все в тулу, в презентации ссылка. Не факт, что вам подойдет, но как скелет точно можно использовать.

Pablo Aguilar. Architecture of an Instant Payment System (by Brazil)

Это – единственное выступление не по теме ИИ, которое я слушал на конференции. Pablo рассказывал, про бразильский аналог СБП (системы быстрых платежей) – архитектуру, производительность, немного истории. Вполне на уровне, от старта разработки до запуска в эксплуатацию – два года, 2019-1020. При этом в Бразилии отличаются стартовые условия: это у нас ЦБ всегда обеспечивал межбанковские платежи, а там расчеты между банками шли напрямую или через SWIFT, и своей карточной платежной системы не было, так что первые разговоры были в 2016 году, а рабочую группу создали в 2018.

У системы два режима проведения платежей: DOC – платеж на следующий день, TED – мгновенно в рабочее время, instant payment (по португальски сокращение pix). Платежи полностью бесплатны для физиков, для компаний есть комиссии – как у нас. Нужен pix key – для передачи денег, есть 4 типа: телефон, taxid, random key и еще что-то.

Сложности платежей – множество банков, валют, счетов, регулируется большим количеством документов.

Технически платежи идут через ЦБ, от банка идет запросом «хочу послать деньги», ответ банка-получателя «готов принять» в ЦБ, и дальше ЦБ передает деньги, около 10 сообщений на платеж. Fraud and ledger в каждом банке, в ЦБ две подсистемы: spi – платежи and dict – справочники. Два канала: для быстрых ответов 40 с и для посылок по расписанию – там 45 минут.

Технически передача по национальной финансовой сети RSFN, в ней банки, и есть два провайдера, которые дают она соединяется в интернет для пользователей. протоколы mutual TLS, message signature – подписываем сообщения xml-signature. Сертификаты обновляются каждый год. Асинхронная коммуникация, не kafka или vpn, а какой-то собственный протокол. В презентации были SLA, они жесткие.

Надежность – через репликацию между датацентрами. Единое мето правды – ЦБ, есть сверка с банками.

Pix – успешен, как софт и продукт. Конкурирует с Visa/Mastercard – проще и дешевле. И со SWIFT тоже.

Андрей Неведин из Райфайзен. Context is a must: как мы системно управляем контекстом

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

Конечно, для начала надо научить агента решать простые типовые задачи от бизнеса, их много, и ребята сейчас именно на этом этапе. Но важно закладывать гибридную команду в архитектуру. Тут уместна аналогия с библиотекой компонентов для интерфейса: есть фреймворки, которые дают богатый набор компонентов, но при этом совершенно закрыты для реализации собственных компонентов с встройкой их в большую форму, и если вам нужна специфика. то всю форму надо собирать вручную. А есть те, где вы можете встроить свой компонент, например, умного ввода больших чисел или номеров счетов, или поиска по конкретным справочникам, и использовать его внутри формы, при этом обычно «из коробки» у них компонентов меньше, зато есть библиотека сторонних компонентов. Разница – в архитектуре, которую закладывали изначально.

Так и тут, если у тебя целевая картина – автономная работа агента, то ты можешь не предусмотреть в архитектуре точечное включение human in the loopс гибкими критериями. Впрочем, судя по выступлению, ребята реализуют именно гибридную команду, хотя целевая картина другая, а до точки ветвления им пока далеко, автомноно выполняется очень мало задач.

А теперь про выступление подробнее. Несмотря на мой скепсис по общему подходу, в выступлении много полезного.

Цель 100% кода пишут агенты, а люди их настраивают. В нашей команде мы туда идем, но не пришли. Возьмем Claude Code. Агент – disrupt индустрии разработки. Когда работает на ноуте, то останавливается, когда закрываешь крышку, а хочется автономно.

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

Claw-решения китайские гиганты обогащают. И их команда делает Raif Claw. Claude agent SDK/Codex/Opencode. У них есть внутренние модели, и есть гейт на внешние модели, где свой контроль запросов, фильтрация и анонимизация.

Vibe team Discovery и Vibe team Delivery – рои агентов для автономного SDLC. Первая – для автономных исследователей и генерации задач, вторая – для реализации.

Vibe Team живет в command center. Paper clip, linear, Claude manager. Они выбрали Multica – open source, его можно форкнуть и докручивать. Управлять: какие скилы у бэкэндера и других, как живут люди и агенты вместе.

Ставит задачу: доработай задачу на потребительский кредит в airline, добавь поле «есть ли субсидия». Агент-тимлид подхватывает, и первое – исследование контекста: где находится потребительский кредит, кто отвечает, где бэк, фронт и мобилки. Он использует это сам для того, чтобы составить спецификацию задачи. На основе спецификации он задает уточняющие вопросы: обязательное поле или нет, куда передается в бизнес-логике и как там учитывается и так далее. На основе ответов – дорабатывает спеку и далее нарезает задачу на агентов-исполнителей. И идет контроль, чтобы задача не грузила контент более, чем на 20% – тогда ее с большой вероятностью сделают за один раз. Если задача слишком большая – пробуют декомпозировать. После бэка работает фронт и мобилки, затем агент-тестировщикпроверяет результат. И когда результат достигнут – человеку идет нотификация на проверку. Так агенты разгребают бэклог.

Agent harness – чтобы обеспечить надежность и предсказуемость результата. Loop Engineering. Придет на смену Harness Engineering. Discover – Plan – Execute – Verify – Iterate. Чтобы работало – нужен Context и Test.

Context annotation platform – цифровой двойник банка: разрез по ответственности по value stream, описание бизнес и софтовой архитектуры в едином графе. Орг.структура, бизнес-контекст, технический контекст. Есть интерфейс для людей, и интерфейс для агентов с семантическим поиском для обогащения задачи. Агенты используют граф знаний для исследования контекста. Векторный поиск через mcp, формат графа – удобен для агента: команда владеет сервисом и так далее – семантика взаимосвязей.

Как поддерживать Context annotation platform? Агенты сами добавляют этот граф. А еще динамически через трейсинг и телеметрию дополняют контекст – есть разметка в коде.

Context memory platform – платформа долговременной памяти ^[24]. Сделана на основе mem0 (на слайде – варианты). Задачи. (1) Персонализация под пользователя – будь прямолинеен или краток. Ты сообщаешь факты – он помнит. И не только про разработчиков, но и для пользователей – кто интересовался какими кредитами и какие каналы предпочитает для коммуникации. (2) Self-improvement – он смотрит трейсинг, реакции человека, чтобы совершенствоваться.

Developer Book MCP – стандарты написания кода в Банке. При этом не все rules нужны для конкретной задачи, надо загружать конкретные гайды с учетом контекста – экономия токенов. Context 7 MCP – дает доку о агентам нужной версии. И они по аналогии сделали: есть гайды, они размечены по категориям, например, по разработке API, и он делает поиск по договоренностям – как делать API, как работать с базой и так далее. И извлекается нужный кусочек.

Контекст – новое золото, пока есть ограничения – надо оптимизировать. И у каждой организации должен быть knowledge-слой. Про контекст поняли год назад, подняли систему и команды год загружали информацию.

Рои агентов сейчас пилотирует 5 бизнесовых команд: платежи, кредиты, данные, они большие, по 100+ разработчиков. И каждая команда имеет свою vibe team и примерно 25% бэклога сделаны командами вместе с агентами, а 4% сделано агентами автономно, без обращения к человеку. При этом есть зоны, которые агентам не доверяют: процессинг, рисковые движки, поэтому если задачи их касаются – то делают вручную. И люди в команде сами проводят исследования и улучшают harness каждый спринт. На слайде были метрики реальной команды.

Вопрос читаемости спецификаций не решали. Спеку, если надо, читаем с помощью агента – он отвечает на вопросы. Базово человек не ревьюит спеку, это будет узкое место. Но избирательно их проверяют, и разбираются при анализе качества работы агентов – почему получилась такая, что надо добавить в harness.

Очень много вкладывают в verify – там много разных агентов с оценками кода, получают evaluation score, интегрированная метрика. Но это – за рамками выступления

Прозрачность работы агентов есть: в командном центре видны все задачи и их состояние.

По расходам. Собирают метрики после каждого прогона – сколько токенов, где вмешивался человек. И пробуют улучшать, определяют причины: переполнил окно и загрузил лишнее, или задача была сложная, или что. Делают ретро и оптимизируют.

За контекст отвечают команды. Но отдельно контекст не тестируем, смотрим результат работы агентов. Если не хватило контекста – команды думают про обогащение. Но при этом между командами синхронизируют понимание терминов, чтобы не было противоречий. Был этап, когда команды описывали по-своему, это прошли.

Никита Круглов из Альфа-банка. Как построить text2sql с нуля и собрать (почти) все шишки

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

Сейчас в сервисе 300 таблиц, количество растет. Используют 4 подразделения, 2000 человек. Хотят перейти на общий каталог от Excel, интеграция с ML для обучения, эксперименты с архитектурой SQL, углубление в аналитику – дата-агент.

Надо проверять, хорошо ли агент вызывает тулы, хорошо ли ищет информацию, хороший ли получается идет SQL-запрос. Нужны примеры простых-средних-сложных запросов. Нужный документ попадает в топ-3 в 80% случаев. Качество генерации – когда результат совпадает с правильным – 80%. Надо проверять описания данных от владельцев. Маленький контекст – хорошо для генерации – они убирают описания ненужных колонок. Пользователи не умеют задавать вопросы – нужен модуль уточнения.

Михаил Кацуба из Ленты. ИИ-код: от нуля до прода

Это был рассказ про конкретный кейс: как сделать приложение, которое бы распознавало и оценивало выкладку овощей и фруктов на витрины. Михаил его делал, сохраняя историю и в презентации ее рассказывал. Кейс, правда, не боевой, а модельный. А до рассказа про кейс была вводная про использование ИИ в обработке данных – профессиональной области МИхаила, и эта теория напрямую с кейсом не связана.

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

Claude Code, Codex, Antigravity. Но использование ограничено – блокировки, обход их несет риски, особенно в корпоративном мире, безопасность – серьезно. Поэтому используем отечественные средства, или разворачиваем свое. И важно уметь работать с разными моделями, быть готовым, что в рабочей среде будет не то, что привычно.

Смотрел отечественные (Yandex, Сбер) и китайские модели. В итоге – Yandex Source Craft. Облачная платформа с ИИ-кодированием, встройка в VS Code, основана на Qwen. Имеет обновляемый пробный доступ, доступен с корпоративными яндекс-сервисами.

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

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

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

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

Пример разработки. Распознавание овощей и фруктов на прилавке – оценка выкладки, а в перспективе – свежесть. Тестировать можно на глаз.

Начало разработки: регистрируем учетку, скачиваем плугин для vscode – и все готово.

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

Дальше – сложнее. Важно не писать промты, а провести исследование. Надо понимать, из каких кубиков строим приложение, не рассыплется ли конструкция. Описываешь задачу, спрашиваешь про способы решения, сравниваешь и обсуждаешь варианты. Начинаем с режима архитектора и используем думающую модель.

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

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

Приложение массивное – он переключился на более простую архитектуру для теста модели. Первый опыт дает хорошее распознавание, но там из коробки всего 5 классов фруктов и овощей, и смесь не определяется. Он начал тестировать разные модели, наиболее удобной оказалсь YOLOe-26x-pf – у нее из коробки результаты лучше. Но все равно она достаточно шумная, ее надо донастраивать: выделять зоны, связывать с планограммами и так далее. И нужно дообучать.

Тестирование. Когда код доверен ИИ, то тесты – основной способ контроля. Их можно генерить с помощью ИИ. Работа тестов – черный ящик. При отладке было, когда картинка передается не на ту модель, или не передают тест на новую модель – переключение не работает. И чтобы работало – ломаем код, если тесты продолжают проходить – а них фейк.

Нейронка хорошо справляется с анализом отклонений в коде и review на merge. Протестировали – загрузку модели проверяли до его загрузки.

Важно грамотно разбивать попроще, и придется разобраться с тестами – везде ли настроены и грамотно ли проверяют функционал.

Розница – хорошее поле: небольшая экономика дает на масштабе большую прибавку к деньгам, и простая регуляторика.

Вопрос: а если код пошел в прод, оно сломалось, а никто в компании не знает, что там под капотом. Ответ. Отлаживать ИИ умеет, указываешь на ошибки – она исправляет, смотришь. Я тут дополню, что это не отличается от ситуации, когда легаси сломалось, а разработчик ушел. А разбираться ИИ помогает, и построить для работающего кода тесты и документацию тоже. Так что это все уже не актуально.

Андрей Давыдков. MWS автоматизация postmorten

Это рассказ про повышение качество кода и снижение количества инцидентов с помощью ИИ. Основной фокус – на автоматизацию postmorten разбора инцидентов, но реально рамка рассказа шире – Андрей рассказал как сложилась ситуация с качеством, и как для ее решения были предприняты организационные меры – был организован ситуационный центр МТС, и сделан процесс, который оставляет цифровые следы. Что и позволило автоматизировать postmorten с помощью ИИ, и далее – выявлять системные ошибки, инициировать работу над ними. А в будущих планах – использовать накопленные в ходе анализа знания еще и при работе над инцидентами для поиска причин и способов устранения.

С какими инцидентами имеют дело? Обычные – остановка отдельной службы или накопление очередей. Критичные – недоступность связи абонентов, отсутствие переводов СБП, недоступность приложения KOIN или оплаты заказов.

Postmorten – разбор инцидентов для предотвращения в будущем. Компания большая, каждый разбирал сам. И были проблемы: формальный анализ, поиск виноватых вместо причин, отсутствие системных решений. Например, бизнес замутил акцию для клиентов, сервис – сломался не выдержав нагрузки. И в разборе указали причину: перегруз CPU и придумали поставить CPU на мониторинг – до реальной причины не дошли. Последствия – повторяющиеся инциденты, влияние на бизнес, отсутствие системных улучшений.

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

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

Они сделали ситуационный центр МТС для координации работы над инцидентами, и приняли план изменений.

• Blameless-подход и SRE-практики

• Mission control center

• Единый инструментарий – RelyOps-платформа: автоматизация разбора инцидентов.

• Дашборд метрик

Оргизменения:

• Команда мониторинга и координации круглосуточно.

• Команда product duty – первая линия, по желанию подключается продуктовым командам

• Команда развития ops-процессов – разбор кейсов с командами и доработка процессов

• Команда BI-аналитики

Формализация процесса на основе SRE-book – адаптировали, описали в confluence, сделали шаблон отчета. Начали проводить демо команд, встроились в онбординг и начали участвовать в разборе инцидентов – чтобы смотреть работу на практике.

После решения инцидента у команды 1-2 дня на разбор и заполнение черновика отчета. Дальше – митинг. Корневые причины, бизнес-импакт, меры предотвращения со сроками. И комитет по пятницам.

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

RelyOps платформа – экономически обоснованный уровень надежности. Архитектурная схема CMDB – Observability (vision scope + бизнес-сценарии, метрики и т.п.) – ITSM – Notification + emergency room.

B это позволило сделать автоматизацию постмортена.

События observability содержат трейсы, логи, метрика и влияние на смежные бизнес-процессы, и дальше он летит в команду, а если инцидент клиентский – то идет интеграция с базой, где идут обращения клиентов. Если критический – аварийная emergency room для обсуждения решений.

Когда инцидент решен – все артефакты упаковываются, команда разбора может еще довнести артефакты, заполнить причины и меры по предотвращению в таск-трекере. И дальше – отчет в конфлюенс.

Лайфхаки.

• Подход пяти почему. Выйти за рамки симптомов. Если сервер лег под нагрузкой – то узнать почему была нагрузка, потому что запустили рекламу без согласования с ИТ, значит надо согласовывать.

• Практика создания мер предотвращения, три типовых причины: (1) если не выявлено мониторингом – доработать для проактивного наблюдения; (2) если долго диагностировали – повышение наблюдаемости и средств диагностики; (3) если ошибка в релизе – повысить охват тестирования.

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

Итого. Разбор критичных инцидентов ускорился с 4 часов до 1 часа. И еще ряд метрик – изменения есть в презентации.

В этом году вывели на прод Co-pilot. Зачем? Потому что смотрят на 5% инцидентов, а 95% в серой зоне, их команды разбирают внутри с неясным качеством. Но posmorten критичных инцидентов – дорогой, там 15 квалифицированных инженеров, все так разбирать дорого. Цель – создавать отчет за счет copilot, масштабировать на все инциденты, и увеличить базу для разборов.

Три сервиса: (1) поиск похожих инцидентов по ключевым атрибутам, (2) проверка точек мониторинга – выявлен ли сбой проактивно, (3) PromptBuilder + LLM – получает предыдущее и выдает основную причину, альтернативы, и предложения по устранению. Дальше инженер принимает или дорабатывает.

Для поиска похожих – Minhash+LSH – оценка похожести объектов и выдача кандидатов. Провели R&D по пороговому значению, нащупали порог сходства 0.7, 0.4 – много шума и потеря полезных совпадений, 0.9 – уменьшает число схожих и тоже увеличивает шум.

PromptBuilder + LLM. Поиск похожих – задает, дальше оптимальный промпт, и дальше выбор модели из локально развернутых – там 10+ моделей.

Берут из ретроспективных данных инцидент, делают внутренний генератор для черновика, дальше выделяем атрибуты, заполненные человеком, дальше судья сравнивает то, что породил генератор с тем, что сделал человек. Проводят бенчмарк моделей, оценивают по 4 бальной шкале. 0 – полностью не соответствует, 3 – полностью эквивалентно. Оптимально генератор Qwen-3, а судья – Codify.

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

Как несут культуру? Когда начали внедрять, многие восприняли как бюрократию. Но когда с командами прошли путь – они поняли, что история приносит пользу. И они слышат обратную связь от команд – где они перегибают палку, где можно автоматизировать.

Второй этап – все эти подсказки postmorten вывести еще на этап разбора инцидента, сейчас делают пилоты.