TechLead Stream | Иван Поддубный

Несмотря на то что я уже лет 20 живу в Ростове-на-Дону, корнями я из Урала и Сибири. Отец военный и, родившись на Урале, я успел пожить в нескольких сибирских городах) Но в душе я сибиряк и до сих пор говорю что "у нас в сибири", хотя по логике уже должен был давно перестать) Радостно что в Сибири тоже проходят движуха, и в этот раз я немного помог ближайшему TeamLead Сибирь, проходящему в Новосибирске с подготовкой нескольких докладов в AI треке) Кажется будет прям неплохо, если собираетесь посетить забирайте промокод от члена ПК: PODDUBNY https://teamleadconf.ru/siberia/2026 P.S. Фирменный стиль конфы с мишками у них огонь)

Немного про измерение эффективности от внедрения AI в SDLC Количество часов разговоров с коллегами в отрасли на эту тему за последний год я бы мог исчислить десятками) Например пол года назад тут с коллегами из Т-Банк, Яндекс и WB (FunSun) или пару недель назад в круглом столе про ФОТ. Или под новый год на митапе smallTech. Также много разговоров с коллегами в кулуарах Saint Haighload++, TeamLeadConf, Sber Arch.Meethup и еще многих других. Кстати так сложилось что практически не обсуждали на Agentic Dev Conf, там как будто бы у людей другой вайб, сильно больше тех кто уже обосновал для бизнеса эффективность. Я бы разделил следующие фазы этого дискуссии. # ФАЗА 1: А ТОЧНО ЛИ УСКОРЯЕТСЯ САМ ПРОЦЕСС РАЗРАБОТКИ? ## Лагерь сомневающихся в ускорении В многом коллеги ссылаются на какие нибудь среднерыночные исследования, но берут конечно те, которые подчеркивают их картину мира, игнорируя отчеты и кейсы других компаний. Здесь мне кажется стоит разбирать кейсы, практический опыт и результаты конкретных компаний и потенциал воспроизводимости тх опыта. Это точно полезнее средних опросов по больнице. Второй их основной довод: у нас в компании сеньеры тратят 10% на код, а львиная часть на решение блокеров и других вопросов. И правильное следствие (которое происходит не у всех) - анализировать узкие места и решать, то что 10% пишется код порой может быть следствием неэффективности построения команд или межкомандного взаиможействия, процессов внутри. На мой взгляд в таких случаях правильный вопрос: а стоит ли параллелить решение вопросов. Иногда можно на AI рельсах пересобрать новомодные tiny team это как раз способ и перезагрузить проржавевшие старые процессы. А с AI флагом сейчас можно как раньше с agile флагом ломать многие преграды внутри корпоративных укладов. Третий довод: что упираемся в когнитивные возможности человека на валидацию (многие об в т.ч. Никита в канале SE Materials подсвечивает риск). Я бы тут прокомментировал что большую часть когнитивных возможностей должен решать harness. Предел конечно же есть, однако на мой взгляд этот предел точно х2-х3 выше чем работа в старых парадигмах. Запуская harness в 2-3 потока с высоким уровнем автономности (работа часами с самопроверкой до результата), ты можешь поочередно решить 2-3 задачи тогда когда решал за это время условно 0.5. Но тема большая в т.ч. если раскрывать мультипоточность работы разработчика в новых реалиях. ## Лагерь адоптеров Можно поделить на тех кто нашел способ доказать ускорение на пилотах в определенных командах. Я видел разные пилоты в корпорациях за последние пол года 1. Внедрение в greenfield проект. Берут greenfield проект, оцениваются конвенциональными способами разработки в год (верифицируют оценку другими старыми командами). И потом эффективно делают его за пару месяцев. Примеров видел много, вот публичный кейс x5, доклады Александра Поломодова (Тбанк) в т.ч. на последнем Highload++ рассказывает об успехе таких команд, много данных в кулуарах конференций. Да и в целом кажется про успехи в greenfield не рассказывал только ленивый. 2. Внедрение в brownField проекты Это уже интереснее т.к. было много споров что вот на старых то проектах внедрить нельзя. Но пилоты многих показали что и тут можно добиваться значимых результатов. На Agentic Dev Conf и грядущем TeamLead Conf Siberia коллеги из райфа показывают такие пилоты и их успех в разных не связанных вертикалях. Есть и много других проектов, и в т.ч. мы в в Вебпрактик видим ускорение в т.ч. в brownfield проектах, если правильно работать с контекстом и правильно затачивать под это harness. Причем как про микросервисную (могу говорить про десятки/сотни) так про монолитную brownfield архитектурой. Т.е. в лагере адоптеров есть много кейсов когда они доказали эффективность бизнесу через прирост производительности разработка в конкретных метриках. И есть конечно и просто те, кто видят эффективность и не меряют, просто принимая это как новый уклад. Считая что назад дороги уже давно нет, и можно двигаться только вперед. # ФАЗА 2: ТРАССИРОВКА ЭФФЕКТОВ ОТ УСКОРЕНИЯ НА БИЗНЕС Когда обе стороны принимают факт что разработка ускорилась, или сторона сомневающихся условно принимает довод что разработка ускорилась. И один из ключевых вопросов который задают: а точно ли ускорение разработки дает эффект в бизнесе. Измеримый сквозной throuthput. В идеале в финансах. И тут ловушка в которую попадает этот вопрос: что даже в мире без ai в большинстве команд не могут однозначно сказать на сколько те или иные гипотезы беклога определенного продукта повлияли на сквозную пользу для бизнеса который выразился в финансовом результате. Могут быть какие нибудь промежуточные метрики, но на сколько они точно влияют на конечный бизнес результат сложно. Да, есть кейсы когда это можно трассировать прозрачно как ускорение переработки беклога дает прозрачный бизнес результат. Но померить влияние на финансы какой нибудь команды в микросервисной архитектуре порой весьма непростая задача) И тогда 2 сценария а) У вас есть возможность доказать бизнесу что беклог действительно конвертируется в ценность и ускорение переработки беклога = польза. б) У вас идут сценарии доказания через сохранение скорости беклога, но сокращение ресурсов. === В целом в правильном споре стоит разделять уровени, и спорить на каждой конкретно: разработчик / команда / поток доставки / бизнес Часто в спорах идет перепрыгивания с уровня на уровень, причем не осознанное. На мой взгляд эффективность разработки доказана давно. Лето 2026 славится тем что уже к этому моменту за весну многие корпорации откатали свои пилоты и пришли с публичными результатами о которых могут заявлять. Сейчас все начинают думать как масштабировать этот опыт и решать те боли с которыми столкнулись в процессе. Нельзя не уважить лагерь тех кто говорит подходить аккуратнее и утверждают что можно получить ускорение больше классическими методами поиска узких мест без AI, особенно если у вас накопился большой ворох проблем и те самые 10% написания кода происходяи в результате огромного количества блокеров. Но имхо эти процессы нужно параллелить. Чтобы к тому моменту когда вы разошьете старые проблемы, не оказалось что вы с самом начале перевода производства на новые рельсы.

На Пыхнике будет выступать наш PHP тимлид Денис, поделится опытом ai трансформации команды и процессов, шишках с которыми столкнулись в его команде на этом пути. Сам Пыхник кстати гибридный, часть онлайн, часть оффлайн. Основная часть в оффлайне. Вообще и другие классные доклады про AI трансформации будут. Например Саша Макаров еще сделает вечером сессию обсуждения как старые классические парадигмы программирования вроде DDD или АОП по другому заиграли в ai-native разработке. Мне такое прям очень откликается. Многие архитектурные парадигмы могут быть переосмыслены в современном мире. Подробнее тут https://t.me/phpyhconf/209

https://github.com/obra/superpowers/releases/tag/v5.0.6 Значимое событие в области харнеса отыгрывает за лагерь сокращения старых обвесов мультиагентности. Автор superpowers выпилил мультиагентное ревью, со словами что чеклист самопроверки справляет лучше и быстрее. # Масленников разобрал лагери обвесов харенса https://habr.com/ru/articles/1058676/ Причем мои наблюдения подтверждают что "минималисты" которых он выделил зачастую приверженцы SDD. Я у многих приверженцев готовых SDD фреймворков, на которых они строят слой харнеса поверх базовой шины контекста узнавал что они не упарываются в мультиагентность. # Мой взгляд на мультиагентность: 1. Многие сабагенты которые мы делали в 2025ом - стали не нужны. Часто мы их делали т.к. не влезали в контекстное окно, да и в эпоху когда скилов не было. Бездумное следование старым привычкам - зло. 2. Мои наблюдения (eval еще не выкатили чтобы сказать замеры), показывают достаточно неплохое качество замыкание на чеклисте самопроверки из SDD при работе в 1 поток. Конечно это не значит что нужно всегда и везде юзать 1 агента в монопоток. Но это призыв к тому чтобы не считать что мультиагентность - серебрянная пуля и точно является некоторой уверенной стадией зрелости харнеса. Необходимо все эвалами тестить, не устарело ли на актуальных моделях конкретные старые приемы в т.ч. конкретное использование сабагентов. Собственно есть разные поинты когда нужно идти в мультиагентов, когда нет. Например базовые правила что мелкие подзадачи с большим выводом и малым вводом можно делегировать чтобы экономить окно. И в недавних патчах агенты вроде claude code / codex даже начали САМИ это делать без ручных оптимизаций. Один из поинтов когда стоит нарезать мультиагентов вручную выразил Николай Сенин на AgenticDevConf и который я тоже нахожу весьма неплохим (скрин ниже). Еще поинт из того же доклада про то что иногда делегирование подзадач дает просто лишнюю потерю токенов т.к. нужно многим подагентам объяснять один и тот же контекст. Существует очень много разные точек роста харнеса, и мультиагентность лишь одна из многих инженерных практик для его прокачки. Возможно прокачка вашей SDD шины даст больше эффекта.

Глеб Михеев (кстати руководитель AI Native комитета в онтико) запустил опрос — исследование адаптации агентной разработки в компаниях. Мы всё сильнее видим расслоение в индустрии — очень хочется копнуть глубже и понять, как это выровнять. Сам опрос тут, его пустили по разным каналам в попытке больше собрать информации по состоянию в отрасли.

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

Скорость изменений в отрасли увеличилась кратно, как и появление новых инженерных практик и укладов. И попытка успевать потреблять все сигналы рынка и даже ключевой опыт граничит с безумием) Помимо личного и опыта в компании, основные потоки считывания сигналов у меня идут отсюда: - Telegram-каналы коллег по несчастью (они тоже генерят контент ппц как быстро). Кстати у одного из коллег по ПК AgenticDevConf - неплохие сводки https://t.me/nobilix/280. Такой формат особо ценен. - Habr. Я поднял себе с нового года Karakeep, в который скидываю (вручную) и классифицирую (аишкой) все статьи. Лучше, чем скидывать в избранное, — и приложуха есть. Правда, скорость прирастания очереди быстрее, чем скорость потребления. Минус что сейчас хабр пестрит нейрослопом, и отделать реальный промышленный опыт от нейрослопа или просто мелких слабо проверенных экспериментов одиночек - сложнее. - Конференции. Онлайн (попроще) и офлайн (посложнее). От офлайновых пользы сильно больше, т.к. там больше живого общения. - ПК в пачке конференций, где курирую AI SDLC-треки. TeamLeadConf, TechLeadConf, Highload, AgenticDevConf, Podlodka Crew, ПыхКонф и пр. Последний источник для меня самый ценный. Да, это доп. нагрузка на вечера и выходные. Но возможность первым узнавать о реальном прикладном опыте, который несут компании всех уровней, про результаты успехов и неуспехов их пилотов — это в наше время самый сок. И это доклады конференций, которые вы гарантированно отсмотрите, а не положите на полку «посмотреть», до которой никогда не доберётесь. И более того — примете участие в формировании ключевых мыслей, помогая в том числе и себе их оформить и зафреймить. Иногда вы созваниваетесь вроде как прогнать доклад, но первые полчаса пересказываете, что у вас изменилось за последние пару недель в рамках конкретной инженерной практики). В общем, доп. нагрузка того стоит, а живые коммуникации с такими же практиками, как ты, — самый сок. Иногда просто созваниваюсь с такими коллегами просто для регулярной сверки часов, поделится опытом. P.S. если вы построили свои автоматизированные пайплайны потребления и обработки контента - делитесь)

У меня были плотные пару неделек) Неделя конференций в Питере и неделя в Мск) - Выступление на HighloadConf, TeamLeadConf на тему уровней зрелости и инженерных практик в SDLC - 2 круглых стола на темы AI и матриц компетенций - Выступление на архитектурной конференции сбера посвященной AI Disrupt PDLC - Выступление на AgenticDev Conf про SDD - Участие в двух сессия коллективного решения проблем внедрения AI в рамках C level клуба При всем этом у меня не отпуск и рабочие задачи никуда не девались, по этому 2 недели сна по ~4 часа, а потом еще неделька разгребания того что не успел. Очень много общения с коллегами. Много мыслей. Понемногу выдыхаю и буду делиться)

better-auth.com Кайфовая восходящая open source звезда в мире аутентификации. — Почти во всем лучше next-auth (auth.js) который не может релизнуть 5 версию пару лет — Покрыл все базовые frontend & backend framework — Причем на нормальной глубине: например…