К основному содержимому
к презентации
Конспект выступления2026Fellow

Как AI меняет инженерную культуру и что это значит для тимлидов и инженеров

Александр Поломодов почти десять лет работает в Т-Банке и теперь отвечает там за AI в разработке, инженерию и архитектуру. Доклад он называет не теорией, а собственным планом действий: сначала исследование о влиянии AI на разработку, потом перестройка процесса и оргдизайна, роль тимлида и три вопроса в финале.

Яндекс · dream teamlead7 минут

Конспект сокращён относительно полного выступления; примеры и оценки передают опыт и позицию автора.

Основная линия материала
01

Метаанализ и опрос по России

Исследование выросло из того, что компания перестала видеть себя на фоне мира: внешних работ о влиянии AI на разработку много, российских почти нет. Поэтому начали с метаанализа — больше пятидесяти исследований с 2023 года по конец 2025-го, суммарно свыше полумиллиона респондентов, хотя, оговаривается автор, складывать выборки так нельзя. В обзор попали массовые опросы вроде DORA, Stack Overflow и JetBrains; телеметрия репозиториев, где стэнфордская группа по продуктивности берёт у компаний доступ к данным и смотрит динамику коммитов, пулреквестов и переделок; полевые эксперименты и внутренние корпоративные исследования с интервью. Громче всех прозвучал METR: шестнадцать разработчиков решали реальные задачи с AI и в итоге замедлились — правда, эксперимент был устроен так, что инструментами они не владели, а репозиторий был максимально неудобный. Результаты автор уже показывал на февральской конференции компании, а до этого о них выходили только посты.

Свой опрос сделали по методологии DORA: его увидели около 80 000 человек, заполнять начали примерно тысяча, на вопросы ответили порядка восьмисот, до конца дошли 350; каузальная часть выйдет в апреле, пока возможен описательный анализ. Ограничения автор проговаривает сам: самооценка, плавающая от вопроса к вопросу выборка, влияние процессных изменений в компаниях, отсутствие рыночного консенсуса о метриках продуктивности и эффект новизны, который уходит за квартал или полгода. Картина такая: проникновение в крупных опросах перевалило за 90%, кодинг ускорился, а доставка — нет, DORA-2024 показала падение пропускной способности, отчёты 2024–2025 — рост нестабильности на проде, 30–40% не доверяли результатам AI, а метаанализ подразделения MIT дал 5% инициатив, которые успешно доходят до конца: остальные зависают на рассмотрении, пилоте или масштабировании. Российские данные повторяют то же с отставанием: качество выросло у 32% и упало у 14%, не доверяют AI 49%, а генерацию кода, по метаанализу и опросу вместе, часто или всегда используют 58%.

02

От ролевого SDLC к агентному контуру

Чтобы показать разницу, автор нарисовал на внутренней доске две схемы. Слева — классический процесс: продакт с гипотезами, рядом дизайнеры, аналитики со спецификациями, разработчики, QA, SRE с деплоем и саппорт, разбирающий проблемы. В 2025 году в компании заходили в AI именно так: лидеры профессий — системного анализа, разработки по языкам, тестирования — придумывали, как ускорить свой участок. Больше идей, быстрее документация, быстрее код, автотесты генерируются сами. Внутренние циклы ускорились, но на передачах ответственности встали пробки: автострада упирается в то же горлышко, и сквозная поставка выросла не настолько, насколько хотелось. Осенью, когда вышли новые модели OpenAI и Google, агентские сценарии заработали достаточно автономно — там, где раньше требовался человек в контуре, он нужен уже не всегда; сам автор последние три месяца много писал код с агентами и говорит: небо и земля.

Справа — контур с меньшим числом передач: продакт доводит идею до требований и прототипа через внутренний аналог Lovable или Replit, который собирает интерфейс по вашим гайдам и деплоит в вашу инфраструктуру, а инженер просит агентов написать тесты, задеплоить и помочь с эксплуатацией. Внутри у компании это плагины к IDE, CLI вроде Claude Code и собственный генератор фронтенд-приложений. Веру в такой контур автор объясняет чтением пейперов: Google чинит самые больные сценарии разработчика вместо ровного слоя из developer tools; Meta описала just-in-time тесты — эфемерные, которые генерируются под конкретное изменение, потому что накопленных тестов много, а ловят они мало; у AWS после серии сбоев утекло мемо, что сделанные с AI-инструментами изменения новичков теперь подтверждают сеньоры. Свежий отчёт DORA автор пересказывает как закон Матфея: сильной инженерной базе AI помогает, слабая просто генерирует случайный код и переделки, рост которых видно и в стэнфордских данных. Отсюда рецепт: новый режим пилотировать на гринфилде, где правила задаются сразу, а с браунфилдом возить практики в обе стороны.

03

Оргдизайн, тимлид и финальные вопросы

Оргдизайн связан с процессами и архитектурой, поэтому вслед за сжатием ролей сжимаются и слои управления: длинная иерархия — это медленные решения, и быстрый код не помогает, если изменение идёт через цепочку согласований до генерального директора. Добавляется финансовое давление: показатели считают в расчёте на человека и спрашивают, нужен ли стадион людей там, где другая компания обходится сотней. Сигналы рынка автор перечисляет подряд: в Meta есть applied-команда, где один менеджер приходится на пятьдесят инженеров, похожее соотношение у Хуанга («не знаю, как он управляет, но, наверное, судя по капитализации, хорошо»), Amazon хотел на 15% больше индивидуальных контрибьюторов, Intel говорит об уплощении, а гость его подкаста из Microsoft после перехода из менеджеров в staff- или principal-инженеры сказал, что теперь просто не отвечает за развитие людей. Но плоская структура без платформы, проторённых путей и автоматически проверяемых policy не работает: узкое место уезжает дальше по пайплайну, а сеньоры вместо архитектуры работают полуменеджерами.

Работа тимлида смещается от распределения задач, найма и ритуалов к проектированию системы, в которой работают люди и агенты: правила команды и знание о продукте переезжают из вики в репозиторий, задачи делятся на те, что можно отдать агенту, те, что требуют глубокого ревью, и те, что делегировать нельзя, а приёмку и definition of done команды, с которыми он общался, стараются проверять автоматически. Метрики берут корпоративные — DORA, SPACE, DevEx — или придумывают свои. Риски он называет прямо: эрозия навыков у джунов, иллюзия скорости и недоверие, переходящее в саботаж. После доклада спросили, не обесценивает ли AI опыт тех, кто знает историю кодовой базы. Ответ: ставка на монополию знания («дорабатывать модуль может только Вася») плохая, знание стараются сделать явным для людей и агентов, а ценность смещается к тому, чтобы придумать, что делать, и проверить результат. Сам он готовит ADR за десятки минут вместо недели, но предупреждает: гениальных гипотез, приносящих деньги, не так много.

Выводы

Что стоит унести с собой

  1. 01Личная продуктивность и командный результат — разные вещи: код пишется быстрее, а изменение всё равно ждёт тестов, ревью и релиза, поэтому мерить нужно сквозной поток, а не скорость набора.
  2. 02Агенты усиливают то, что уже есть: без тестов, гейтов, платформы и автоматически проверяемых policy быстрая генерация даёт переделки, шумные тесты и нестабильность на проде.
  3. 03Нормы вроде одного менеджера на пятьдесят инженеров не догма: плоская структура работает лишь там, где узкое место не переезжает на согласования, а сеньоры не превращаются в полуменеджеров.
  4. 04Закрытый контур не приговор: открытые модели, если говорить о китайских, отстают месяца на три-четыре, а разницу чаще делает агентский тулинг вокруг модели, а не сама модель.

Источники