Как AI влияет на продуктивность опытных разработчиков

Ведущий начинает с рамки: METR — организация, которая бенчмаркает модели, — в начале 2025 года засетапила эксперимент и померила эффективность инженеров, дорабатывающих open-source-фреймворки. Получилось статистически значимое замедление, отчёт разошёлся по индустрии, на него начали ссылаться. Александр сначала его проигнорировал, потом всё-таки написал о нём в своём канале и на Medium, но хотел обсудить пейпер с тем, кто понимает, как такие эксперименты сетапятся и как оценивается их валидность и статистическая сила. Артём рассказывает о себе: последние несколько лет он занимается эффективностью разработки и Developer Experience — сначала в Сбере, теперь в Яндексе, где он по сути CPO платформы для разработчиков в городских сервисах. AI в разработке он начал заниматься ещё в Сбере, активно — в 2023 году, и подчёркивает, что это не единственная его тема, а один из инструментов повышения эффективности.

Александр читал не только выжимку с результатами, но и все пятьдесят страниц — вплоть до объявления, по которому набирали людей. Искали опытных контрибьюторов крупных open-source-репозиториев, платили им заметную сумму за час работы, просили записывать видео экрана и брать реальные задачи из этих же репозиториев — так, чтобы они прошли код-ревью и были смёржены в основную ветку. Всего 246 задач и 16 инженеров, случайное деление на тех, кому ассистент разрешён, и тех, кому нет; перед задачей человек фиксирует estimate, после — фактическое время. Разметку активностей, по словам Александра, делали, кажется, сами исследователи, отсмотрев многие часы видео. Задачи, по его памяти, укладывались примерно в один-четыре часа, крупные декомпозировали. Интервью на выходе было точно, на входе — скорее отсев. На эксперимент ушло, он не помнит точно, то ли сто, то ли двести тысяч долларов.

Первое, о чём думает Артём, — кто спонсор исследования. Фокус в нём, насколько он помнит, на моделях Anthropic, а логику компании он описывает так: сначала выходят пугающие исследования о том, на что модель готова ради выживания, а потом по бенчмаркам оказывается, что самые человеколюбивые и безопасные модели — как раз у Anthropic; отсюда вопрос про долю предвзятости. Александр возражает: похоже, взяли просто самый популярный инструмент, Cursor, и лучшую на тот момент модель для кода — Claude версий 3.5–3.7, — и хотели померить руками, а не опросами и не изнутри организации, где CEO рассказывает про единорогов. Проверяли ассистентский режим, когда код пишет сам разработчик, а IDE помогает. Артём отвечает как менеджер: получив KPI доказать, что AI неэффективен, он взял бы столько же людей — шестнадцать или, он уже не помнит точно, девятнадцать, — заведомо объёмную кодовую базу и опытных разработчиков, которые её знают.

Александр продолжает эту фантазию: а тем, кто ассистентом раньше не пользовался, он бы купил инструмент и сказал — пользуйтесь, принуждаем вас. Артём оговаривается, что не факт, что всё было так, — он опирается на внешние сигналы; будь он менеджером этой команды, попросил бы контрольные группы на разных задачах и процессах. Дальше — разрыв оценок, из которого выросли заголовки: по пересказу Александра, те, кому ассистент был запрещён, отводили на задачу около двух часов и справлялись быстрее, а те, кому разрешён, рассчитывали на полтора часа, а тратили в среднем больше двух; доверительный интервал до нуля не доезжает. Артём видит здесь обычное искажение — оценивать задачи никто не умеет, мы все оптимисты — и хотел бы знать, был ли входной опрос про ожидания: верящий в ассистента занижает оценку, скептик завышает. Оговорок в пейпере много — есть даже отдельная табличка с тем, чего авторы не берутся доказывать, — а ожидания были совсем другими: экономисты закладывали ускорение на 40%. Но оговорок не читают: журналисты берут абстракт и делают новость «AI замедляет разработчиков».

Артём признаётся, что пятьдесят страниц не читал: закинул их в ChatGPT и поговорил с ним. Разметка видео позволила авторам поспекулировать о причинах: набралось порядка восемнадцати факторов, из которых самыми значимыми они считают около пяти. Это сверхоптимизм; знакомство инженера с репозиторием на миллион с лишним строк, который целиком в контекст не влезает; размер и сложность репозитория; низкое доверие к подсказкам у тех, кто раньше такими инструментами не пользовался; и неявные правила проекта — в open source их редко пишут для ассистента, инженер набивает их через раунды обратной связи на пул-реквесты, а теперь их приходится выносить в MD-файлы. Александр сравнивает такую постановку с матчем баскетболистов и футболистов по правилам одного вида спорта, а Артём напоминает: много времени уходило на вычистку неприменимых изменений, по его памяти применялось меньше 40% сгенерированного кода.

Полезнее всего, считает Артём, читать это менеджерам: в любой корпорации накоплена кодовая база, которую годами писали при приоритете сроков, а там, где разработка софта не профиль, легаси ещё больше — обещанного буста ассистент на нём не даст. Его давний тезис: проекты проваливаются на интеграциях и коммуникации, ведь контекст мы плохо передаём даже друг другу. Александр отвечает практикой из своего разбора интервью с Борисом Чёрным из Anthropic, создателем Claude Code: доверие выстраивают лестницей — сначала попросить рассказать про кодовую базу и сверить с тем, что знаешь, потом простые баги, потом средние задачи через отревьюенный план, и лишь затем сложные, где агент делает прототип, а работу драйвишь ты. Артём говорит, что это буквально онбординг нового разработчика. Итог ведущего: бенчмарк неплохой, но ему не хватает масштаба, а такую методологию интереснее раскатывать внутри больших компаний.