Анализ 623 млн. изменений кода, проведенный компанией GitClear, подтверждает реальность прироста производительности кодирования при использовании искусственного интеллекта, но также показывает, что он несопоставим с сопутствующими затратами на последующее сопровождение кода, пишет на портале The New Stack Стив Фентон, специалист по работе с сообществом Octopus Deploy.
Значительная часть индустрии разработки ПО возлагает на ИИ-инструменты — от ранних чат-интерфейсов до современных систем, использующих рои автономных агентов — большие надежды с момента их появления. Однако в последние недели настроения изменились: например, поставщик HR-ПО Rippling добавил в свою систему панель мониторинга расходов на ИИ, позволяющую финансовым и техническим директорам контролировать затраты, а вице-председатель IBM Гэри Кон недавно заявил, что окупаемость инвестиций оказалась «далеко не такой высокой, как многие полагали». И пока в Северное полушарие приходит осенняя прохлада, для бюджетов на ИИ-инструменты, похоже, наступает зима.
По мере того как организации будут приводить в порядок свои финансовые показатели, команды начнут ощущать давление в отношении бюджетов на использование таких инструментов, как Claude Code и Cursor. Это может обернуться либо ужесточением лимитов на использование там, где отдача неочевидна, либо нехваткой средств для поддержания текущих объемов работы.
Организации, научившиеся измерять влияние ИИ, все чаще осознают: высокая скорость генерации кода не гарантирует улучшения ключевых показателей эффективности. Если оценивать продуктивность по количеству строк кода, числу запросов на изменения (pull requests) или даже по количеству реализованных функций, четкой связи с реальной ценностью продукта не прослеживается. Далеко не каждая строка кода или функция одинаково важны для бизнеса или клиентов; разброс в их значимости может быть колоссальным.
Даже на уровне непосредственных результатов многие организации так и не поняли, как превратить локальные улучшения в комплексный рост эффективности всего процесса. Прирост скорости написания кода либо поглощается новыми задачами, порождаемыми самим же ИИ, либо нивелируется изменениями на последующих этапах разработки. Если вы не разобрались в особенностях потоков создания ценности до внедрения ИИ, попытки оценить окупаемость инвестиций могут стать для вас болезненным уроком.
Если бы проблема сводилась лишь к сопоставлению затрат на ИИ-инструменты с конечной ценностью продукта, это уже было бы серьезно. Но происходит нечто гораздо более тревожное.
Продуктивность с точки зрения получаемых результатов
Давайте взглянем на данные, собранные и проанализированные GitClear для опубликованного в июне отчета «Maintainability Gap». В нем представлен анализ 623 млн. изменений, внесенных в период с 2023 по 2026 гг. По мере того как команды активно внедряют среды разработки с поддержкой ИИ и такие инструменты, как Cursor и Claude Code, база данных GitClear, отслеживающая операции с кодом, позволяет им выявлять и классифицировать дублирование кода, «горячие точки» (проблемные участки), а также признаки удачного или неудачного структурирования кода.
Согласно отчету, активные пользователи ИИ увеличили собственную скорость работы на 25% по сравнению с предыдущими показателями — это далеко от заявлений о десятикратном росте. То же исследование показывает, что эти активные пользователи превосходят тех, кто не применяет ИИ, по объему выработки в
Первый этап расчета ROI — определение, оправдывают ли полученные результаты затраченные средства. Сильно удивлюсь, если для многих организаций ответ окажется утвердительным.
Возможно, из-за того, что в дискуссиях об ИИ-инструментах упор делался преимущественно на скорость, другие факторы остались без должного внимания. Индустрия разработки ПО могла бы извлечь иную выгоду, если бы рассматривала эти инструменты не как гоночный болид, а как вилочный погрузчик: ведь скорость движения по прямой здесь не так уж впечатляет. Зато они способны выполнять тяжелую работу, сложную для нас, простых людей, — например, масштабные изменения в кодовой базе, такие как замена устаревшей, неподдерживаемой библиотеки на актуальный аналог.
Для тех, кто успешно прошел этот первый этап, можно рассмотреть следующий фактор.
Продуктивность с точки зрения качества кода
Переход к использованию ИИ привел к кардинальным изменениям в поведении специалистов индустрии разработки ПО. На протяжении десятилетий постоянно подчеркивалась важность удобства сопровождения кода. Более половины книг по программированию на моей полке посвящены архитектуре, проектированию кода, связности компонентов и чистоте кода. Во многих из этих изданий затрагивается тема рефакторинга, подкрепленного автоматизированными тестами.
Однако данные, полученные GitClear, свидетельствуют о совершенно иной тенденции: возврате к эпохе разработки по принципу «пиши и исправляй» («code-and-fix»). Согласно исследованию, за период с 2023 г. частота дублирования блоков кода выросла на 81% — с 40,3 до 73,0 случаев на миллион измененных строк. Множественные реализации одной и той же идеи начинают расходиться, порождая трудноуловимые ошибки, которые возникают вновь и вновь (подобно игре «Ударь крота»). Доля перемещенного кода — характерного признака рефакторинга — снизилась с 21% от общего объема измененных строк в 2022 г. до 3,8% в
Внося подобные изменения, поначалу вы не ощущаете негативных последствий, так как находитесь на раннем этапе кривой затрат на сопровождение. Однако со временем растущие расходы станут непосильными. Увеличится доля задач по переделке кода, отнимающих время у разработки новых функций. На выявление и устранение даже незначительных проблем будет уходить слишком много времени, а многие из них просто станут частью системы, поскольку их исправление окажется экономически невыгодным. Накопление тесно связанных и запутанных фрагментов кода приведет к тому, что ПО утратит свою ценность.
Мы пытались подтвердить заявления о десятикратном росте продуктивности благодаря ИИ-помощникам по кодированию. Данные свидетельствуют об обратном. До появления ИИ разработчики предпочитали рефакторинг копированию (copy-and-paste) кода в соотношении примерно два к одному. Теперь же они прибегают к копипасту кода примерно в пять раз чаще.
Технические практики — основная задача, а не второстепенное дело
Выступая на конференциях и встречах профессиональных сообществ с рассказами о том, как должен выглядеть качественный выпуск ПО, я упоминаю, в частности, автоматизацию тестирования и рефакторинг. В ходе последующей сессии вопросов и ответов неизбежно звучит вопрос: «Как получить разрешение руководства на внедрение этих практик?».
Разработчиков жестко подгоняют, требуя быстрых результатов, поэтому они приучаются избегать всего, что кажется им второстепенным. Стремясь повысить производительность, они упрощают процесс написания кода, не оставляя времени на тесты или улучшение архитектуры, так как это замедлило бы выпуск новой функции. В конечном счете это приводит к значительному замедлению разработки любого функционала в долгосрочной перспективе.
Преимущество облегченных процессов выпуска ПО заключается в опоре на технические практики, позволяющие контролировать затраты на сопровождение системы с течением времени. Идея состоит в том, что более взвешенный подход к работе сегодня позволит сохранять высокий темп внесения изменений в будущем. Если же пренебрегать этими практиками, любые изменения будут даваться все труднее и обходиться все дороже.
Такие технические практики, как автоматизация тестирования и рефакторинг, — это не «побочные квесты», а сама суть работы. Техническая дисциплина — фундаментальное требование при выпуске коммерческого ПО, и эти практики уже давно перестали быть необязательными.
Меня ставят в тупик просьбы подсказать способы убедить руководство разрешить применение этих практик. Я никогда не спрашивал разрешения делать то, что правильно для меня, для программного продукта, его пользователей и организации. Здесь не может быть компромиссов, поскольку отказ от технических практик вредит всем участникам процесса.
Во многих организациях так и не удалось преодолеть отношение к этим мерам как к «побочным квестам», а внедрение ИИ лишь усугубило ситуацию. Когда команды получают инструменты на базе ИИ, от них ожидают высокой отдачи. Однако на деле они наблюдают лишь 25%-ный рост скорости внесения изменений, в то время как в отрасли бытует ошибочное мнение о десятикратном ускорении; в результате давление с требованием результатов только возрастает.
В таких нездоровых условиях неудивительно, что те, кто считает качественные практики чем-то второстепенным, пропускают критически важные этапы работы.
Признаки высокой эффективности хорошо известны
Высокоэффективные команды осознали, что набор практик по выпуску ПО — это обязательное условие, а не опция по выбору. Они пришли к этому выводу, поскольку занимались масштабированием задолго до появления новых инструментов.
Когда речь идет о важном ПО — продуктах, от которых зависят люди и которые должны оставаться актуальными через год, пять лет и дольше, — мы уходим от прежнего подхода «выбирай что хочешь». Теперь к профессиональной разработке и выпуску ПО предъявляются новые, более высокие требования.
И все же есть проблеск надежды. Команды, успешно использующие ИИ, — это те же самые коллективы, которые опережали конкурентов еще до появления этой технологии. Они придерживаются строгой технической дисциплины, отслеживают показатели качества кода и уделяют первостепенное внимание мастерству создания кода, пригодного для долгосрочного сопровождения.
