Code of Leadership

У среднего бизнеса с AI есть неприятная развилка. Лаборатория, платформа и команда редких специалистов — тяжёлый входной билет. Но личные подписки, разрозненные демо и один «AI-волшебник», работающий по вечерам, ещё не складываются в практику.

Сегодня в 17:00 проведем прямой эфир (https://www.youtube.com/watch?v=S5-I72_K004) и обсудим это вместе с Александром Воронцовым, партнером @revelio_tech и автором канала AI Subjects (@aisubjects, изучает когнитивные ошибки при работе с ИИ). В прошлом разговоре (https://www.youtube.com/watch?v=gpYZr8RQlSw) мы дошли до важной точки: внешний эксперт уйдёт, а внутри должен остаться человек, который понимает задачу, проверяет результат и продолжает изменение. Теперь разбираемся, как получить и удержать эту способность, если сильные люди заняты основной работой, а нанимать AI-департамент рано.

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

Timeline
00:00 - Александр Воронцов: AI без лаборатории и многомиллиардного бюджета
01:52 - Что считать средним бизнесом и практическим внедрением AI
05:55 - Маржа, логистика и конкретная проблема как отправная точка
10:10 - Почему доступ к Claude или Codex ещё не меняет работу
12:25 - Удачный кейс торговой компании: начать с сотрудников
14:55 - Конкурс прототипов, денежная мотивация и системный аналитик
16:56 - Чувствительные данные и ограничения облачных моделей
20:20 - Кому поручить ответственность за внедрение AI
22:30 - Неоднозначный кейс растущей аутстаффинговой компании
27:40 - Почему разрозненным инициативам нужен внутренний IT-партнёр
32:00 - Один лидер, внешняя команда или несколько специалистов
36:40 - Почему ускорение написания кода не ускоряет весь процесс
39:30 - Как небольшой масштаб помогает запускать изменения за часы
48:50 - AI как новый слой автоматизации: работа с дебиторской задолженностью
59:00 - Короткая диагностика, первые задачи и ценность живого диалога

#CodeOfLeadership #AI #Consulting #Leadership #Management #DigitalTransformation

AI-агенты сделали первый вариант решения быстрым и дешёвым. Джун теперь может за короткое время подготовить убедительный прототип, тесты и pull request. Но готовый артефакт ещё не доказывает, что инженер понимает систему, способен проверить результат и готов отвечать за последствия изменения.

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

В этом выпуске Александр Поломодов разбирает, как AI-агенты меняют путь от джуна до самостоятельного инженера.

В выпуске:

Timeline
00:00 - Зачем заново определять путь джуна в эпоху AI
01:07 - Почему одинаковое демо не означает одинакового понимания системы
02:38 - Артефакт, рабочая задача и развитие системы
08:22 - Что исследования говорят об ускорении начинающих инженеров
12:30 - Почему опыт в конкретной задаче важнее формального грейда
17:51 - Почему ускорение написания кода теряется на пути к выпуску
19:08 - Джуну отдали весь продукт: как справиться с ответственностью
22:27 - Как агенты убирают нижнюю ступень инженерного обучения
25:44 - Как делегировать работу агенту и сохранить собственное суждение
30:21 - Рост от готового артефакта к ответственности за систему
36:43 - Стабильность, защитные ограничения и инженерные компромиссы
42:55 - Ответственность мидла и портфель решённых инженерных задач
46:17 - Интервью, на котором видна работа кандидата с агентом
49:30 - Как превратить ученичество в работающую систему
51:57 - Код дешевеет, инженерное суждение — нет

Мы много говорим о первых 90 днях в новой роли. Мне захотелось разобрать обратную сторону перехода — последние 90 дней в компании.

31 августа проведу сольное выступление Code of Leadership #Ω — выпуск «Омега». Оно не только про увольнение. У этого процесса есть три равноправных исхода: остаться в пересобранной роли, перейти внутри компании или уйти.

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

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

Для меня главный тезис такой: последние 90 дней — это не обратный отсчёт до увольнения. Это управляемый переход между двумя профессиональными главами. И следующие 90 дней фактически начинаются ещё до завершения предыдущих.

Слайды и материалы:
https://polomodov.tech/2026-08-31-last-90-days-in-company/

#Management #Leadership #Career #Engineering #CodeOfLeadership

Что остаётся дефицитным, когда код становится дешёвым: инструменты, инженерное мышление или доверие между компанией и разработчиками?

В очередной серии подкаста Code of Leadership поговорим с Сергеем Бережным — директором по взаимодействию с разработчиками Яндекса, CTO Яндекс Практикума и одним из соавторов методологии БЭМ (https://veged.ru/). Сергей работает в Яндексе с 2005 года и прошёл путь от разработки интерфейсов до DevRel, open source и образования. Но разговор будет не про карьерную ретроспективу. Хочу понять, как техническое лидерство выходит за границы одной команды и проявляется в методологиях, платформах, работе с сообществом и публичной ответственности.

Обсудим:
- Зачем бизнесу DevRel и чем измерять его результат;
- Почему внутреннюю технологию стоит открывать миру и как выбирать проекты для open source
- Как разработка проходит путь от автодополнения к AI-агентам и harness-системам;
- Что происходит с ролью руководителя, когда частью команды становятся агенты;
- Кого и чему учить, если привычные entry-level задачи всё чаще забирает AI.

Смотрите выпуск и приносите в комментарии свои вопросы и примеры.

23 августа в 16:00 по москве Александр Поломодов отвечает на вопросы подписчиков «Книжного куба».

В программе:

Плюс еще был ряд дополнительных вопросов в чате трансляции

Как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением?

17 августа в 19:00 МСК в эфире Code of Leadership вместе с Михаилом Тюргановым, руководителем Департамента разработки цифровых сервисов Альфа-Банка, поговорили про его путь от тестировщика, программиста и CEO малого бизнеса до технологического директора.

В эфире мы обсудили:
- Чем CTO малого бизнеса отличается от CTO в enterprise;
- До какого масштаба работают сильные люди и неформальные договорённости;
- Как отличить нужный найм от попытки закрыть организационную проблему численностью;
- Что дают метрики эффективности и когда команда начинает играть с дашбордом;
- Почему сильный инженер не обязан становиться менеджером;
- За что CTO должен отвечать лично, а что превращать в платформу, процесс и инженерный карьерный трек;
- Как AI и вайбкодинг меняют требования к скорости, проверке и эксплуатации.

#Management #Leadership #Engineering #Architecture #PlatformEngineering #AI4SDLC

В четверг в 13:30 по Москве вместе с Алексеем Литвиновым в прямом эфире продолжили говорить про AI-Assisted Engineering и про то, как вообще строить AI-Native организацию. Первые две AMA сессии прошли плотно и мы разобрали порядка 15 вопросов, но еще осталось около шесть, которые мы разобрали с Лёшей в третьей серии. Кстати, у Леши есть свой tg-канал - t.me/tip_podcast, подписывайтесь на него.

Обсуждение с Альбиной Мунировой из Т-Банка последние изменения в профессии продакт менеджеров, когда граница между ним и ML-инженером становится заметно тоньше. Прототип теперь можно собрать за несколько дней, но главный вопрос начинается после демо: кто превратит продуктовое намерение в воспроизводимые проверки и возьмёт ответственность за поведение вероятностной системы?

Альбина Мунирова - лидом продуктов в AI-центре Т-Банка, бывший ML-инженер и тимлид, лидером и создателем профессии ML-продакт-менеджера в банке.

Центральная формула разговора - PRD == evals. Разберём, что она означает в реальной работе и почему это не просто замена одного документа таблицей тестовых вопросов.

Поговорили о том:

- Кто такой AI Product Builder и действительно ли это новая профессия;
- Что продакт теперь должен уметь делать руками, а где специализация MLE остаётся критичной;
- Как перевести требования к ассистенту в eval-набор, порог выпуска и продуктовые метрики;
- Почему быстрый MVP ещё ничего не говорит о стоимости проверки и промышленной эксплуатации;
- Как, по словам Альбины, её команда в 2023 году строила инвест-ассистента на RAG, когда готовая обвязка только формировалась;
- Почему ассистент «по всему банку» - это не один большой промпт, а маршрутизация, данные, права, инструменты, память, безопасность и разные владельцы качества;
- Что опыт ассистента Олега может дать современным LLM-продуктам.

Для меня главный вопрос эфира такой: AI Product Builder - это новая клетка в оргсхеме или новый минимальный уровень владения результатом от проблемы до доказательства качества?

#AI #Product #MachineLearning #Evals #Engineering #Agents

Работают ли ваши разработчики на 100%? И можно ли вообще ответить на этот вопрос по коду - без табелей, дополнительных отчётов и субъективной оценки руководителя? А если в работе случился спад - отличить недозагрузку от сложного легаси, техдолга, незнакомой технологии или месяца тяжёлой отладки?

6 авугста в 17:00 по Москве со мной в прямом эфире будет Иван Гель, основатель  компании Dex, в рамках подкаста Code of Leadership. Мы поговорим об UpCore - системе, которую команда называет «цифровым тимлидом».

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

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

Но здесь и начинается самый интересный разговор. Код - важный результат работы инженера, но далеко не вся его работа. Архитектурные решения, помощь команде, ревью, исследование, предотвращённые ошибки и сложность контекста плохо сводятся к одному числу. А метрика, от которой зависят грейд, бонус или увольнение, быстро становится целью для оптимизации.

Обсудим:

- Что именно UpCore считает эффективностью и как нормализует разные проекты, стеки и типы задач;
- Можно ли автоматически определить грейд и трудоёмкость только по коду;
- Как в текущих условиях, когда код пишется с помощью ИИ, можно измерить эффективность программиста.
- Как отличить слабую работу от легаси, техдолга, сложного ядра системы и длительной отладки;
- На каких данных проверялись заявленные 85% точности и рост на 12%;
- Повышает ли полная прозрачность осознанность разработчика или разрушает доверие в команде;
- Как защитить такую систему от накрутки и саму команду - от ошибочных управленческих выводов;
- Где проходит граница между полезной инженерной телеметрией и цифровой слежкой.

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

В среду в 17:00 по Москве вместе с Алексеем Литвиновым в прямом эфире продолжили говорить про  AI-Assisted Engineering и про то, как вообще строить AI-Native организацию. За первую серию AMA сессии (https://www.youtube.com/watch?v=4fiExYKIP3Y) мы не справились со всеми вопросами, поэтому мы продолжим обсуждать это с Лёшей, у которого есть свой tg-канал - @tip_podcast, подписывайтесь на него.

Мы договорились обсудить
- зрелость работы с AI // от «пишу код сам» до экосистемы на принципах
- verification debt и цена проверки
- почему навык уезжает из кодинга в менеджмент
- AI-native организация: операционка, роли, governance
- люди и найм, когда рядом агенты