Восемь мифов о продуктивности с GenAI в разработке ПО: что показывают исследования

ACM Queue опубликовал аналитический материал о том, что маркетинговые заявления, единичные истории успеха и неверно прочитанные исследования породили набор устойчивых мифов о генеративном ИИ в разработке ПО, и эти мифы уже влияют на решения компаний о внедрении инструментов и на то, как измеряется их эффект. Автор опирается на крупные исследования, интервью и полевые наблюдения; из доступного текста разобраны первые три мифа из заявленных восьми.

Первый миф, что разработчики большую часть времени пишут код, поэтому ИИ-генерация кода даёт основной прирост продуктивности. Исследование Microsoft 2025 года, охватившее более 450 инженеров, показало: на написание кода уходит лишь 14% рабочего времени. Более ранние исследования давали похожую картину: в «хороший» рабочий день на кодинг уходило 18% времени, в «плохой», 11%. В интервью Microsoft за июнь 2025 года один из разработчиков описал это так: «Для меня, на моём уровне, много времени уходит на проектирование. Кодинг, это [лишь] один аспект, а много времени уходит на проектирование и встречи»; и добавил, что доля времени, «затронутая» GitHub Copilot, в его работе относительно мала. Отсюда следует практический вывод автора: если на написание кода уходит около 15% времени, то даже ИИ-ассистент, ускоряющий сам процесс кодинга вдвое, теоретически повысит общую продуктивность разработчика менее чем на 15%, остальные 85% рабочего времени остаются незатронутыми. Более того, ускорение написания кода без изменения соседних процессов (проектирование, разбор легаси-кода, настройка окружения) может просто сдвинуть нагрузку вниз по цепочке: больше кода, значит больше кода, который нужно ревьюить, тестировать и интегрировать, а весь цикл разработки не быстрее своей самой медленной стадии.

Второй миф, что строки написанного кода (в том числе сгенерированные ИИ), валидная метрика продуктивности. Автор цитирует Билла Гейтса: «Измерять продуктивность разработки строками кода, всё равно что измерять прогресс самолёта по тому, сколько он весит». Ещё в 2014 году статистическое исследование валидности метрики «строки кода» пришло к выводу, что она не проходит проверку на валидность и потому имеет ограниченную пользу. Несмотря на это, компании, включая Microsoft, продолжают публично отчитываться о числе строк кода, сгенерированных ИИ. Автор предупреждает: такие метрики (как и другие однозначные показатели вроде story points) не только статистически некорректны, но и стимулируют команды «играть» с системой, разрушают доверие разработчиков, толкают их жертвовать качеством проектирования ради объёма кода, а это ведёт к росту технического долга и уязвимостей.

Третий миф, что ИИ-инструменты вроде GitHub Copilot превращают рядовых разработчиков в «10x-разработчиков», кратно умножая их продуктивность. Автор указывает, что исследования дают противоречивые результаты: часть работ фиксирует большой прирост продуктивности, часть, нейтральный эффект, а одно недавнее исследование обнаружило даже отрицательный эффект. Так, исследование 2025 года среди опытных разработчиков открытого ПО показало, что использование ИИ-инструментов в среднем увеличивало время реализации задачи на 18%, то есть замедляло работу. Другое исследование показало, что переформулировка промпта с сохранением того же смысла в 46% случаев приводила к другому сгенерированному коду и в 28% случаев, к изменению его корректности. Часто цитируемая цифра «прирост продуктивности на 55%» контекстно-зависима и не универсальна. Отчёт Microsoft за 2024 год об ИИ и продуктивности показал, что более крупный выигрыш от Copilot дают знакомые, хорошо понятные задачи, а также что опыт использования ИИ и опыт разработки в целом влияют на успех; при этом чем больше у разработчика профессионального опыта, тем ниже его уверенность в написании эффективных промптов. Автор приводит цитату профессора Джорджтаунского университета Кэла Ньюпорта из его статьи в The New Yorker: «Исторически оптимизация систем ради роста продуктивности была крайне сложной задачей. Конвейер не появился как внезапное озарение, Форд прошёл через множество неудачных попыток и постепенных экспериментов, вложил значительные деньги и разработал новые инструменты… Теперь же мы буднично просим отдельных интеллектуальных работников проводить столь же сложную оптимизацию их собственных «фабрик», и делать это одновременно с той самой работой, которую они пытаются оптимизировать». Вывод автора: продуктивность ИИ в разработке сильно зависит от контекста, характера задачи, опыта разработчика, знакомства с кодовой базой и качества промптов, и универсальной формулы успеха не существует; выигрыш обычно приходит не от раздачи лицензий отдельным инженерам, а от системных изменений на уровне организации.

Ключевые факты

Исследование Microsoft 2025 года (450+ инженеров): на написание кода уходит лишь 14% рабочего времени, поэтому даже удвоение скорости кодинга с помощью ИИ теоретически даёт прирост общей продуктивности менее 15%
Метрика «строки кода», в том числе сгенерированные ИИ, статистически невалидна (исследование 2014 года) и стимулирует «игру с системой», рост технического долга и уязвимостей
Исследование 2025 года среди опытных разработчиков открытого ПО показало, что ИИ-инструменты в среднем УВЕЛИЧИВАЛИ время реализации задачи на 18%, а не сокращали его
Переформулировка промпта с тем же смыслом в 46% случаев меняла сгенерированный код и в 28% случаев, его корректность
Миф о «10x-разработчике» не подтверждается: результаты исследований противоречивы (от заметного прироста до нейтрального и даже отрицательного эффекта), выигрыш сильно зависит от задачи, опыта и контекста

Почему это важно

Компании принимают решения о закупке ИИ-инструментов, найме и метриках эффективности на основе маркетинговых заявлений и единичных историй успеха, которые обогнали реальную доказательную базу. Автор показывает, что распространённые допущения, «код это главное», «строки кода = продуктивность», «ИИ делает каждого 10x-разработчиком», не подтверждаются крупными исследованиями, а иногда прямо им противоречат.

Кому это важно

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

Как это применить

Отказаться от подсчёта строк кода (в том числе сгенерированных ИИ) и story points как мерила продуктивности; оценивать эффект по итоговым результатам, качеству, скорости поставки, техдолгу. Учитывать, что кодинг, это малая часть рабочего дня разработчика (около 14, 18%), поэтому ускорение кодинга без пересмотра соседних процессов (проектирование, ревью, тестирование) может просто сдвинуть узкое место дальше по цепочке. Ожидать реальный прирост продуктивности не от массовой раздачи лицензий, а от системных изменений процессов на уровне организации и от подбора задач, где ИИ действительно эффективен (шаблонная, повторяющаяся работа), а не творческих и совместных задач.

Можно ли доверять

Материал опубликован в ACM Queue, рецензируемом практическом издании ACM, и опирается на конкретные названные исследования: исследование Microsoft 2025 года на 450+ инженерах, статистическое исследование валидности метрики «строки кода» 2014 года, отчёт Microsoft 2024 года об ИИ и продуктивности, исследование 2025 года среди разработчиков open source и исследование о влиянии переформулировки промптов. Цитаты Билла Гейтса и профессора Кэла Ньюпорта атрибутированы напрямую. Доступный для пересказа текст обрывается на переходе к четвёртому мифу, из заявленных восьми в источнике разобраны первые три; дальнейшие мифы в этом пересказе не описываются, чтобы не додумывать содержание статьи.

Риски и подводные камни

Компании, которые продолжают отчитываться числом строк кода, сгенерированных ИИ, рискуют стимулировать «игру с метрикой»: разработчики наращивают объём кода в ущерб качеству проектирования, что ведёт к росту технического долга и уязвимостей и подрывает доверие команды к руководству. Отдельный риск, переносить результаты контролируемых экспериментов на изолированных задачах на реальную командную разработку: исследование по open source прямо показало, что ИИ-инструменты могут не ускорять, а замедлять опытных разработчиков.

«Измерять продуктивность разработки строками кода, всё равно что измерять прогресс самолёта по тому, сколько он весит.»

— Билл Гейтс