Разработчики программного обеспечения настолько привыкли к инструментам с искусственным интеллектом для написания кода, что многие уже отказываются работать без них – даже для ограниченного круга задач в контролируемых экспериментах. В то же время все больше данных свидетельствуют о том, что эти системы нередко создают больше проблем, чем решают. Таким образом, массовое внедрение ИИ в программирование начинает выглядеть скорее вопросом восприятия и зависимости, чем реальной эффективности.
Парадокс продуктивности
В феврале 2026 года лаборатория по исследованию ИИ "METR" попыталась повторить нашумевшее исследование, сравнивающее время, затрачиваемое разработчиками на задачи с помощью ИИ и без нее. Опыт провалился по неожиданной причине: участники просто отказывались работать без своих ИИ-инструментов даже для ограниченного числа задач в строго контролируемой среде.
Первоначальное исследование METR 2025 года уже нарисовало тревожную картину. Программисты утверждали, что ИИ «ускорил» их примерно на 24%, но реальные измерения показали обратное – в среднем они тратили на 19% больше времени на выполнение задач. Задержка была связана с дополнительными усилиями по поиску и исправлению ошибок, управлению ИИ-помощником и ожиданием генерации кода.
Даже столкнувшись на практике с этим замедлением, участники продолжали оценивать прирост скорости от ИИ примерно в 20% – это показательно для сильного расхождения между субъективными ощущениями и объективными результатами. После того как лаборатории не удалось воспроизвести эксперимент в 2026 году, она опубликовала опрос, в котором разработчики сами заявили, что ИИ делает их «в два раза более ценными» для своих организаций.
Код более низкого качества и скрытые расходы
Независимые анализы показывают, что ускорение сопровождается серьезной ценой в плане качества. Платформа для code review "CodeRabbit", проанализировав 470 открытых pull request-ов, установила, что код, сгенерированный ИИ, содержит в среднем примерно в 1,7 раза больше проблем по сравнению с написанным вручную. Критические и серьезные дефекты в изменениях, созданных с помощью ИИ, встречаются в 1,7 раза чаще, логические и синтаксические ошибки возрастают примерно на 75%, а уязвимости в безопасности увеличиваются в 1,5–2 раза.
Стартап "Entelligence AI", специализирующийся на надежности и мониторинге, сообщает, что компании тратят около 44% своих ИИ-токенов на исправление проблем, созданных самим ИИ – эта оценка основана на данных более чем 2400 организаций. Исследователи из Сингапурского университета менеджмента пришли к аналогичным выводам в апрельском отчете, предупреждая, что «сгенерированный ИИ код может вовлечь реальные программные проекты в долгосрочные расходы на поддержку».
Как управлять зависимостью от ИИ
Рекомендации специалистов сводятся к ясному принципу: относитесь к коду, созданному ИИ, так же, как вы относились бы к коду начинающего программиста. Команда SMU и основатель "Cognition" Скотт Ву – создатель ИИ-агента для программирования "Devin" – единодушны в том, что критически важно поддерживать надежные системы контроля качества и внимательно проверять каждое изменение, предложенное ИИ.
Эксперты также настаивают на том, что самые важные задачи – проектирование архитектуры, выбор технологий, обеспечение безопасности и управление сложными зависимостями – должны оставаться в руках опытных инженеров. ИИ может быть полезен при генерации шаблонного (boilerplate) кода, вспомогательных функций и первичных черновиков, но не как автономный источник истины для общего дизайна системы.
«Вы пишете код быстрее, но у поддержки нет автопилота»
Программист и автор Джеймс Шор сформулировал дилемму особенно остро в публикации, которая быстро стала популярной на "Hacker News": «Вы теперь пишете код в два раза быстрее? Лучше надейтесь, что расходы на поддержку также сократились вдвое. Иначе вы в ловушке. Вы меняете временный прилив скорости на вечное рабство».
Эта цитата отражает суть новой реальности в индустрии: ИИ может создавать ощущение взрывной продуктивности, но если организации не учитывают возросшие расходы на ревью, тесты и поддержку, они рискуют накопить невидимый «технический долг», который в долгосрочной перспективе съест всю краткосрочную выгоду в скорости. Вопрос уже не в том, использовать ли ИИ, а в том, как именно – и с какими защитными механизмами – чтобы инструмент не превратился в источник постоянной уязвимости.