2026-07-02: Saint Highload-2026: как крупный ИТ осваивает ИИ

Короткая ссылка: Highload-2026-Spb

Ссылки сюда (3) →

О других конференциях

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

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

Отчет опубликован на habr, через некоторое время перенесу на сайт, а пока читайте там.

Пост на моем канале Пост на канале конференции Пост в чате конференции

---

Переношу на свой сайт

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

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

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

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

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

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

1. Spec Driven Development – это попытка инженеров построить водопад. Хотя бы на ИИ-агентах, если уж на людях не получилось. Не потому, что родился Agile, причина обратная: Agile родился именно потому, что классический подход (водопад, RUP и так далее) – не сработал. И SDD не сработает по тем же системным причинам, так что картинка, которую вы видите в посте по-прежнему актуальна.
2. Внедрение ИИ-агентов (а не ИИ-помощников) не совместимо с привычными способами работы. Даже в варианте SDD. Чтобы внедрить не формально, а получить реальный эффект, надо существенно перестраивать процессы.
3. Что такое «привычный способ работы» – вопрос отдельный. О них был роскошное выступление Даниила Подольского, где он назвал этот метод «колхозный скрам» и очень едко описал. Это когда разработчики делают непонятно что, потому что бизнес описал это невнятно, бесконечно это переделывают и правят ошибки. И да, показал, что ему точно придет конец. Замечу, что этот метод от скрама получил только лейбл в то время, когда скрам стал модным. А исторически сложился он задолго до, и в 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% задач без агентов.

Я этот оптимизм не разделяю, это опыт ИТ показывает: несмотря на богатые возможности генерации сайтов, дизайнеры и разработчики сайтов остаются, а описание бизнес-процессов не позволяет покрыть их полностью, так как процессы содержат множество точек с особыми ситуациями, разруливание которых не описывается языком процессов. Аналогично и здесь, агенты смогут взять значительную часть разработки, но не все. Возможно, соотношение будет описываться правилом Парето 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 должна была сэкономить, а где?

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

1. Где бюджеты?
   • Стартапы. Ускорилось, за 2 недели можно сделать то, что выпустили или даже анонсировали конкуренты, если это мониторить. У корпоратов – не так, там большой цикл согласования.
   • Сотрудников – не меньше, и добавились подписки.
   • Бизнес стал быстрее работать. Но не факт, что больше зарабатывать. Я замечу, что это вопрос к бизнесу: если у него норма прибыли сохранилась, то стал зарабатывать больше. Или он мог уронить цены, чтобы заработать на обороте.
     

1. • Была задача начала года: сократить штат на 20-30%, не потерять в качестве и еще ускориться. Прошло полгода. Не видит ускорения и оптимизации.
   • А другие – видят. В операционке люди начали решать задачи быстрее – в 3 раза отдел комплайнс, им хорошо заходит агентская аналитика. Цифры очень разуют, не ожидали. Сокращение – не планируется, просто работы делают больше. SDLC – пытаются внедрить, но пока не внедрили, вопрос второго полугодия. QA нравится автотесты генерить, а разрабы – осторожно, ревью – сложнее.
   • Чем ближе к физику, тем хуже в реальных кейсах это работает. Много крупных компаний «давайте совершать финансовые транзакции с помощью ИИ». Регуляторнка и риски относятся негативно: как докажете? Возражения «люди тоже не ошибаются» – не принимается. Закона от регуляторов нет, но есть куча рекомендаций разных служб – и они приходят с проверками. И закон тоже.
   • Агенты имеют ограниченное окно контекста. У людей тоже ограниченное, но лучше. На ChatGPT поддержку не построить. Но Human in the loop работает. Замечу, что на AIconf было выступление Яндекса о том, как на смеси людей и агентов собирать поддержку для бизнеса. Много уровней, каждого агента отдельно настраивают и мониторят качество. И все работает, агенты дают реальные деньги компенсации при проблемах, и не более щедро, чем люди.
   • Стартап. Агенты, которые парсят конкурентов – блог, github и так далее. И это дает офигенное ускорение по придумыванию новых фич. А разработка – на людях, которые действуют с ко-пилотами. Написание кода ускорилось в 1.5-2 раза.
   • Угорели больше всего как раз на кодинге – потому что запускали на ночь и агенты жрали все тикеты. Так не надо.
   • Много успехов в операционке, генерации контента – персонализировнные предложения с картинками и видео, дизайнеры.
   • У банков есть разграничение по персональным данным – их не выложишь в отрытые модели.
2. Все будет по-другому.
   • 5-10% команд, где все хорошо, 60% – немного Qwen и так далее. И остальные – ИИ-диссиденты, бред. У всех performance review. Как будете делать performance?
   • Пока performance – по-старому. И если ты за счет ИИ делаешь в 2-3 раза больше – у тебя все хорошо.
   • Дмитрий. Тех.директор стал генеральным. И финдир спрашивает: у вас ИИ – расходы или инвестиции?
   • Есть льготная подписка opus, которая по полной цене 6к долларов – вопрос когда придет. Поэтому был эксперимент – выдать современные макбуки и на них локальные модели – так тоже работает.
   • Нужно изменение mindset!
   • Процессы – они же мешают. Мы знаем, как было раньше, умеем прогнозировать (пообещаешь месяц – накинем два). Люди привыкли. А как в новой парадигме сделать процесс прозрачным и прогнозируемым – непонятно. На мой взгляд, вполне понятно – через метрики: если процесс по-прежнему пережевывает задачи или проверяет гипотезы, то метрики не меняются, если у него другой предмет – надо придумывать, но все равно понятно. С прогнозом может быть хуже, но он и раньщше был плохой, если исполнители специально не докручивали.
   • Технология – новая. Но мы почему-то обязательно пытаемся выстроить фреймворк, при этом внешний и готовый. Возможно, основная проблема с бюджетами в том, что не пробуют что-то делать, а пытаются фреймворк сделать. Кейс. Надо было сделать рефакторинг, выдали подписки по 200 баксов, придумали миллиард скиллов и так далее – сделали что угодно, только не код переписывали. Делаем скилл, вместо того, чтобы отрефакторить.
   • Вопрос: не проще ли подождать, а другие пусть ломают дрова. А мы будем пока по классике? Я замечу, что, может, и проще, но есть риск, что конкуренты съедят твой кусок рынка, банки помнят пример Тинькова. При этом статистически больше выигрывает удачливый последователь, следуя по следам первопроходца, но не совершая его ошибок. Впрочем, вырвавшись вперед второй становится первопроходцем, роли меняются, а путь – из многих этапов.
   • Очень важно держать фокус на продукте. Но люди вместо это развивают инфраструктуру. Запретить инженерам оверинжиниирить. Не строить космолет, когда нужна тележка.
3. Как защищать стратегию на год, когда все быстро меняется?
   • Убер и 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, чтобы проверять вероятностное поведение. А если мы используем ИИ-агентов в разработке, то для них тоже нужны 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-портала.

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

Результаты в разных командах отличается в разы. И хорошо работает там, где люди готовы менять процесс разработки. Часто стимул – жесткие сроки. Платформа их помогает, чем является необходимым условиям – дает инфраструктуру. А не получается – у тех, кто поставил плугин в 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. Лимиты на токены/задачу, тайм-лимит.
• Мультиагентная координация – чтобы не было гонок и переписывание. Не всегда они нужны, в один поток может быть лучше, потому nxj проще.
• Моделенезависимый harness – чтобы менять провайдера, и было не страшно. Антропик может взвинтить цены в произвольный момент итак далее. И сейчас китайцев для многих задач достаточно-. антропик не нужен.
• AI-gateway: LLM-прокси. Там есть нюансы с подписками. Их много, можешь использовать общие токены, а каждому выдавать.
• Кодовый агент с выходом на L3. Многие агенты встроены в IDE, их нельзя запустить автономно – а это блокирует L3. Есть агенты, где IDE и SDK разные и несовместимые. Agents SDK, Codex sdk, pi.dev, 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 был расширен и адаптирован под это. Хотя, это действительно была адаптация, и реально надо выходить за его пределы.

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

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

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

А думать не хочется, поэтому 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 такие странные, зачем они такие подробные и так далее. Люди читать не будут. Что можно с этим сделать? Можно взять архитектора и посадить клепать хорошие задачи из однословных задач, сделанных аналитиком. Но! Архитектор работать над такими спеками не захочет. Вместо этого – нужна архитектура и хорошая постановка: что надо сделать без как надо сделать.

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

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

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

У нейросети слишком гладкий слог, поэтому человеку скучно. ИИ так не умеет. Отм