Восемь мифов о генеративном ИИ в разработке ПО
Генеративный ИИ перестраивает разработку ПО, но нарратив опережает факты. Маркетинговые обещания, отдельные истории успеха и неверно прочитанные исследования породили устойчивые мифы, которые мешают организациям принимать взвешенные решения об ИИ, инструментах и метриках успеха. Исследователи Microsoft и университета Виктории — Дженна Батлер, Брайан Хоук, Маргарет-Энн Стори, Трэвис Лоудермилк, Стивен Кларк и Эмерсон Мерфи-Хилл — разбирают восемь самых живучих заблуждений, опираясь на крупные исследования, интервью и полевые наблюдения.
Миф 1. Разработчики большую часть времени пишут код
Разработка ПО — это не только написание кода, но и дизайн, встречи, планирование, код-ревью. Исследования раз за разом показывают, что кодинг занимает меньшую часть рабочего дня.
Исследование 2025 года среди более чем 450 инженеров Microsoft показало, что на написание кода уходит лишь 14% времени. Другие исследования дают похожие цифры: в «хороший» день инженеры тратят на кодинг 18% времени, в «плохой» — всего 11%. Граница между хорошим и плохим днём оказывается крайне тонкой.
Один из разработчиков в исследовании Microsoft сформулировал это так: «На моём уровне много времени уходит на дизайн. Кодинг — это один из аспектов, но много времени занимают дизайн и встречи. Количество времени, которое я трачу на написание кода, довольно невелико в течение недели».
Миф 2. Написание кода — узкое место
Если разработчики тратят лишь около 15% времени на набор текста в редакторе, то даже ИИ, который ускоряет кодинг вдвое, теоретически повысит общую продуктивность менее чем на 15%. Остальные 85% рабочего времени остаются нетронутыми.
Ускорение написания кода без решения смежных задач — дизайна, разбора легаси-кода, настройки окружений — приводит к неожиданным последствиям. Если ИИ позволяет генерировать код быстрее, давление просто смещается вниз по конвейеру: больше кода нужно ревьюить, тестировать и интегрировать.
Цикл разработки настолько быстр, насколько быстра его самая медленная фаза, и кодинг часто не является этой фазой. ИИ в роли простого генератора кода улучшает «внутренний цикл» работы в IDE, но почти не меняет «внешний цикл» разработки. Как заметил один из участников исследования: «Количество точек в моей работе, которых вообще касается GitHub Copilot, относительно невелико».
Миф 3. Строки кода, написанные ИИ, — лучшая метрика влияния
Билл Гейтс сравнивал измерение продуктивности строками кода с оценкой прогресса самолёта по его весу. Ещё в 2014 году статистическое исследование показало, что метрика строк кода «не проходит проверку на валидность и имеет ограниченную полезность». Несмотря на это, многие организации продолжают ей пользоваться, а с приходом ИИ метрика эволюционировала в подсчёт «строк кода, сгенерированных ИИ».
Строки кода, как и другие одиночные метрики вроде стори-поинтов, не являются ни статистически валидными, ни осмысленными индикаторами влияния. Хуже того, они стимулируют «игру в цифры»: под давлением метрики объёма разработчики жертвуют качеством дизайна, что ведёт к росту технического долга и уязвимостей.
Ирония в том, что усилия по ускорению кодинга через ИИ-генерацию усиливают давние проблемы: больше кода — больше работы по ревью, тестированию и поддержке. Цель инженерных компаний — не максимизация объёма кода, и оценка влияния ИИ должна это отражать: доставлять безопасное, поддерживаемое и качественное ПО.
Миф 4. ИИ помогает всем задачам и разработчикам одинаково
Результаты исследований GenAI-инструментов противоречивы: одни находят значительный рост продуктивности, другие — нейтральный эффект, третьи — даже негативный. Причина в том, что успех зависит от множества факторов: природы задачи и навыков разработчика.
Отчёт Microsoft 2024 года показал, что для знакомых и хорошо понятых задач Copilot даёт больший прирост эффективности, чем для незнакомых. Опыт разработки и опыт работы с ИИ также влияют на результат. При этом годы профессионального опыта отрицательно коррелируют с уверенностью в написании эффективных промптов.
В открытом исходном коде исследование 2025 года обнаружило, что ИИ-инструменты в среднем увеличили время реализации на 18%. GenAI эффективнее для «кодо-интенсивных» задач — бойлерплейта и повторяющейся работы, но не для творческих или коллаборативных. Даже формулировка промпта имеет значение: одно исследование показало, что переписывание семантически эквивалентного промпта меняло код в 46% случаев, а корректность — в 28%.
Миф 5. ИИ превратит каждого в 10x-разработчика
Устойчивый нарратив о том, что Copilot и аналоги сделают из индивидуальных разработчиков «10x-инженеров», игнорирует коллаборативную природу реальной разработки. Контролируемые исследования с изолированными задачами показывают впечатляющий прирост, но такие результаты редко переносятся в сложную командную среду.
Знаменитый «прирост в 55%» контекстозависим. Замеры продуктивности в изоляции не учитывают координацию, коллаборацию и обмен знаниями — то, без чего невозможна успешная поставка ПО. Многое из различий в результативности разработчиков объясняется конкретной задачей: один инженер может превосходить другого в одной задаче, но не стабильно во всех.
Миф 6. ИИ должен «сработать» у каждого разработчика
Большинство исследований рассматривает отдельного инженера с GenAI-инструментом, перекладывая бремя роста продуктивности на самого разработчика. Исторически же прирост продуктивности давали не изменения на индивидуальном уровне, а системные изменения на уровне организации.
Кэл Ньюпорт в New Yorker сформулировал это точно: «Исторически оптимизация систем для повышения продуктивности была исключительно сложной. Конвейер не возник из внезапного озарения. Форд прошёл через множество неудачных попыток и итераций. Теперь мы небрежно просим отдельных работников умственного труда проделывать подобные оптимизации собственных фабрик — одновременно со всей работой, которую они пытаются упорядочить».
Инструменты часто внедрялись без минимального руководства. GenAI, возможно, первая технология, в лицензии которой организации вложили миллионы, не понимая, как извлечь из неё максимум. Отсутствие драматичного роста продуктивности говорит о том, что одного доступа недостаточно: нужно пересматривать системы и процессы разработки на организационном уровне.
Миф 7. Хорошие ИИ-инструменты приживутся автоматически
Предположение, что инженеры примут ИИ-инструменты просто потому, что те улучшают результаты, игнорирует социальные, организационные и когнитивные барьеры.
Исследования показывают «штраф за компетентность»: разработчики — особенно женщины и старшие инженеры — получают более строгие оценки за работу с ИИ, даже когда результат идентичен. Доверие тоже проблема: 80% разработчиков пользуются инструментами, но лишь 29% доверяют их точности, и многие тратят больше времени на отладку ИИ-вывода, чем на написание кода.
Инструменты часто плохо встраиваются в существующие рабочие процессы, а у разработчиков нет ни времени, ни организационной поддержки на их изучение. Этические опасения — от влияния на экологию до происхождения обучающих данных — соседствуют со страхом потери навыков. Принятие — это не только качество инструмента, но и доверие, контекст и человеческий опыт работы.
Миф 8. С GenAI энтерпрайз будет инновировать со скоростью стартапа
Стартапы строят на открытых компонентах и документированных фреймворках, которые хорошо представлены в обучающих данных LLM. Энтерпрайз-системы опираются на проприетарные инструменты и легаси-код, которых модели никогда не видели. Плюс к этому — требования соответствия, безопасности, приватности и регулирования, применимые только в масштабе.
GenAI лучше всего работает в greenfield-сценариях, тогда как энтерпрайз-ПО обязано сохранять обратную совместимость и интегрироваться с тысячами внутренних систем. Цели тоже различаются: стартапы оптимизируют скорость до MVP и быстрые итерации, энтерпрайз балансирует скорость с надёжностью, безопасностью и контрактными обязательствами. Стартапы могут выпускать сырые альфа-версии, энтерпрайз-клиенты ожидают отполированных production-ready решений. Скорость видна, сложность — нет.
Вывод
Мифы об ИИ в разработке показывают, насколько сложно влияние генеративного ИИ на инженерию. Инструменты ускоряют отдельные задачи, но их преимущества часто преувеличены или поняты неверно — особенно когда речь о том, как разработчики реально проводят время, что такое продуктивность и как улучшение одной части процесса создаёт новые вызовы в других.
Контекст имеет значение: тип задачи, опыт разработчика, динамика команды и организационные системы формируют исход внедрения ИИ. Строки кода и скорость — плохие прокси реального прогресса. Полная ценность ИИ реализуется не через хайп и упрощённые метрики, а через фокус на более широких целях: безопасном, поддерживаемом и качественном ПО.