[3/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Продолжим рассмотрение статьи про developer productivity (1 и 2) обсуждение независимых переменных, а также построением самой модели.

Независимые переменные
Авторы взяли в качестве гипотезы 42 независимые переменные, которые по их мнению могли влиять на продуктивность. Эти 42 переменные схлопнулись до 39 после проверки на мультиколлинеарность. Эти данные были доступны из логов и результатов опросов. Все эти переменные были разбиты на 6 категорий
1) Code quality & technical debt - эти факторы связаны с качеством кода и техническим долгом, которые дальше разбираются в деталях. Кстати дальше авторы написали отдельные интересные статьи
- "Developer productivity for Humans, Part 7: Software Quality" - статья про качество, которую я уже разбирал
- "Defining, measuring and managing technical debt" - которую я разбирал с Димой Гаевским в подкасте Research Insights Made Simple, а также разбирал в отдельной статье
2) Infrastructure tools & support - здесь история про выбор инструментов, а также работу инфраструктуры. Часть из этих факторов были разобраны отдельно
- "Build Latency, Predictability, and Developer Productivity" - статья про важность не просто build time, а его предсказуемости и как это влияет на продуктивность, о которой я уже рассказывал
3) Team communication - здесь авторы говорят про коммуникации, дистанцию от менеджеров, код ревью. Кое-что авторы из этого разобрали в дальнейших статьях
- "Developer Productivity for Humans, Part 2: Hybrid Productivity" - это статья про то, как удаленная работа и удаленные коммуникации во время COVID повлияли на продуктивностьЯ рассказывал про нее раньше
- "Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up" - это статья про то, как работает процесс онбординга и как на него повлиял COVID. Я рассказывал про нее раньше
4) Goals & priorities - это про ясность целей и про изменение приоритетов
5) Interruptions - здесь авторы замеряют влияние встреч
6) Organizational & process factors - проблемы из-за процессов, реорганизации и перемещения людей

Дальше авторы использовали квази-экспериментальный метод использования панельных данных для построения связи между воспринимаемой инженерами продуктивностью и независимыми переменными: 𝑦𝑖𝑡 =𝛼𝑖 +𝜆𝑡 +𝛽 * 𝐷𝑖𝑡 + 𝜖𝑖𝑡
Где
- 𝑦 - это самооценка продуктивности для инженера i в момент t
- 𝛼 - это независимые от времени необозреваемые параметры инженера, такие как образование или уровень навыков
- 𝜆 - это независимые от инженера эффекты от времени, например, изменение политики на всю компанию или сезонные эффекты (как январские каникулы в России)
- 𝐷𝑖𝑡 - это измеренные факторы продуктивности для инженера i в момент времени t
- 𝛽 - это причинно-следственныые эффекты факторов продуктивности 𝐷𝑖𝑡 в момент времени t
- 𝜖𝑖𝑡 - это ошибка во время t

Дальше авторы берут производную и получают формулу Δ𝑦𝑖𝑡 = Δ𝜆𝑡 + 𝛽 * Δ𝐷𝑖𝑡 + Δ𝜖𝑖𝑡 , где
- Δ𝜆𝑡 = 𝛾0 + 𝛾1 * 𝑇 и Δ означает разницу между соседними временными промежутками
- T - это категорийная переменная, что означает разницу между периодами
- после дифференцирования 𝛼𝑖 исчезает из уровнения, а Δ𝜆 можно явно контролировать, что говорит о том, что 𝛼𝑖 и 𝜆𝑡 не искажают результаты

Дальше авторы берут метод Feasible Generalized Least Squares (FGLS) и строят корреляции между зависимой и независимыми переменными и оценивают абсолютный эффект и статистическую значимость. Про результаты и ограничения исследования будет в последней части обзора.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

The Pragmatic Programmer: From Journeyman to Master (Программист-прагматик) (Рубрика #Engineering)

Достал тут очередную древнюю книгу с полки, чтобы вспомнить былое и рассказать как начинался для меня IT в начале 2000х годов. В этот раз речь пойдет про влиятельную книгу того времени, написанную Эндрю Хантом и Дэвидом Томасом в 1999. Основная мысль книги была о том, что программист должен быть прагматичным профессионалом, который постоянно совершенствуется, мыслит критически и ответственно относится к своему труду. Сейчас я бы сказал, что авторы пропагандируют здоровый инженерный подход, а не просто программирование. Интересно, что я уже рассказывал про книгу, но тогда фокусировался на своих записях из 2000х годов, а теперь решил поговорить про pragmatic programmer , ключевого персонажа, которого описывают авторы и который
- Заботится о качестве своего кода и принимает ответственность за свои решения (care about your craft) - ту есть отсылка к craft, а не engineering, в те времена были разные школы мысли о том, является ли программирование инженерной деятельностью или это скорее craftmanship (потом даже появился craftmanship manifesto для софта)
- Применяет принцип DRY (don't repeat yourself), избегая дублирования кода
- Использует автоматизацию для повышения эффективности разработки (automation)
- Регулярно тестирует код и применяет подходы вроде TDD (test-driven development)
- Постоянно обучается и адаптируется к изменениям технологий (по прошествии 25 лет я бы поставил этот пункт на первое место)
- Использует системы контроля версий (Version Control) как обязательную часть рабочего процесса
- Стремится к написанию понятного, легко поддерживаемого кода.
- Применяет техники отладки (debugging), такие как разговор с уточкой (rubber duck debugging)
- Следует принципам YAGNI ("You aren't gonna need it"), избегая излишней сложности
- Применяет подходы рефакторинга для улучшения структуры кода
В книге есть забавные истории про теорию разбитых окон ("broken windows theory"), о каменном супе ("stone soup") или супе из топора в русских сказках, а также метод отладки "резиновая уточка" ("rubber duck debugging").

Книга была издана чуть больше 25 лет назад и на тот момент она была чрезвычайно прогрессивной и новаторской - из описанного выше она ввела или популяризировала
- Принципы DRY, принци ортогональности (orthogonality) для декомпозиции системы на независимые компоненты (decoupling), важность рефакторинга
- Сфокусировала внимание на автоматизации процессов разработки и тестирования задолго до массового распространения CI/CD (Continuous Integration/Continuous Delivery) систем. Например, в то время многие компании не использовали даже VCS, не то что не писали тесты
- Сделала акцент на личной ответственности программиста за качество своего продукта, что было новаторским подходом на фоне тогдашних более формализованных методологий
- Предложила концепцию постоянного обучения и адаптации как неотъемлемой части профессионального роста разработчика задолго до того, как это стало общепринятым стандартом

P.S.
Интересно сравнивать то, что интересовало меня 20+ лет назад при прочтении книги и как я сейчас на нее смотрю с высоты опыта:)

#SelfDevelopment #Engineering #Software #SoftwareDevelopment #Management #Leadership

[4/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Закончим рассмотрение статьи про developer productivity (1, 2 и 3) и обсудим полученные авторами результаты.

Топ пять факторов, что получились после анализа содержали следующие факторы
- Project code quality (качество кода в проекте)
- Hindrance of shifting priorities (препятствия в изменении приоритетов)
- Technical debt in projects (технический долг в проектах)
- Innovation of infrastructure & tools (инновации в инфраструктуре и инструментах)
- Overall satisfaction with infra & tools (общая удовлетворенность инфраструктурой и инструментами)

Дальше авторы применили панельный анализ с запаздыванием. Суть в том, что они получили корреляцию между продуктивностью инженеров и факторами, что приведены выше, а хотелось бы получить более сильные результаты и понять направление связи. Для этого они выдвинули две гипотезы
1) QaP: изменения в качестве кода в момент T-1 коррелирует с изменениями в продуктивности инженеров во времени T. В виде формулы это выглядело так: Δ𝑃𝑖𝑡 = 𝛼 + 𝛽Δ𝑄𝑖𝑡−1 + Δ𝜖𝑖𝑡
2) PaQ: изменения в продуктивность в момент T-1 коррелирует с изменениями в качестве кода в момент T. В виде формулы это выглядело так: Δ𝑄𝑖𝑡 = 𝛼 + 𝛽Δ𝑃𝑖𝑡−1 + Δ𝜖𝑖𝑡
Оказалось, что первая гипотеза о том, что рост качества кода связан с повышением производительности подтверждается со следующей силой

We found that a 100% increase of satisfaction rating with project code quality (i.e. going from a rating of ‘Very dissatisfied’ to ‘Very sat- isfied’) at time T-1 was associated with a 10% decrease of median active coding time per CL, a 12% decrease of median wall-clock time from creating to mailing a CL, and a 22% decrease of median wall-clock time from submitting to deploying a CL at time T.

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

Отдельно надо рассказать про опасности для валидности этого эксперимента, которые описали авторы. Их всего 4
1) Content. Авторы измеряли продуктивность по ответу на один вопрос в проводимом EngSat опросе, что конечно не дает полной картины. Например, авторы отмечают, что этот вопрос был про индивидуальную продуктивность инженера, а не про эффективность команды. Примерно также не все факторы, что могут влиять на продуктивность были рассмотрены
2) Construct. Восприятие вопроса про продуктивность могло отличаться у респондентов. Например, кто-то мог думать о продуктивности в формате нафигачить быстро фичу, а кто-то учитывал разницу в качестве при создании фичи. Ну и там был еще ряд мест, где респонденты по разному могли воспринять сами вопросы
3) Internal. В этом исследовании авторы используют панельный анализ с запаздыванием, что эффективно предполагает, что эффекты на индивидуальных инженеров не зависят от времени. Например, у одного инженера сменился проект и команда, другому достался крутой ментов, у третьего что-то случилось в семье. Одновременно, могли бы быть проблемы, если какие-то категории инженеров систематически не участвовали в опросе, например, ветераны разработки или наоборот новички. Но авторы такие отклонения контролировали.
4) External. Весь эксперимент основывает только на опыте инженеров внутри Google, а значит может не иметь обобщающей силы на другие компании в индустрии.

Несмотря на все потенциальные проблемы, мне понравилось это исследование не только итоговым ответом на вопрос про то, что улучшает developer productivity в Google, но и самой методологией проведения эксперимента.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

AI и Platform Engineering (Рубрика #AI)

Интересное выступление Игоря Маслова, VP of Coretech & Data в Т-Банке, на открытии конференции Platform Engineering Night, про которую я уже рассказывал. Игорь открывал конференцию и рассказал о том, как AI влияет на работу инженеров и развитие инженерных платформ. Основные мысли выступления примерно следующие

1. AI как усилитель существующих платформ
Сейчас нужно "обмазывать" существующие инженерные сценарии AI - от создания пайплайнов до анализа телеметрии. В этом разрезе интересно глянуть whitepaper Google "Measuring Developer Goals", чтобы посмоттреть какие основные сценарии выделяет Google (я рассказывал о нем раньше), а также девятый выпуск "Research Insights Made Simple", в котором мы с коллегой Колей Бушковым разбирали whitepaper "What Do Developers Want From AI?" от ребят из Google
2. Когнитивная нагрузка и потеря навыков
Игорь отмечает, что активное использование AI приводит к потере низкоуровневых навыков, но считает это нормальной эволюцией - условно, мало кто пишет на ассемблере и большая часть инженеров его уже не понимает и это никого не смущает. Примерно также мы будем писать код с ассистентами на условной Java и часть людей без ассистентов его уже не смогут написать/прочитать:)
3. Режим "копайлота" как базовый уровень
Ответственность за финальный результат остаётся за человеком, что минимизирует риски "галлюцинаций" AI-моделей. Anthropic реализует эту философию в Claude, где модель действует как ассистент, а не замена разработчика. Такой подход особенно важен в критически важных системах, таких как финансы или здравоохранение, где ошибки AI недопустимы
4. Будущее: AI как платформенная инженерия
В долгосрочной перспективе AI может стать основным интерфейсом для управления инженерными процессами, устраняя необходимость в традиционных инструментах. Это направление напоминает эволюцию Kubernetes, который стал стандартом для оркестрации контейнеров, но для AI аналогичный "момент" ещё не наступил
5. Vibe Coding и персонализированный софт
Генерация кода под конкретные бизнес-кейсы или индивидуальные потребности пользователей — ключевой тренд. Однако, как предупреждает Игорь, подобные системы требуют тщательной валидации, чтобы избежать проблем с поддерживаемостью кода
6. Разгрузка разработчиков от рутины
80% экспериментальной работы можно автоматизировать, освободив время для более важных задач. OpenAI's Code Interpreter позволяет итеративно решать сложные задачи программирования и анализа данных.
7. ML-платформы: гибкость и готовность к изменениям
Инвестиции в ML-платформы оправданы, но требуют готовности к технологическим сдвигам. Например, переход от традиционных нейросетей к трансформерам в 2020-х потребовал полного пересмотра инфраструктуры у большого количества компаний. Спикер подчёркивает, что платформы должны сохранять модульность, чтобы адаптироваться к новым алгоритмам и аппаратным решениям
8. Отсутствие "момента Kubernetes" в AI
Пока нет универсального стандарта для AI-платформ, и стоит дождаться его появления. Каждая компания развивает свои подходы: OpenAI с Agents SDK, Anthropic с фокусом на безопасность, Google с комплексными AI решениями.
9. Высокорискованная природа current AI R&D
Современные AI-решения требуют больших ресурсов и подходят в основном крупным компаниям. Это подтверждается масштабными инвестициями OpenAI, Google и Microsoft в платформенные решения.
10. Постепенный подход к внедрению
Рекомендация: начинать с улучшения инструментов, но пока воздержаться от сложных low-code процессов. Anthropic следует схожей философии, предоставляя мощные модели с акцентом на контролируемое внедрение.

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

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

State of platform engineering in the age of AI (Рубрика #AI)

Интересный отчет конца 2024 года, который подготовлен компанией Red Hat совместно с исследовательским агентством Illuminas. Red Hat — мировой лидер в области корпоративных open source-решений, активно развивает платформенную инженерию и внедрение ИИ в инфраструктуру предприятий. Illuminas — опытная исследовательская компания, специализирующаяся на IT и B2B-рынках. Этот отчет построен на опросе 1000 инженеров платформ и IT-руководителей из США, Великобритании и стран Азиатско-Тихоокеанского региона.

Методология исследования была следующей
- Это был онлайн-опрос на 20 минут, где было 1000 респондентов (поровну инженеров и руководителей)
- 35% участников представляло средние компании, а 65% — крупные
- Участвовали сотрудники компаний из отраслей: IT, финансы, ритейл, здравоохранение, профессиональные сервисы
- География опроса: США, Великобритания, англоязычные страны APAC

Ключевые идеи и выводы опроса следующие
1. Платформенная инженерия становится стратегической
62% компаний уже имеют выделенные команды платформенной инженерии. Платформенная инженерия — это не просто автоматизация инфраструктуры, а стратегический инструмент для ускорения инноваций и внедрения ИИ.
2. Влияние искусственного интеллекта
76% организаций уже используют генеративный ИИ для задач разработки (документация, генерация кода, подсказки). 45% считают ИИ центральным элементом своей платформенной стратегии.
3. Модель зрелости платформенной инженерии
Red Hat выделяет 4 уровня зрелости:
- Exploring - исследование
- Emerging - начало внедрения
- Established - устоявшаяся практика
- Advanced - продвинутый уровень
Компании с высокой зрелостью достигают на 41% лучших результатов (по продуктивности, инновациям, безопасности).
4. Основные драйверы внедрения
- Безопасность
- Улучшение взаимодействия между командами
- Автоматизация и ускорение процессов
5. Эволюция инвестиций
- На ранних этапах — фокус на модернизации инфраструктуры (55%)
- На продвинутых этапах — автоматизация (85%), безопасность (59%), инструменты для разработчиков (55%)
6. Проблемы и вызовы
На всех уровнях зрелости сохраняются сложности с интеграцией рабочих процессов и рисками безопасности (по 37%).
- На ранних этапах — нехватка навыков и бюджета (40%)
- На продвинутых этапах — несовместимость инструментов, нестабильность платформ, дефицит знаний (около 30%)
7. Метрики успеха
Зрелые компании отслеживают больше показателей (в среднем 7), включая продуктивность, безопасность, производительность приложений, удовлетворённость разработчиков. На ранних этапах чаще фокус на снижении затрат.

Если подводить итоги отчета, то можно заключить, что
- Платформенная инженерия становится отдельной профессией, требующей новых навыков и командной структуры.
- Компании и вендоры должны интегрировать ИИ в платформенные решения, а не рассматривать ИИ как отдельный инструмент.
- Стандартизация архитектур и best practices ускоряет внедрение и снижает риски.
- Безопасность и автоматизация — ключевые приоритеты для будущего развития.

#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx

ArchDays 2025 - CFP (Рубрика #Architecture)

Этой осенью пройдет уже 7 ежегодная конференция ArchDays по software architecture. Я в программном комитете этой конференции с момента ее появления, поэтому не могу не поделиться стартом CFP (call for paper). Если вы хотите выступить на конференции и рассказать доклад об одной из тем: процессы проектирования, практики, инструменты, обучение архитектуре или про собственную разработку, то you are welcome. В этом году, как и в прошлом у нас упор на практику - можно подать заявку на проведение арх каты, порешать арх кейсы или подискутировать насчет разных концепций архитектуры.

В общем, если планируете стать спикером, то вам сюда.
А если вы планируете прийти послушать, то уже можно покупать билеты:)

P.S.
Я выступал на всех предыдущих конференциях ArchDays, что были до этого с разными докладами на тему архитектуры. По ним даже можно отследить как менялась архитектурная повестка у нас в компании:)
1) "Эволюция web’а tinkoff.ru за последние 3 года" в 2019 (youtube)
2) "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" в 2020 (youtube, статья с расшифровкой)
3) "System Design Interview как проверка навыков проектирования систем на собеседованиях" в 2021 (youtube, статья с расшифровкой)
4) "Как подготовиться и пройти System Design Interview" в 2022 (youtube, статья с расшифровкой)
5) "Публичное интервью по System Design про бронирование отелей" в 2022 (youtube, статья с расшифровкой)
6) "Публичное интервью по System Design про простую a/b платформу" в 2023 (youtube)
7) "Архитектура в Т-Банке: вчера, сегодня, завтра" в 2024 (youtube, статья с расшифровкой)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

Research Insights Made Simple #10 - Measuring Developer Experience With a Longitudinal Survey (Рубрика #DevEx)

Очередной выпуск подкаста с разбором whitepapers посвящен разбору темы проведения опросов инженеров "Measuring Developer Experience With a Longitudinal Survey". Для разбора этой статьи ко мне пришел гость, Артем Арюткин, руководитель проектного и продуктового офиса в RideTech & e-com Яндекса. Артем отвечает за развитие платформы для разработчиков, а раньше в Сбере занимался развитие платформы Сбербанк онлайн и рекомендательной платформы. Артем ведет интересный телеграм канал - https://t.me/badTechProject

За 40 минут мы успели обсудить следующие темы

- Опыт Google в проведении опросов
- Преимущества и процесс проведения опросов
- Методология и анализ опросов
- Важность коммуникации и внедрения изменений по итогам опросов
- Роль менеджера и сменяемость ролей в команде
- Масштабирование и частота опросов
- Продуктовый подход и интеграция онлайн-опросов
- Двухсторонний анализ: опросы и логи

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
Я разбирал этот whitepaper раньше в своем tg канале в двух частях: 1 и 2

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

Круглый стол «Техлид и развитие в Individual Contributor: как превратить код в карьеру» (Рубрика #Engineering)

Сегодня буду в рамках круглого стола на Techlead Conf X обсуждать этот вопрос с джентельменами из разных компаний, где у нас соберется квартет представленный ниже
- Максим Вишневский, ведущий (Mindbox)
- Глеб Михеев (Сбер)
- Александр Белотуркин (Делимобиль)
- Александр Поломодов (Т-Банк)

И вместе мы точно поговорим про то
- Как роль техлида влияет на бизнес: от компаний с развитой IC-веткой до тех, где влияние минимально?
- Какие навыки и подходы нужны техлиду в бизнесе, архитектуре и технической экспертизе, а также как расти по IC-ветке?
- Почему в российском IT IC-ветка слабо развита и какие перспективы для роста?
- Как формируется роль техлида в разных компаниях, почему она часто остается неофициальной и как развивать навыки без продуктового контекста?

Думаю, что мне будет, что добавить к этой дискуссии, так как раньше я уже много рассказывал на эту тему
- Code of Leadership #6 Staff+ инженеры, архитектура и SDLC
- Варианты роста инженера, если он уже Senior на Tinkoff Meetup 2023
- Как нанимать технических руководителей на Teamlead Conf 2023
- Архитектура в масштабе на ArchDays 2020
- System Design Interview на ArchDays 2021
- Как подготовиться и пройти System Design Interview на ArchDays 2022
- Книга Will Larson "Staff Engineer" и мои обзоры этой книги в двух частях: 1 и 2
- Книга Tanya Reilly "The Staff Engineer's Path" (перевод этой книги есть в издательстве Питер под названием "Карьера разработчика. Стафф - круче, чем senior")

#Staff #SoftwareDevelopment #Software #SelfDevelopment #Career

Research Insights Made Simple #11 - Measuring AI Code Assistants and Agents (Рубрика #DevEx)

Очередной выпуск подкаста с разбором whitepaper "Measuring AI Code Assistants and Agents" посвящен разбору измерения эффекта от AI в разработке. Этот отчет интересен, так как ребята из DX являются одними из законодателей мод в мире developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health.

За полчаса мы разобрали whitepaper и осудили темы
- Платформа DX и оценка влияния кодовых ассистентов и агентов на продуктивность инженеров
- Структура фреймворка DX: этапы зрелости, метрики и риски неправильного внедрения
- Оценка adoption и утилизации
- Оценка импакта и метрики
- Коммуникация внедрения метрик в разработку
- Обсуждение фреймворков DORA, SPACE, DevEx, DX Core 4 для измерения эффективности продуктивности инженеров в общем

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
Я разбирал этот whitepaper раньше в своем tg канале раньше.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes #AI #Agents

[1/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)

Я достаточно оперативно познакомился с этим whitepaper, где показано замедление разработчиков при использовании AI. Но изначально я не хотел про него писать - методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Но я поменял свое мнение после того, как посыпались заголовки в стиле "Учёный изнасиловал журналиста" и дальше падкие на громкие заголовки люди начали присылать это исследование с аргументацией "вот они доказательства: усы, лапы и хвост".

После этого я пошел и прочитал не только краткую выжимку с сайта METR (Model Evaluation & Threat Research), но и все 50 страниц основного whitepaper, где авторы описали всю методологию эксперимента, свои мысли о результатах и их причинах (конечно, без стат значимости) и даже инструкции для участников экспериментов. Дальше я поделюсь своими мыслями насчет этого эксперимента.

Начнем с того, почему это исследование получило столько внимания и тут есть несколько причин
1. Противоречие общепринятому мнению
Результаты исследования прямо противоречат широко распространенному убеждению о том, что AI-инструменты неизбежно повышают продуктивность разработчиков. Исследование показало, что AI-инструменты фактически замедляют опытных разработчиков на 19%, что стало шокирующим открытием даже для самих авторов.
2. Методологическая точность
Авторы провели исследование используя рандомизированные контролируемые испытания (фактически, a/b тест) для оценки реального влияния AI на продуктивность разработчиков в их обычной рабочей среде. Исследование отличается от предыдущих работ использованием фиксированных задач и опытных разработчиков, работающих в знакомых кодовых базах. Правда, тут участники знали про сам эксперимент, а значит мог проявляться эффект Хоторна
3. Актуальность для индустрии
Результаты исследований про влияние AI имеют огромное значение для оценки многомиллиардных инвестиций в AI-инструменты для разработки. Предыдущие исследования по другому подходили к оценке эффекта и все поголовно показывали увеличение продуктивности. А это исследование поднимает вопросы о реальной окупаемости инвестиций в AI-инструменты разработки.

Продолжим тем, а почему нам стоит доверять исследователям из METR.
Начать надо с того, что METR - это некоммерческая исследовательская организация, специализирующаяся на оценке возможностей фронтирных AI-систем и их потенциальных рисков. Организация работает с ведущими AI-компаниями, включая OpenAI и Anthropic, и сотрудничает с государственными институтами AI-безопасности. В группу исследователей входили технические сотрудники Joel Becker, Nate Rush, David Rein, а также Beth Barnes - основатель и главный исследователь METR, бывший исследователь OpenAI и DeepMind, ведущий эксперт по AI-безопасности и оценке AI-систем.

И как же выглядела методология рандомизированных контролируемых испытаний?
- Участвовали 16 опытных разработчиков open-source проектов со средним опытом работы с репозиториями 5 лет и 1500 коммитов в среднем.
- Решали они 246 реальных задач из крупных open-source репозиториев (в среднем 23,000 звезд, 1,100,000 строк кода).
- Дизайн эксперимента предполагал, что каждая задача случайным образом назначалась в одну из двух групп
-- AI-разрешенная группа: разработчики могли использовать любые AI-инструменты (преимущественно Cursor Pro с Claude 3.5/3.7 Sonnet)
-- AI-запрещенная группа: использование генеративного AI запрещено
- Измерялось время выполнения задачи, что разработчики отслеживали самостоятельно. Дополнительно собирались записи экрана, интервью и детальная аналитика использования AI.
- Помимо этого все задачи проходили стандартный процесс code review и должны были соответствовать высоким стандартам качества репозиториев.

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

#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes