Про AI-ускорение рутины разработчиков, которого... НЕТ! ч.5: свежие рандомизированные контролируемые исследования (РКИ) и не только.Покопался в актуальных исследованиях, отделил всякие опросы и ангажированные репорты от РКИ, выбрал только актуальные, за полгода-год. Вот, что получается:
1️⃣ Самая известная работа METR (
пост), которая показала прирост +20% по ощущениям и -20% по факту, получила странную попытку репликации (
фев'26) от тех же авторов: взяли больше разрабов (57), понизили ставку ($50/час), получили +18% AI-ускорения для 10 участников из прошлой работы и +4% для 47 новых. Но до половины разработчиков отказались от неAI задач (??!!) и организаторы посчитали результаты ненадежными.
Непонятно, почему самая известная работа по теме так и не получила нормального продолжения, с актуальными инструментами. Есть интересный
разбор второго исследования на lesswrong. tldr: "ничего непонятно".
2️⃣ "How AI Impacts Skill Formation" (
фев'26): РКИ про обучение новой python-библиотеке - участники случайно делали задачу либо с AI-помощником, поиском и инструкциями, либо только с поиском и инструкциями. AI не дал статистически значимого ускорения по времени задачи, но результат теста на понимание упал на 17% (vs контроль без AI).
Другими словами, AI помогает сделать задачу, но может мешать понять, что сделано. Особенно опасно для джунов и для ситуаций, где потом надо самому поддерживать код. Есть еще работа с такими же выводами (
мар'26).
3️⃣ Echoes of AI (
фев'26), проверяли влияние AI на поддержку кода: разработчик добавлял фичу в Java/Spring Boot проект (с AI или без AI), другой разработчик получал решение и вручную его дорабатывал.
Первые сделали задачу на 30% быстрее (и аж 56% для power AI-юзеров), а у вторых при поддержке кода был большой разброс от -45% до +33%, и в среднем весь прирост пропадал.
4️⃣ Не РКИ, но интересная работа (
янв'26): американские разработчики в SAP несколько дней сдавали анкеты, записи экрана/мыши/клавиатуры, физиологические данные с браслета. В контролируемых сессиях были задачи на Java: кодинг, дебаг, документация, unit-тесты, мозговой штурм и др.
Выводы кратко:
• Умеренное использование AI сокращало время выполнения задач, но избыточное - мешало.
• Когда разработчик начинает постоянно переключаться между кодом, подсказками, чатом и проверкой ответов, то продуктивность падает.
• Лучше выглядели сценарии, где было взаимодействие с чатом. Вероятно, потому что чат лучше подходит для объяснений, проверки логики и задач, где нужно понять контекст.
• AI одновременно воспринимался как повышающий и продуктивность, и когнитивную нагрузку.
5️⃣ Тоже не идеальная "Speed at the Cost of Quality" (
ноя'25): как влияет AI кодинг на дистанции в месяцы.
tldr: главный вывод авторы вынесли в название работы - AI резко ускоряет разработку в краткосрочной перспективе, но одновременно увеличивает технический долг и сложность кода, что потом начинает тормозить проект.
Добавленные строки выросли на +281% в первом месяце и +48% во 2-м, к 3-му месяцу вернулись к базовой линии. По коммитам аналогичный паттерн +55%/+14%.
Рост накопленной сложности на 100% вызывает падение будущей скорости на 65%, создавая самоусиливающийся цикл технического долга.
Устойчивая деградация качества: +30% предупреждений статического анализа и +41% когнитивной сложности, удерживается на горизонте наблюдения и переживает контроль на динамику скорости. То есть AI-код внутренне более сложен, а не просто более многочислен.
6️⃣ На самом деле свежих качественных работ я найти больше не смог - остальное что-то странное, ангажированное или устаревшее.
Очевидно, что в каких-то частях разработки AI может дать буст, особенно для коротких циклов, крошечных команд и джуниоров. Но этот буст скромный, а не 10х (как нам многие обещают). Массовых увольнений инженеров из-за этого тоже не будет.
А я еще три года назад писал (раз, два, три), что AI изобретен, и наша задача - искать те редкие части своей работы, где AI реально помогает! @kyrillic 
ПредысторияУ нас в airflow есть много дагов, которые качают данные из бд. Чтобы не положить базу, мы используем пулы, которые ограничивают количество подключенийКак-то мы реализовали новый тип загрузки и, как порядочные разрабы, про пулы тоже не забыли. Долгое время данные грузились, все работало — с этой стороны не было проблем. Но однажды к нам пришел аналитик и спросил, почему таски висят в статусе scheduled по несколько часов. И вот тогда мы поняли 
И когда загрузчик требовал много слотов, абсолютно все простаивало, потому что больше ничего не помещалось
@data_engineerette
