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

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

Почему утроение разработки не утраивает эффективность бизнеса

Представим, что компания проверяет 100 гипотез в квартал. Предположим, что 20 из них подтверждаются и заметно двигают бизнес‑метрики. После внедрения в процесс разработки AI‑агентов, стоимость ее реализации снижается, а цикл от намерения до работающей фичи сокращается. Допустим, теперь компания, с теми же ресурсами, может проверять уже не 100, а 300 гипотез в квартал.

На первый взгляд, бизнес должен радоваться, ведь производительность выросла втрое. Но Discovery, качество данных, экспериментальная инфраструктура и управленческое внимание не выросли втрое. Первые 100 гипотез могут сохранить прежнюю конверсию в 20%, а следующие двести — дать, например, по 5%. Получится 30 успешных гипотез вместо 20. Производственный output вырос втрое, а количество положительных результатов — только на 50%. Расчёт иллюстративный, но вопрос финансового директора по итогам года вполне реален:

«Мы утроили производительность. Почему бизнес‑результат не утроился?»

Ответ на него — не в разработке.

Сняв ограничение в Delivery, узкое место по Теории ограничений не исчезает, а переезжает. Организация обнаруживает следующие ограничения: достаточно ли у неё сильных гипотез, достоверных доказательств, качественных экспериментов, управленческого внимания и способности довести выпущенное изменение до принятия клиентом и роста бизнес‑результата? Именно с этой точки я предлагаю посмотреть на whitepaper Сбера AI‑Disrupt PDLC.

Если кто ещё не знаком с ним, настоятельно рекомендую ознакомиться, потому что далее я буду опираться на изложенную в нем архитектуру, структуру и терминологию: вот исходные документы, обновлённые в июне, — короткая версия  и длинная, за авторством Кирилла Меньшова, старшего вице‑президента и главы блока «Технологии» Сбера. На Хабре уже есть разбор для тех, кто пишет код, поэтому я не буду подробно пересказывать содержание документа, но затрону несколько ключевых для данной статьи идей.

Одна из самых дорогих встреч в нашем календаре выглядела совершенно обычно. Раз в неделю 20-25 человек собирались на 1,5 часа, чтобы оценить задачи. Раз за разом встреча повторялась, забирая время разработчиков и техлидов, а результат строился на уже известной команде информации: описаниях задач, истории похожих работ и прошлых оценках.

Мы отдали эту работу агенту, которого назвали Эстима. Через 1,5 месяца пилота сходимость его оценки с ручной достигла 95%. После этого встречу отменили, валидацию оставили техлидам и получили экономию около 20 человеко-дней в месяц.

Именно Эстима помогла команде поверить в практическую ценность AI. За ней появились агенты для работы с Jira, ревью кода, разработки, тестирования, аналитики и AppSec. Вместе они постепенно изменили наш PDLC.

Привет, Хабр! Меня зовут Михаил Чернов, я старший IT-лидер направления развития IT взыскания в Альфа-Банке. В этой статье расскажу о нашем опыте перестройки производственного процесса на AI-рельсы, включая пилоты, ограничения и вопросы, на которые мы пока ищем ответы.

Привет, я Тимур Напреев, основатель клуба рецензентов ИТ-литературы Read IT Club. В этой статье хочу рассказать, почему технической книге нужен рецензент с практическим опытом, как устроен Read IT Club и что получает специалист, который помогает книге выйти с меньшим числом досадных ошибок.

Простой пример –  книга о работе с данными. Автор предлагает найти слово «мышь» (mouse) в базе данных, где хранятся персонажи Disney. По замыслу система должна вернуть запись «Микки Маус» (Mickey Mouse), потому что она содержит это слово. На английском пример работает. В русском переводе связь ломается, потому что в «Микки Маусе» нет слова «мышь» и обещанного результата читатель не получит.

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

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

Привет, Хабр! Я Денис Макрушин, работаю в Яндексе, и вместе с командой SourceCraft Security строю платформу для безопасной агентской разработки, а в свободное время ищу уязвимости в ИИ‑агентах и иногда рассказываю об исследованиях в своем блоге. Чем дольше этим занимаюсь, тем лучше вижу тенденцию: индустрия обсуждает, что агенты умеют делать, но реже говорит о том, какие решения и как проще внедрять, чтобы сделать агентскую инфраструктуру безопаснее. Вместе с моими коллегами Ратмиром Самархановым и Андреем Погирейчиком мы решили проверить гипотезу: «наши ИИ‑агенты в разработке могут быть скомпрометированы и существуют простые средства для контроля их безопасности». Расскажем о первых результатах.

Привет, Хабр!

17 сентября 2026 года в Москве и онлайн пройдет AI R&D DAY. Это конференция для исследователей, ML‑инженеров, AI‑архитекторов, руководителей R&D‑команд и специалистов, которые превращают экспериментальные разработки в работающие продукты.

Один из фокусов конференции — NextGenAI, проект команды R&D SberAI, посвященный технологиям следующего поколения. Команда поделится результатами исследований, расскажет о развиваемых продуктах и представит технологические направления, над которыми работает сейчас.

В программе 22 доклада на двух сценах, панельная дискуссия, постерная сессия и выставка. Участие бесплатное.

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

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

Меня зовут Татьяна Костенкова. Я предприниматель, ментор руководителей и ex-CEO IT- и маркетинговой компании. Эта статья о том, как видеть политические процессы в компании и уменьшать ущерб для себя и команды. Я не предлагаю превращать офис в «Карточный домик». Моя цель проще и практичнее: дать тимлиду понимание и приемы, которые помогут не быть съеденным первым.

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

В этой статье по мотивам доклада для Saint TeamLead Conf психолог, психотерапевт Анна Бабич даст четыре простые  научно доказанные инструмента — их хватит их на всю жизнь, чтобы поддерживать свою психику в прекрасном состоянии. Автор предложит алгоритм, как внедрить практики в свою жизнь на постоянной основе и мы обязательно потренируемся физически управлять своим вниманием и вернем себе контроль над этим процессом, вызывающим много вопросов (СДВГ, привет!).

Эта статья — конкретный ответ на вопрос, что делать. Передаем слово автору.

В мае я анализировал whitepaper Сбера «AI-Disrupt PDLC», представленный на ЦИПР-2026. В том разборе я отметил, что документ обладает сильной инженерной составляющей, но недостаточно подкреплён конкретными данными.

В июне вышла версия 2.0, которую в начале июля представили на «Иннопроме». Название изменилось с «Стратегия AI-трансформации бизнеса: от кода к намерению» на «ИИ-нативная трансформация разработки ПО для зрелого корпоративного контура. Практическое руководство». Переименование точно передаёт суть обновлённого содержания.

В первой части мы остановились на том, что Продуктовая аллея DevOpsConf 2026 показала рынок как поиск более зрелых эксплуатационных моделей. AppSec, observability и AIOps важны, потому что заставляют команды ответить на важные вопросы: где остаётся ответственность, кто владеет дефектом, с какого SLO начинается мониторинг и какие решения нельзя отдавать автоматизации без контроля.

Во второй части мы поищем ответы на вопросы кто и на какой платформе будет сопровождать production через Kubernetes, инфраструктурные платформы, DevOps as a Service, облака, data-платформы и инструменты разработчика. Команды пытаются снять рутину эксплуатации, собрать внутренние платформы, автоматизировать инфраструктуру через API и Terraform, а заодно встроить AI и data-инструменты в SDLC так, чтобы они помогали разработчику, но не получали бесконтрольный доступ к критичным средам.

Привет! Я Саша Рыжов, MLOps-инженер в hh.ru, уже три года занимаюсь развитием инфраструктуры для искусственного интеллекта. Компании, которые развивают GenAI, рано или поздно приходят к задачам по запуску LLM на собственном железе. В статье я расскажу, как обстоят дела с движками инференса в 2026 году и как запустить on‑prem-прод и не изобрести при этом велосипед.

Привет, меня зовут Филипп Бочаров, CPO в МТС Web Services и член программного комитета HighLoad++. 8 лет я занимаюсь наблюдаемостью (observability) продуктов - внедряю, обучаю, выступаю и менторю. В этом году мы с командой придумали воркшоп "Смотри, как думает агент: Observability AI-агентов с Langfuse", подготовили его всего за 2 месяца и успешно провели на AIConf 2026 и Saint HighLoad++ 2026.

Наш воркшоп прошли уже 60+ человек, которые оценили его содержание на 4.62 из 5 баллов и дали положительный фидбек. Но когда мы начали его готовить, оказалось, что воркшоп требует совершенно другого подхода, чем обычный доклад. Некоторые проблемы мы вообще не могли предсказать. 

В этой статье я поделюсь нашей историей, ошибками и выводами о том, как готовить интерактивные форматы: воркшоп и мастер-класс. Ведь московский HighLoad++ 2026 уже не за горами и открыт для заявок!

Сразу после Saint HighLoad++ прошла Saint TeamLead, основной темой тоже было применение ИИ. Второй день принес прекрасное визионерское выступление Авенира Воронова, два тезиса.

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

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

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

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

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

В подборке есть продукты разной зрелости и разного масштаба: от open source runtime-security до managed Kubernetes, от AIOps-корреляции алертов до Git-платформы с AI-ассистентом. Смотреть на них лучше как на карту болей, вокруг которых сейчас собирается российский DevOps/DevSecOps-стек.

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

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

Несколько месяцев назад в публичном пространстве появилась история, которую в engineering-сообществе стали называть поучительной. Команда AWS использовала внутренний AI-инструмент Kira для ускорения работы. Kira предложила джуниорам сценарий: переразверни продакшн-слой. Инженеры согласились. Следующие шесть часов весь AWS не работал. После разбора полётов компания объявила новое правило: финальный апрув на изменения, предложенные агентом, должен давать сениор-инженер.

На первый взгляд, решение логичное. На второй, уже менее. Если агент генерирует изменения в темпе, к которому люди не привыкли, один сениор превращается в бутылочное горлышко для бесконечного потока PR. Это не решение проблемы. Это антипаттерн, оформленный как процесс.

История AWS точно формулирует главный вызов 2025-2026 годов: AI научился быстро писать код, но индустрия пока не научилась с такой же скоростью его доставлять, проверять и принимать решения о нём. Данные, собранные в рамках масштабного исследования State of AI4SDLC, это подтверждают.

У разработчиков есть крепкое убеждение: стать тимлидом значит навсегда потеряться в созвонах, потерять хард-скилы и оказаться в ловушке из которой не выбраться. В конце 2024 года на Хабре набрала больше 200 плюсов статья с говорящим названием «Не надо быть тимлидом». Она начала просачиваться в чатики, каналы и умы людей. И закрепила страх: тимлидство карьерный тупик.

Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure и автор телеграм-канала «Тимлид Очевидность», с этим категорически не согласен. 18 лет в IT, последние 10 в менеджменте, плюс 5 лет консалтинга с десятками тимлидов в клиентах. Достаточно, чтобы смотреть на карьерные страхи без паники. Доклад на Saint TeamLead Conf 2025 в Петербурге он посвятил разбору этого популярного тезиса.

Спойлер: тимлид это не тупик. Это развилка.

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

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

Эта статья про то, как измерять. Точнее, про то, как тестировать и мониторить адаптивные LLM-системы в продакшене и до него, чтобы убедиться: ассистент ведёт себя так, как задумано.

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

Эта статья написана по мотивам моего выступления на DevOpsConf 2026. Поговорим о Time-to-Market: как разложить его на части, найти узкое место и подобрать под это узкое место инженерную практику, которая действительно сдвинет метрику. Сразу предупрежу, что универсального рецепта на все случаи здесь не появится. Это и есть главная мысль всего материала.