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

О четвёртой промышленной революции говорили так долго, что к разговорам успели привыкнуть. А она тем временем уже разворачивается прямо в редакторах кода. Все прошлые промышленные революции ускоряли физический труд. Эта впервые взялась за труд когнитивный: за проектирование, написание кода, ревью, отладку, за всё, чем инженер занят каждый день. Куда это приведёт, честно не знает пока никто. Понятно при этом одно: разбираться придётся всем, и разбираться всерьёз. Под этот сдвиг команда Saint HighLoad++ пересобрала всю программу. И вместе с этим появилась новая логика, по которой всё устроено.

Привет, Хабр! Я Александр Блинов — технический руководитель B2C-направления в hh.ru (та самая часть, которую знают все соискатели). В статье расскажу о том, как мы работаем с метриками, поделюсь своим подходом к ним и приведу пример нескольких незаурядных метрик, которые вы сможете использовать в своих проектах.

Вопрос «внедрять AI в разработку или нет» закрыт. Сегодня индустрию занимает другое: успеет ли ваша команда перестроить процессы под AI быстрее, чем рынок переформатирует доли. Мы собрали мнения пяти членов программного комитета Saint HighLoad++ 2026 о том, на каком уровне зрелости находится индустрия, где хайп обманывает на цифрах, что должно быть готово до внедрения и почему конференция сменила формат. Если коротко: рабочих практик пока мало у всех, и ценнее всего оказывается чужой реальный опыт, включая отрицательный.

Волна сокращений в IT — реальность, а не угроза. С конца 2024 года к консультантам «большой четвёрки» всё чаще приходят не технические директора, а CEO и CFO с одним запросом: «Айтишников стало слишком много — что-то надо сделать». Для CTO ключевой путь — создание профессиональных команд, усиленных ИИ-инструментами, где CTO становится инициатором изменений, а не их объектом.

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

Это короткая аннотация для статьи. Заполни меня позже. Аннотация не может быть меньше 100 символов, по этому я пишу и пишу больше текста.

На ЦИПР-2026 в Нижнем Новгороде, 19 мая, Сбер выкатил whitepaper с амбициозным названием — «AI-Disrupt PDLC. Стратегия AI-трансформации бизнеса: от кода к намерению». Автор — Кирилл Меньшов, СВП и глава блока «Технологии». В тот же день там же подписали меморандум о партнёрстве с red_mad_robot. То есть это был не «выложили на сайт», а вполне заготовленный релиз с витриной.

Открытых версий две. Короткая — PDF на 28 страниц, обзорная. Длинная — .docx на 337 тысяч знаков, в пять раз толще, и местами это совсем другой документ: там лежит почти всё интересное. Я прочитал обе целиком, плюс лендинг (на нём, кстати, есть пара формулировок, которых нет в PDF), плюс смежные публикации Сбера, Яндекса, Т-Технологий и red_mad_robot к этому же релизу.

Ниже — пересказ того, что в документе важно для инженера. Без пересказа цитатами и без рекламы. Где это пересказ — там пересказ. Где это моё мнение — написано «от себя».

Типичная ситуация: вы находите проблему в компании. Понимаете, как её решить. Пишете документ, готовите презентацию, объясняете идею руководителю. Все соглашаются: «Да, звучит разумно». И… ничего не происходит.

Документ лежит в wiki. Архитектура остаётся прежней. Процесс не меняется.

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

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

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

Но со временем стало очевидно: дело почти никогда не в самой идее. Дело в том, как она проживается людьми вокруг — и какую историю про неё в итоге начинают принимать.

Всем привет! Меня зовут Вадим, я — Data Scientist в компании Raft. Эта статья написана по мотивам моего выступления на конференции AiConf 2025. В ней мы разберём, какими метриками измеряется машинное разучивание и какие основные методы позволяют добиться контролируемого «забывания» без полного переобучения модели. Погрузимся в методы, метрики и бенчмарки, связанные с машинным разучиванием.

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

На «Ура, мы запустили процесс!» работа не заканчивается. Здесь как с деревьями: мало посадить, важно присматривать и ухаживать, иначе процесс зачахнет и не даст ожидаемых плодов. В этой статье по мотивам выступления с TeamLeadConf Александр Бондаренко из Garage Eight поделится своим опытом, как сделать так, чтобы процессы жили и приносили результаты. Передаём ему слово.

Как обучить ML-модели на Edge-устройствах с памятью <256 МБ? Привет, Хабр! Я — Александр Лошкарев, инженер-программист, и это вторая часть материала о федеративном обучении. В первой мы рассматривали, зачем в принципе понадобилось добавлять устройствам интеллект, о преимуществах FL, архитектурных подходах и вызовах.

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

Привет, Хабр! Меня зовут Владислав Шаргин, я — руководитель практики подбора в компании ecom.tech. В этой статье по мотивам доклада для Saint TeamLead Conf я расскажу, как за минимальное количество действий сделать так, чтобы ваш сотрудник был доволен, почему деньги — это не мотиватор, и как правильно задавать вопросы про эффективность. 

Представьте типичный разговор на ретроспективе: команда обсуждает, стоит ли переходить с Ansible на Terraform, нужен ли Backstage или хватит самописного портала, пора ли внедрять Chaos Engineering или это ещё «не для нас». Каждый приводит аргументы, ссылается на прочитанные статьи, и в итоге решение принимается по принципу «кто громче убедил». Знакомо?

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

Если ваше устройство думает, что 1 ГБ — это ругательное слово, то этот доклад в двух частях для вас.

Меня зовут Александр Лошкарев, я инженер-программист в компании Eltex. Этот материал основан на моем докладе для AiConf и посвящен федеративному обучению (FL). Мы разберем, как внедрять ML-модели на краевых устройствах, которые жестко ограничены в ресурсах и имеют меньше 256 МБ оперативной памяти. 

Описание модели памяти Go начинается со слов «если вы читаете этот документ — вы излишне умный, остановитесь». Многие и правда остановились, но не автор этой статьи. 

Привет, Хабр! Я — Игорь Панасюк, и это вторая часть материала по мотивам моего выступления на GolangConf, где я рассказывал о модели памяти Go. В первой мы разобрались с  отношением happens before, формализмом, посмотрели практические примеры и многое другое. Сегодня поговорим о линеаризуемости исполнения, барьерах памяти (можно ли опустить абстракцию модели памяти), гарантии для программ с data race и использовании продвинутых техник.