Восемь мифов об ИИ в разработке ПО

Генеративный ИИ (GenAI) переделывает разработку ПО быстрее, чем исследования успевают поймать эффект, а организации — осмыслить практику. В этом разрыве и расплодились мифы: маркетинговые обещания, единичные успехи и неверно прочитанные исследования срослись в набор устойчивых заблуждений, которые потихоньку диктуют плохие решения — про внедрение инструментов, про то, как их выбирать, и про то, чем считать успех.

Эта статья — разбор восьми самых живучих мифов об ИИ в инженерии ПО, с опорой на масштабные исследования Microsoft, интервью с разработчиками и полевые наблюдения. Цель — не скепсис ради скепсиса, а рабочая, подкреплённая данными картина, чтобы решения об ИИ опирались на факты, а не на воодушевление. Материал основан на статье Jenna Butler, Brian Houck, Margaret-Anne Storey и др. «Eight Myths on Software Engineering and GenAI» (ACM Queue, май 2026), написанной по результатам исследования более 450 инженеров Microsoft.

Откуда растут мифы #

Большинство мифов об ИИ в разработке растут из одной и той же ошибки: индивидуальный, изолированный эффект инструмента принимают за системный эффект на команду и процесс. «Разработчик с Copilot пишет тест за полцены времени» — измеримый факт. «Команда с Copilot вдвое быстрее релизит» — уже спекуляция, потому что между клавиатурой и релизом стоят ревью, тестирование, интеграция, координация и legacy. Каждое из исследований ниже фиксирует именно этот разрыв: локальный выигрыш есть, а на уровне цикла поставки он либо тает, либо проявляется совсем не там, где ждали.

Ключевая работа, на которую опирается разбор — исследование распределения времени 450+ инженеров Microsoft (2025). Его базовый, но постоянно забываемый вывод: разработчики проводят за написанием кода лишь около 14 % рабочего времени. Всё остальное — это дизайн, встречи, планирование, ревью, понимание чужого кода, настройка окружения. Пока этот факт не уложен в голове, разговоры про «ускорение разработки ИИ-инструментами» неизбежно скатываются в мифологию.

Восемь мифов #

Миф 1. Разработчики проводят большую часть времени за написанием кода #

Это базовый миф, на котором стоят почти все остальные. Если он кажется вам очевидным — отлично, но индустрия в целом всё ещё действует так, будто кодинг занимает львиную долю рабочего дня инженера.

Исследование Microsoft 2025 года показывает: разработчики тратят на написание кода лишь около 14 % времени. Более ранние работы дают тот же порядок: на «хороший» рабочий день уходило около 18 % времени на кодинг (не считая фикса багов и тестирования), на «плохой» — всего 11 %. Маржа между хорошим и плохим днём — единицы процентов.

Один из разработчиков в исследовании использования ИИ (Microsoft, июнь 2025) сформулировал это так: «Для меня, на моём уровне, много времени уходит на дизайн. Кодинг — это один из аспектов, но много времени занимает дизайн и встречи». И ещё: «Есть верхняя граница того, какую долю моей работы я могу на это потратить… реальное количество времени на кодинг за неделю ощущается довольно небольшим».

Вывод: инструменты, ускоряющие только написание кода, по определению касаются малой части рабочего времени инженера. Это не делает их бесполезными, но задаёт верхнюю границу их вклада.

Миф 2. Написание кода — главное узкое место #

Если кодинг занимает лишь ~14–15 % времени, то даже двукратное ускорение этой фазы теоретически даёт менее 15 % общего прироста продуктивности. Остальные 85 % рабочего времени — дизайн, понимание legacy, настройка окружения, встречи, ревью — остаются нетронутыми.

Хуже того: ускорение создания кода без перестройки окружающих задач часто просто сдвигает давление вниз по потоку. Больше кода, написанного быстрее, означает больше кода, который нужно ревьюить, тестировать и интегрировать. Цикл разработки быстрее своего самого медленного этапа, и кодинг редко им является. Поэтому ИИ, используемый в первую очередь как генератор кода, ускоряет «внутренний цикл» (inner loop) работы в IDE, но почти не меняет «внешний цикл» (outer loop) — а именно он и определяет скорость поставки.

Тот же разработчик: «Кажется, что количество точек в моей работе, которых вообще касается GitHub Copilot, относительно невелико».

Вывод: чтобы реально ускорить поставку, нужно атаковать внешний цикл — ревью, тестирование, интеграцию,environments. Скорость набора кода здесь не узкое место.

Миф 3. Строки кода (LOC) — лучшая метрика влияния ИИ #

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

В 2014 году вышло статистическое исследование релевантности метрики строк кода в программных проектах; его авторы пришли к выводу: LOC не проходит тесты на валидность и потому имеет ограниченную полезность. Несмотря на десятилетие таких результатов, многие организации всё ещё используют LOC как меру продуктивности. С приходом ИИ метрика эволюционировала в подсчёт AI-сгенерированных строк — показатель, который публично рапортуют даже крупные компании, включая саму Microsoft.

LOC и родственные одноточечные метрики (story points) — ни статистически валидный, ни содержательно связанный с результатом индикатор. Хуже: они стимулируют команды «накручивать» систему, что затрудняет оценку реальных результатов. В нездоровой культуре такие метрики плодят токсичное поведение и подтачивают доверие разработчиков: когда людей давят к объёму кода в ущерб сотрудничеству, страдает качество дизайна, растёт технический долг и количество уязвимостей.

Парадокс: усилия по ускорению кодинга через ИИ усугубляют застарелые проблемы разработки. Больше кода — больше работы на ревью, тестирование и поддержку, выше риск технического долга. Цель софтверной компании — не максимизировать объём написанного кода, и оценка влияния ИИ должна это отражать. Измерение успеха объёмом кода подменяет истинную цель: поставлять безопасное, поддерживаемое и качественное ПО.

Вывод: LOC, AI-LOC и story points — плохие метрики влияния ИИ. Они измеряют активность, а не результат. Подробнее о том, почему одиночных метрик продуктивности не существует — в Метрики LLM.

Миф 4. ИИ одинаково помогает всем и во всём #

Исследования GenAI-инструментов дают крайне пеструю картину. Многие работы фиксируют большой прирост продуктивности, другие — нейтральный эффект, а одна недавняя работа (2025, опытные open-source разработчики) показала отрицательный эффект: инструменты ИИ в среднем увеличили время реализации на 18 %.

Почему такой разброс? Сейчас ИИ применяют как молоток, а код — как гвоздь. Но доказательства указывают: успешность GenAI для конкретной задачи зависит от множества факторов — от природы самой задачи до навыков разработчика.

Microsoft Report по AI и продуктивности (2024) установил: задачи знакомые и хорошо понятые дают больший прирост эффективности с Copilot, чем задачи незнакомые и менее понятые. Разработческий опыт и опыт работы с ИИ тоже положительно влияют на эффект. Стили решения задач и мотивация оказались существенны: разработчики, использующие комплексный подход к обработке информации, увереннее генерируют удачные промпты; те, кто пользуется технологией по собственной мотивации (а не принуждённо), тоже увереннее. При этом годы профессионального опыта обратно коррелированы с уверенностью в написании эффективных промптов.

Даже формулировка промпта меняет результат радикально: одно исследование показало, что переформулировка промпта с тем же смыслом даёт другой код в 46 % случаев и меняет корректность в 28 %. GenAI эффективнее для «кодоинтенсивных» задач (бойлерплейт, повторяющаяся работа), но не для творческих или коллаборативных.

Вывод: успеха с GenAI нет по универсальной формуле. Характер задачи, опыт разработчика, знакомство с кодовой базой, уверенность и навык составления промптов — всё это формирует результат.

Миф 5. ИИ превратит каждого в «10x-разработчика» #

Один из самых стойких мифов: инструменты вроде Copilot превратят каждого разработчика в «10x-разработчика», кратно умножив его продуктивность. Этот нарратив игнорирует коллаборативную, взаимозависимую природу реальной разработки и сложность реальных задач (многие предыдущие исследования смотрели игрушечные примеры, а не живой код).

Контролируемые эксперименты могут показывать впечатляющий прирост для индивида на изолированной задаче — тот самый «55 % productivity gain» — но эти результаты контекстно-зависимы и редко напрямую переносятся в сложные командные среды, где и строится большинство ПО. Прирост, измеренный в изоляции, не учитывает координацию, сотрудничество и обмен знаниями — то, без чего успешная поставка невозможна.

Более того, значительная часть разницы в производительности между разработчиками объясняется задачей, которую они делают. Один может обгонять другого на одной задаче, но это не значит, что он стабильно обгоняет на всех. Характеристики задачи, контекст и соответствие навыков — играют огромную роль.

Вывод: «10x-разработчик от ИИ» — маркетинговый нарратив. В командной работе прирост от инструмента растворяется под весом координации и сложности реального кода.

Миф 6. Эффективность ИИ — ответственность самого разработчика #

Большинство исследований ИИ в разработке смотрит, как отдельный инженер получает поддержку от GenAI-инструмента. Это возлагает бремя роста продуктивности на самих инженеров. Но исторически приросты продуктивности приходили не от изменений на индивидуальном уровне, а от системных изменений на уровне организации.

Кал Ньюпорт, профессор информатики Джорджтаунского университета, формулирует это точнее всех: «Исторически оптимизация систем ради роста продуктивности была чрезвычайно сложна. Сборочный конвейер не явился во вспышке самоочевидного озарения. Форд прошёл через множество ложных стартов и пошаговых экспериментов, вложил значительные деньги и разработал новые инструменты… А теперь мы буднично просим отдельных интеллектуальных работников провести столь же сложную оптимизацию их собственных, пресловутых „фабрик" — да ещё и параллельно со всей работой, которую они пытаются оптимизировать».

Часто инструменты внедряли с минимальным руководством. GenAI — одна из первых технологий, где организации вложили миллионы в лицензии без чёткого понимания, как выжать из них максимум. Use cases рождаются снизу, а исследователи параллельно ищут лучшие практики. Отсутствие ожидавшихся драматических приростов говорит: просто дать доступ — недостаточно. Чтобы раскрыть потенциал GenAI, нужно переосмыслить системы и процессы разработки на организационном уровне — создать среду, где разработчики могут давать больший эффект внутри более продуктивной экосистемы.

Вывод: ответственность за эффект ИИ лежит на организации, а не на инженере. Это системная, а не индивидуальная задача.

Миф 7. Хорошие ИИ-инструменты внедряются автоматически #

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

Недавние исследования показывают: разработчики — особенно женщины и старшие инженеры — сталкиваются с «штрафом за компетентность» (competence penalty) при использовании ИИ: они получают более жёсткие оценки за AI-ассистированную работу даже при идентичном результате. Доверие — отдельная проблема: хотя 80 % разработчиков используют эти инструменты, лишь 29 % доверяют их точности; многие сообщают, что тратят больше времени на отладку AI-вывода, чем написали бы сами. Это подтачивает обещанный прирост и добавляет когнитивную нагрузку.

AI-инструменты часто плохо интегрируются в существующие процессы. Разработчики и так перегружены и могут не иметь времени или поддержки на освоение новых инструментов — особенно если те не решают их реальные проблемы. Этические опасения (экология, происхождение обучающих данных) тоже играют роль, как и страх деградации навыков (de-skilling) или потери работы: инженеры боятся, что излишняя опора на ИИ подточит их способность решать задачи и сделает их менее незаменимыми.

В конечном счёте внедрение — это не только качество инструмента. Это доверие, контекст и человеческий опыт работы.

Вывод: качество инструмента — необходимое, но не достаточное условие внедрения. Без работы с доверием, интеграцией в процессы и страхами деградации даже лучший инструмент останется на обочине.

Миф 8. С ИИ enterprise может двигаться со скоростью стартапа #

Распространённое допущение: если маленький стартап может быстро поставлять фичи, почему крупный enterprise не может делать то же с ИИ? ИИ ускоряет разработку повсеместно, но структурные различия между стартапами и enterprise делают это сравнение обманчивым.

Стартапы обычно строятся на open-source компонентах и широко документированных фреймворках — ресурсах, которые массово представлены в обучающих данных LLM. Enterprise-системы, напротив, опираются на проприетарные инструменты и legacy-кодовые базы, которых модели никогда не видели. Кроме технической сложности, enterprise работает под требованиями compliance, безопасности, приватности и регулирования, применимыми только в масштабе — ограничениями, с которыми стартапы обычно не сталкиваются.

GenAI лучше всего работает в greenfield-сценариях, тогда как enterprise-ПО должно поддерживать обратную совместимость и интегрироваться с тысячами внутренних систем и сторонних инструментов. Цели тоже разные: стартап приоритизирует скорость до MVP и быструю итерацию, enterprise балансирует скорость с надёжностью, безопасностью и контрактными обязательствами. Ожидания клиентов расходятся: стартап может релизить альфы с багами и получать терпение ранних адоптеров; enterprise-клиент ждёт отполированное production-ready решение — и регуляторы с контрактами этого требуют.

Вывод: ИИ помогает и стартапу, и enterprise двигаться быстрее, но структурные реалии означают, что они никогда не будут работать в одинаковых условиях. Скорость видна; сложность — нет.

Почему внедрение — это системная задача #

Сквозной нитью через все восемь мифов проходит один тезис: ценность ИИ в разработке приходит не от раздачи лицензий, а от переосмысления процессов на организационном уровне. Это означает, что работа руководителя разработки не заканчивается на закупке инструмента — она, по сути, только начинается.

Что это значит на практике:

• Процессы ревью и тестирования. Ускорение кодинга сдвигает давление в ревью и CI/CD. Если эти фазы не масштабируются, ИИ не ускорит поставку, а создаст затор. Подробнее о том, как выстроить цикл вокруг AI-генерации кода — в AIDD.
• Обучение и нормирование промптов. Эффект ИИ зависит от навыка составления промптов и знакомства с задачей. Это значит, что нужно обучение, шаблоны и обмен удачными практиками внутри команды — а не надежда, что «разработчик сам разберётся».
• Доверие и культура. Штраф за компетентность и страх деградации навыков — реальные барьеры внедрения. Без психологической безопасности и честного разговора о роли ИИ инструмент не приживётся.
• Системные метрики вместо локальных. LOC и скорость кодинга — плохие индикаторы. Нужны метрики, отражающие цикл поставки целиком.

Историческая аналогия Ньюпорта здесь особенно уместна: Ford не получил сборочный конвейер, выдав лицензии на гаечные ключи. Он вложился в инструменты, эксперименты и перестройку всей системы производства. С ИИ — та же логика: настоящий прирост приходит от перестройки системы, а не от точки приложения инструмента.

Как измерять продуктивность #

Если LOC, AI-LOC и story points не работают, чем их заменить? В индустрии сложились три зрелых фреймворка, специально созданных для комплексной оценки продуктивности разработки. Примечательно, что SPACE был разработан при участии как раз Маргарет-Энн Стори и Брайана Хука — соавторов разбираемой статьи, так что метрический раздел здесь концептуально выверен.

Принцип общий: ни одна метрика в одиночку не отражает продуктивность. SPACE явно построен на этом — отсюда и название (пять осей, ни одну из которых нельзя вырвать без потери смысла). DevEx смещает фокус с «сколько произвели» на «насколько легко производить» — потому что опыт разработчика предсказывает долгосрочную продуктивность надёжнее, чем любой снэпшот активности. DORA, в свою очередь, смотрит не на написание кода, а на способность команды поставлять и поддерживать — то есть на тот самый внешний цикл, который, как мы видели в мифе 2, и определяет реальную скорость.

Для целей оценки влияния ИИ это означает: вместо подсчёта AI-LOC стоит смотреть, изменились ли lead time и change failure rate (DORA), не выросла ли когнитивная нагрузка от отладки AI-вывода (DevEx), не упала ли удовлетворённость и качество связи в команде (SPACE). Эти метрики покажут реальный системный эффект, а не локальный выигрыш в скорости набора.

Плюсы #

При всей критике выше генеративный ИИ — не враг продуктивности. Это инструмент, у которого есть зона реальной эффективности. Сбалансированный взгляд требует зафиксировать и его сильные стороны.

Общий паттерн плюсов: ИИ отлично берёт то, что и так легко делегировать — предсказуемое, формализуемое, повторяющееся. Там, где задача плохо формализуема или требует знания контекста, его полезность резко падает.

Минусы #

Общий паттерн минусов: риски концентрируются там, где ИИ внедряют как замену осмысленной инженерной работе, а не как её усиление. Минусы — не свойство инструмента, а свойство способа его внедрения.

Итого #

Восемь мифов объединяет одно: каждый из них переносит локальный, наблюдаемый эффект ИИ (ускорение набора кода, выигрыш на знакомой задаче) на систему в целом — и там этот эффект не подтверждается. Реальность сложнее и интереснее заголовков: ИИ работает лучше для одних задач, одних разработчиков и одних контекстов, чем для других; прирост не течёт автоматически из лицензии; внедрение буксует без доверия и времени на обучение; сравнение стартапа и enterprise игнорирует структурные ограничения.

Контекст решает: тип задачи, опыт разработчика, командная динамика и организационные системы — всё это формирует результат внедрения. LOC и скорость — плохие индикаторы реального прогресса. Чтобы раскрыть ценность ИИ в инженерии ПО, нужно отказаться от хайпа и простых метрик и сосредоточиться на цели более широкого порядка: строить безопасное, поддерживаемое и качественное ПО.