Тема 75 из 91· Ускорение с помощью ИИ
Продуктивность разработчиков с ИИ
Метрики того, что помощь ИИ в кодировании реально делает с инженерной производительностью: коэффициенты принятия предложений, ускорения в контролируемых исследованиях, пропускная способность PR и удержание кода. Доказательная база по-настоящему противоречива — что делает её идеальным примером для различия эффективности в теории и на практике, для работы с которым и создавалась экономика здравоохранения.
Почему это важно
Два наиболее цитируемых контролируемых исследования указывают в противоположных направлениях:
- Peng et al. 2023 (РКИ GitHub Copilot): разработчики завершили задачу по созданию HTTP-сервера с нуля на 55,8% быстрее с Copilot (1ч11м против 2ч41м, n=95).
- РКИ METR 2025: опытные разработчики открытого ПО, работающие над собственными зрелыми репозиториями, были на 19% медленнее с инструментами ИИ начала 2025 года (16 разработчиков, 246 задач) — при этом полагая, что они на 20% быстрее.
Оба исследования качественные. Противоречие и есть результат: эффективность на «чистой» задаче не переносится на эффективность в зрелой кодовой базе, а воспринимаемая польза не может заменить измеренную пользу. В медицине есть названия для обоих явлений (объяснительные против прагматических испытаний; проблема плацебо) и механизмы для работы с ними.
Расчёт
Коэффициент принятия = принятые предложения / показанные предложения
(телеметрия GitHub ~30% в среднем; варьируется: SQL 45%, Python 35%, JS 28%)
Коэффициент удержания = код ИИ, доживший до слияния / принятый код ИИ (~88% по отчётам)
Ускорение = (t_контроль − t_ИИ) / t_контроль (ТОЛЬКО из контролируемого сравнения)
Дельта пропускной способности = Δ слитых PR/разработчика/неделю (полевые данные GitHub/Accenture: +8,7%)
Модель ценности = разработчики × сэкономленное время × нагруженная ставка × коэффициент использования
— каждый член требует локального измерения; см. диаграмму-торнадо в
sensitivity-analysis.md, где сэкономленное время доминирует над
всеми остальными параметрами вместе взятыми
Разобранный пример
Организация из 500 разработчиков тестирует помощника с надлежащим контролем (сопоставленные команды, 3 месяца, предварительно зарегистрированные метрики):
Результат пилота: время цикла PR −18%; слитые PR +6%; ЧОИ без изменений;
самоотчёт о сэкономленном времени 45 мин/день; измеренный уровень задачи ≈ 15 мин/день
Оцените ИЗМЕРЕННУЮ цифру: 500 × 0,25ч × 220д × £60 × 0,6 использования
≈ £990 000/год мощности (не высвобождает наличные)
Стоимость: 500 × £39/мес × 12 ≈ £234 000/год
Коэффициент чистой мощности ≈ 4:1 — финансируемо, при трети от заявленного самоотчётом.
Трёхкратный разрыв между воспринимаемым и измеренным — это результат METR, действующий в реальности; составление бюджета на основе самоотчёта утроило бы строку выгоды.
Связь с программной инженерией
Импорт из экономики здравоохранения для всех, кто оценивает инструменты ИИ: проводите прагматичные испытания (ваша кодовая база, ваши инженеры, реальные тикеты — не демонстрационные задачи поставщика); относитесь к коэффициенту принятия как к косвенному показателю, а не результату (это ППЦ предложений с точки зрения разработчика — высокое принятие при низком удержании — это гипердиагностика); сочетайте каждый прирост пропускной способности с проверкой стабильности (DORA 2025: ИИ повышает пропускную способность, вредит стабильности — вмешательство с побочными эффектами требует анализа чистой выгоды, согласно метрикам DORA); и честно классифицируйте выгоду как мощность (высвобождающую наличные против не высвобождающей).
Подводные камни
- Пересадка исследований поставщика: цифры РКИ на чистых задачах, применённые к работе в устаревшей кодовой базе — именно та ошибка, которую разоблачило исследование METR.
- Самоотчёт как измерение: разрыв восприятия в 20 процентных пунктов — крупнейшее известное искажение в этой литературе.
- Инфляция активности: больше PR и больше кода — это Активность, а не результаты (SPACE); сочетайте с переделкой и ЧОИ.
- Игнорирование кривой обучения: измерения второй недели фиксируют эффекты новизны в любом направлении; измеряйте в устойчивом состоянии (временной горизонт).
Источники
- Peng S, et al. "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." 2023. https://arxiv.org/abs/2302.06590
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Отчёт DORA 2025. https://dora.dev/dora-report-2025/