TechLead Stream | Иван Поддубный
Видео
20260701_184604.mp4 · 64.8 МБ · нажмите — покажем
20260701_184604.mp4 · 64.8 МБ · нажмите — покажем
Фотография
нажмите — покажем
нажмите — покажем
Фотография
нажмите — покажем
нажмите — покажем
Фотография
нажмите — покажем
нажмите — покажем
Фотография
нажмите — покажем
нажмите — покажем
Фотография
нажмите — покажем
нажмите — покажем
Скорость изменений в отрасли увеличилась кратно, как и появление новых инженерных практик и укладов. И попытка успевать потреблять все сигналы рынка и даже ключевой опыт граничит с безумием)
Помимо личного и опыта в компании, основные потоки считывания сигналов у меня идут отсюда:
- Telegram-каналы коллег по несчастью (они тоже генерят контент ппц как быстро).
Кстати у одного из коллег по ПК AgenticDevConf - неплохие сводки https://t.me/nobilix/280. Такой формат особо ценен.
- Habr. Я поднял себе с нового года Karakeep, в который скидываю (вручную) и классифицирую (аишкой) все статьи. Лучше, чем скидывать в избранное, — и приложуха есть. Правда, скорость прирастания очереди быстрее, чем скорость потребления.
Минус что сейчас хабр пестрит нейрослопом, и отделать реальный промышленный опыт от нейрослопа или просто мелких слабо проверенных экспериментов одиночек - сложнее.
- Конференции. Онлайн (попроще) и офлайн (посложнее). От офлайновых пользы сильно больше, т.к. там больше живого общения.
- ПК в пачке конференций, где курирую AI SDLC-треки. TeamLeadConf, TechLeadConf, Highload, AgenticDevConf, Podlodka Crew, ПыхКонф и пр.
Последний источник для меня самый ценный. Да, это доп. нагрузка на вечера и выходные. Но возможность первым узнавать о реальном прикладном опыте, который несут компании всех уровней, про результаты успехов и неуспехов их пилотов — это в наше время самый сок. И это доклады конференций, которые вы гарантированно отсмотрите, а не положите на полку «посмотреть», до которой никогда не доберётесь. И более того — примете участие в формировании ключевых мыслей, помогая в том числе и себе их оформить и зафреймить.
Иногда вы созваниваетесь вроде как прогнать доклад, но первые полчаса пересказываете, что у вас изменилось за последние пару недель в рамках конкретной инженерной практики).
В общем, доп. нагрузка того стоит, а живые коммуникации с такими же практиками, как ты, — самый сок.
Иногда просто созваниваюсь с такими коллегами просто для регул
2 · 752 · ОтветСкорость изменений в отрасли увеличилась кратно, как и появление новых инженерных практик и укладов. И попытка успевать потреблять все сигналы рынка и даже ключевой опыт граничит с безумием)
Помимо личного и опыта в компании, основные потоки считывания сигналов у меня идут отсюда:
- Telegram-канал
А нужно ли потреблять контент и сигналы с рынка с такой скоростью?)
Готов поспорить что - "да" и мы вынуждены это делать чтобы не ошибаться в инженерных, архитектурных и организационных вопросах.
Нет универсально правильных, выверенных годами способов решения совершенно новых для отрасли задач и вызовов в области построения ai sdlc процессов.
По этому вместо своего RnD подсмотреть у соседей что уже получилось или у других что не зашло - бесценно.
Вы сэкономите кучу времени на проверке неправильных гипотез.
"Пойти не туда" - самое больное. И на всех уровнях - от деталей реализации харнеса, до организационных изменений - количество вариантов где можно поставить "не на ту лошадку" очень много.
Большинство изменений которые мы сейчас внедряем - несут риски.
Примеры из жизни ПК. Примеры чуть упрощены, но смыслы именно такие.
1. Ребята из одной компании приносят продукт для sdlc. Члены ПК экспертно заявляют что ребята потратили несколько месяцев работы зря, их решение уже устарело и его нужно было делать совсем иначе. Из-за не правильного считывания сигналов рынка - месяцы работы не по той дорожке.
2. Для другой конференции мы начали отбирать доклады за 3+ месяца. И часть докладов которые казались актуальными в марте, в июне уже сильно менее актуальны.
То что казалось революцией 3 месяца назад, сейчас уже данность.
> Выпасть на 1-2 месяца из этого зверского информационного потока - значит принимать неправильные решения в трансформации производства за которую ты отвечаешь.
Как бы не звучало смешно - но практика которая прожила год или хотя бы 6 месяцев с результатами - это прям штука за которую стоит хвататься)
Каждую практику ты еще вынашиваешь применительно к своим процессам, анализируешь относительно трендов и рынка, 10 раз взвешиваешь прежде чем кинуться ее внедрять.
Тут стоит отдельно похвалить коллег из сбера которые не побоялись выпустить AI Disrupt PDLC как набор устоявшихся практик, трендов и веяний который они взяли смелость зафиксировать в документ. Кол
9 · 755 · TechLead Stream | Иван Поддубный
Ссылка
нажмите — покажем
нажмите — покажем
Глеб Михеев (кстати руководитель AI Native комитета в онтико) запустил опрос — исследование адаптации агентной разработки в компаниях.
Мы всё сильнее видим расслоение в индустрии — очень хочется копнуть глубже и понять, как это выровнять.
Сам опрос тут, его пустили по разным каналам в попытке больше собрать информации по состоянию в отрасли.
1 · 741 · Фотография
нажмите — покажем
нажмите — покажем
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 и который я тоже нахожу весьма неплохим (скрин ниже).
Еще поинт из того же доклада про то что иногда делегирование подзадач дает просто лишнюю потерю токенов т.к. нужно многим подагентам объяснять один и тот же контекст.
Су
9 · 883 · TechLead Stream | Иван Поддубный
Фотография
нажмите — покажем
нажмите — покажем
Фотография
нажмите — покажем
нажмите — покажем
На Пыхнике будет выступать наш PHP тимлид Денис, поделится опытом ai трансформации команды и процессов, шишках с которыми столкнулись в его команде на этом пути.
Сам Пыхник кстати гибридный, часть онлайн, часть оффлайн. Основная часть в оффлайне.
Вообще и другие классные доклады про AI трансформации будут.
Например Саша Макаров еще сделает вечером сессию обсуждения как старые классические парадигмы программирования вроде DDD или АОП по другому заиграли в ai-native разработке.
Мне такое прям очень откликается. Многие архитектурные парадигмы могут быть переосмыслены в современном мире.
Подробнее тут
https://t.me/phpyhconf/209
2 · 1.1K · TechLead Stream | Иван Поддубный
Немного про измерение эффективности от внедрения AI в SDLC
Количество часов разговоров с коллегами в отрасли на эту тему за последний год я бы мог исчислить десятками)
Например пол года назад тут с коллегами из Т-Банк, Яндекс и WB (FunSun) или пару недель назад в круглом столе про ФОТ. Или под новый год на митапе smallTech.
Также много разговоров с коллегами в кулуарах Saint Haighload++, TeamLeadConf, Sber Arch.Meethup и еще многих других.
Кстати так сложилось что практически не обсуждали на Agentic Dev Conf, там как будто бы у людей другой вайб, сильно больше тех кто уже обосновал для бизнеса эффективность.
Я бы разделил следующие фазы этого дискуссии.
# ФАЗА 1:
А ТОЧНО ЛИ УСКОРЯЕТСЯ САМ ПРОЦЕСС РАЗРАБОТКИ?
## Лагерь сомневающихся в ускорении
В многом коллеги ссылаются на какие нибудь среднерыночные исследования, но берут конечно те, которые подчеркивают их картину мира, игнорируя отчеты и кейсы других компаний. Здесь мне кажется стоит разбирать кейсы, практический опыт и результаты конкретных компаний и потенциал воспроизводимости тх опыта. Это точно полезнее средних опросов по больнице.
Второй их основной довод: у нас в компании сеньеры тратят 10% на код, а львиная часть на решение блокеров и других вопросов. И правильное следствие (которое происходит не у всех) - анализировать узкие места и решать, то что 10% пишется код порой может быть следствием неэффективности построения команд или межкомандного взаиможействия, процессов внутри.
На мой взгляд в таких случаях правильный вопрос: а стоит ли параллелить решение вопросов. Иногда можно на AI рельсах пересобрать новомодные tiny team это как раз способ и перезагрузить проржавевшие старые процессы.
А с AI флагом сейчас можно как раньше с agile флагом ломать многие преграды внутри корпоративных укладов.
Третий довод: что упираемся в когнитивные возможности человека на валидацию (многие об в т.ч. Никита в канале SE Materials подсвечивает риск).
Я бы тут прокомментировал что большую часть когнитивных возможнос
18 · 1.4K · TechLead Stream | Иван Поддубный
Фотография
нажмите — покажем
нажмите — покажем
Несмотря на то что я уже лет 20 живу в Ростове-на-Дону, корнями я из Урала и Сибири. Отец военный и, родившись на Урале, я успел пожить в нескольких сибирских городах)
Но в душе я сибиряк и до сих пор говорю что "у нас в сибири", хотя по логике уже должен был давно перестать)
Радостно что в Сибири тоже проходят движуха, и в этот раз я немного помог ближайшему TeamLead Сибирь, проходящему в Новосибирске с подготовкой нескольких докладов в AI треке)
Кажется будет прям неплохо, если собираетесь посетить забирайте промокод от члена ПК: PODDUBNY
https://teamleadconf.ru/siberia/2026
P.S. Фирменный стиль конфы с мишками у них огонь)
2 · 916 · TechLead Stream | Иван Поддубный
Сегодня вечером поделюсь про матрицы зрелости у коллеги на канале)
По сути обновленный контент моего доклада с хайлоада про матрицы зрелости и инженерные вызовы построения автономности.
Приходите кому интересно, онлайн трансляция
789 · Фотография
нажмите — покажем
нажмите — покажем
Уровни зрелости внедрения AI в процессы разработки 🌶️
Завтра на System Design Chill'e эксперт Иван Поддубный 🤝:
🔘Разберёт мировые и локальные модели оценки зрелости AI в разработке;
🔘Покажет, как честно определить, на каком уровне находится команда или компания;
🔘Расскажет, что меняется в инфраструктуре, процессах и роли разработчика на каждом следующем уровне.
🤔 2 случайных факта о нас:
1. Познакомились в буфетной в офисе X5 на BigTechNight прошлой осенью
2. Установили, что жили оба в детстве в Восточной Сибири - буквально в неполных двух часах езды друг от друга, недалеко от Ангары 😲
Регистрация на эту среду 19.08.26 19:00:
—> System Design Chill. AI <—
—-
Кто ещё сибиряк/сибирячка? :)
3 · 1K · TechLead Stream | Иван Поддубный
Фотография
нажмите — покажем
нажмите — покажем
Можно сгенерировать дропдаун на 200 строк JavaScript, но никто не скажет, что браузер уже умеет это в 20 строк CSS. 🤓
28 августа в 19:00 на онлайн-митапе разберемся, кто в 2026 году все еще читает спецификации и зачем это команде.
Без абстрактных рассуждений, только по делу: 😎
❓ Зачем читать спеки, если код можно просто сгенерировать. Как ставить задачу и как проверять результат, чтобы не получить решение пятилетней давности
❓ Почему caniuse не отвечает на вопрос, можно ли в прод. Вебвью супераппов, старые андроиды и корпоративные машины против красивых процентов. Как считать свою аудиторию, а не мировую
❓ Откуда возьмутся инженеры, если в код никто не заглядывает. Наем, рост и как отличить понимание от умения промптить
Спикеры: 🎙
📢 Иван Поддубный, CTO Вебпрактик
📢 Алексей Рахманов, CTO FUN&SUN
📢 Александр Гончаров, заместитель технического директора ГК «Юзтех»
Регистрация по ссылке. Ждем вас!
11 · 1.1K · TechLead Stream | Иван Поддубный
Ссылка
нажмите — покажем
нажмите — покажем
Как используют клод при производстве деталей)
Выводы в конце содержат флешбеки к ит =)
https://youtube.com/shorts/kTBf_8743aA?si=KNqGfRMHRU2SrUq3
11 · 833 · TechLead Stream | Иван Поддубный
GIF
vacuumwars-robot-vacuum.gif.mp4 · 97 КБ · нажмите — покажем
vacuumwars-robot-vacuum.gif.mp4 · 97 КБ · нажмите — покажем
Я вечером со своими агентами =)
31 · 1.3K · Ссылка
нажмите — покажем
нажмите — покажем
Интересные скилы для визуализации архитектуры.
1. https://github.com/tt-a1i/archify
2. https://github.com/cathrynlavery/diagram-design
67 · 964 · TechLead Stream | Иван Поддубный
ОтветТоп-10 факторов, снижающих продуктивность разработчиков в Google.
В вопросе инженерам предлагается выбрать три основных фактора, и вариантов больше, чем показано здесь.Согласен с постом, но хочу докинуть своего мнения)
Наибольших результатов в агентской разработке сейчас добиваются хорошие менеджеры с техническим прошлым.
Качество кода для них давно не святая корова. А за время менеджмента они научились двум вещам: декомпозировать задачу, понижая когнитивную сложность до уровня «поймёт последний джун», и формулировать образ результата, чтобы команда понимала, в какую сторону копать. Агенту нужно ровно то же самое.
Плюс пара бонусных навыков. Терпимость к тому, что результат вышел не совсем таким, как задумывали. И готовность выкинуть совсем нерабочее решение целиком — без жалости к потраченному времени. Тем более что в конце проекта не всегда оказывается, что он вообще был так уж необходим.
8 · 811 · TechLead Stream | Иван Поддубный
Ссылка
нажмите — покажем
нажмите — покажем
Плановое обслуживание кода
Даже если вы настроили у себя процесс разработки, в котором все делают агенты, есть задачи которые они не могут выполнить качественно в моменте. В основном это связано с тем, что они фокусируются вокруг тех изменений с которыми работают прямо сейчас. Причем каждое конкретное изменение может выглядеть допустимо, но если посмотреть на дистанции, то будет видна деградация, постепенное расползание плохих практик, дублирование, отсутствие обобщения там где оно напрашивается.
Поэтому в процесс нужно включать задачи по расписанию, которые имеет смысл запускать раз в неделю или месяц. Ниже расскажу что я делаю сам с помощью каких команд или скилов.
Эффективность агента
/doctor (Claude Code) — раз в месяц проверяю здоровье агентского окружения: конфигурацию, неиспользуемые скилы и MCP, медленные хуки, проблемы с permissions и другие накопившиеся проблемы. Заодно помогает освобождать память от устаревшего и лишнего.
/fewer-permission-prompts (Claude Code) — анализирует историю работы и предлагает, какие часто используемые безопасные команды стоит добавить в allowlist, чтобы агент меньше отвлекал подтверждениями.
/run-skill-generator (Claude Code) — периодически пересобирает знания агента о том, как поднять и проверить проект, чтобы /run и /verify не опирались на давно устаревшие команды.
/retro (Matt Pocock Skills) — формально не плановая задача. Запускаю после сессии, где агент заметно буксовал, делал лишние шаги или его приходилось несколько раз исправлять. Скил анализирует, что можно поменять в инструкциях, автоматических проверках и окружении, чтобы эта проблема больше не повторялась.
Качество кода
/simplify (Claude Code) — прохожусь по активно меняющимся частям проекта. Ищет дублирование, лишние абстракции, возможность переиспользовать уже существующий код и просто слишком сложные решения. Удобно запускать раз в неделю по нескольким наиболее активно меняющимся каталогам.
/code-review (Claude Code; у Matt Pocock также есть одноимённый
33 · 323 · TechLead Stream | Иван Поддубный
Ссылка
нажмите — покажем
нажмите — покажем
Почему нам нужны визионеры
Недавно DHH выступил на Rails World и по полной прошелся по привычному программированию. Сказал, что писать код руками становится экономически бессмысленно, что сам почти перестал писать на Ruby, а часть нового HEY они делают на Rust, который он сам не знает и воспринимает как черный ящик для агентов (но уверен что он тут специально нагнетает).
Этим он подорвал столько пердаков, что из космоса было видно зарево. Мой твиттер на неделю превратился в бесконечный срач. На Reddit появились треды в духе "уберите DHH из Rails", Aaron Patterson посвятил значительную часть своего закрывающего доклада ответу DHH. Как вообще создатель Rails может выйти на Rails-конференцию и рассказывать людям, что язык, фреймворк и даже понимание собственного кода скоро могут перестать иметь прежнее значение?
DHH самый настоящий визионер, не в смысле что он умеет и хорошо предсказывает будущее, такие люди вообще довольно часто ошибаются. Визионерство это способность увидеть большой сдвиг раньше большинства, построить вокруг него цельную картину будущего и начать действовать так, как будто эта картина уже становится реальностью. Поэтому визионеры почти всегда выглядят слишком радикальными. Когда их идеи становятся очевидными, никакого визионерства уже не требуется, тут уже можно строить планы, выделять деньги, нанимать команду и вперед на галеру.
Практически любой большой технологический переход требует от кого-то сделать ставку раньше остальных.
Apple много раз отказывалась от вещей, которые рынок считал обязательными. Стив Джобс убирал флопи диски, отказывался от физической клавиатуры в смартфоне, воевал с флешом. Каждое отдельное решение можно было критиковать, но за ними стояла цельная картина того, что ПК должен стать ближе к бытовому устройству, чем к набору технологий.
Амазон годами инвестировал в инфраструктуру и рост вместо прибыли. AWS поначалу вообще выглядел почти побочным направлением интернет-магазина. Сегодня идея покупать вычисления как электриче
7 · 352 · TechLead Stream | Иван Поддубный
Фотография
нажмите — покажем
нажмите — покажем
В мире с миллиардом Эйнштейнов кому-то всё равно придётся строить лаборатории, вести бухгалтерию и таскать материалы…
Кажется, это все нам придется делать:(
На сайте OpenAI вышло авторское эссе The Eternal Complement.
И там есть хороший вопрос:
👉🏼 насколько быстрее вообще сможет развиваться цивилизация, если интеллект перестанет быть дефицитом?
Вот Галилею, чтобы посмотреть дальше в космос, понадобились две линзы и трубка.
А чтобы человечество посмотрело ещё дальше с помощью James Webb, понадобились около $10 млрд, сотни организаций, десятки стран, сложнейшее производство, логистика и годы координации.
То есть проблема была уже не только в том, чтобы придумать хороший телескоп.
Нужно было ещё как-то построить его в физическом мире, найти финансирование, продать идею и потом все это скоординировать.
Есть исследование Nicholas Bloom и соавторов: чтобы поддерживать темп роста плотности транзисторов, сегодня требуется больше чем в 18 раз больше исследователей, чем в начале 1970-х. Похожие тенденции они нашли в сельском хозяйстве и медицине.
То есть прогресс не становился проще, но мы просто бросали на него всё больше людей, денег и инфраструктуры.
А теперь представим, что интеллект стал почти бесплатным.
AI может:
- придумать лекарство;
- предложить новый материал;
- спроектировать двигатель.
Но лекарство всё равно нужно испытать, материал - произвести, двигатель собрать и проверить.
И природе, короче, вообще всё равно, насколько умный у вас AI 😁
Авторы предлагают два возможных сценария.
Первый : «цивилизация глубины».
AI становится настолько хорош в моделировании мира, что нам нужно всё меньше физических экспериментов. Он просто гораздо точнее понимает, что действительно стоит проверять.
Второй - «цивилизация ширины».
AI производит настолько много хороших идей, что узким местом становятся уже лаборатории, заводы, энергия, производство и логистика.
Чем дешевле становится интеллект, тем ценнее может становиться исполнение.
Потому что между:
«Я приду
3 · 284 ·