ИИ достиг 65% закоммиченного кода на год раньше срока. Знаем ли мы, что внутри?

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

Год назад разработчики и технические менеджеры в нашем первом опросе State of Code Developer Survey рассказали нам, какой объем их кода пишет ИИ и сколько, по их мнению, он будет писать в ближайшем будущем. В этом году мы опросили 1026 разработчиков и технических менеджеров по всему миру, чтобы узнать, что изменилось. Краткий ответ: ИИ развивался быстрее, чем предсказывали респонденты, а верификация — нет, и команды в любом случае уже планируют свой следующий скачок. Подробности вы можете найти в отчете State of Code Developer Survey за этот год.

Давайте кратко взглянем на то, о чем говорят данные!

Насколько быстро вырос ИИ-кодинг в этом году?

В прошлом году респонденты, пишущие код, сообщили нам, что ИИ генерировал или существенно помогал в написании 42% закоммиченного ими кода, и они ожидали, что эта доля достигнет 55% в течение года и 65% в течение двух лет. Они достигли 65% всего за один год.

Код, который пишет ИИ, также стал важнее, чем раньше. 76% респондентов заявили, что их команда или компания использует инструменты ИИ-кодинга для бизнес-критичных или критически важных сервисов (по сравнению с 58% в прошлом году). Таким образом, мы давно миновали стадию, когда ИИ доверяли в основном прототипы и побочные проекты.

Кто проверяет весь этот код?

Меньше людей, чем хотелось бы, а у тех, кто это делает, заканчивается время. 53% респондентов теперь тратят больше времени на ревью кода, чем на его создание, по сравнению с 18%, которые говорили так до внедрения инструментов ИИ. Несмотря на все это дополнительное время на ревью, 76% разработчиков и технических менеджеров согласны с тем, что «мы генерируем ИИ-код быстрее, чем успеваем его проверять».

Доверие постепенно растет, что делает картину скорее интересной, чем обнадеживающей. 45% разработчиков и технических менеджеров согласны с тем, что код, сгенерированный ИИ, функционально корректен (по сравнению с 29% в прошлом году), однако лишь 6% согласны с этим полностью (4% в прошлом году). Это означает, что 94% все еще не доверяют ему до конца. В то же время доля тех, кто полностью согласен с тем, что они всегда проверяют сгенерированный ИИ код перед коммитом, упала с 48% до 39%. Иными словами, код, которому почти никто полностью не доверяет, проверяется менее последовательно, и при этом он попадает в ПО, от которого зависит бизнес.

Почему все вдруг заговорили о «фабриках ПО» (software factories)?

Потому что команды уже их строят. Если бы мы спросили кого-нибудь об автономных фабриках ПО, когда публиковали наш прошлый опрос в январе, наиболее вероятным ответом был бы: «Каких еще фабриках ПО?». Сейчас 5% строят или уже построили фабрики ПО, где агенты автономно работают над задачами, а 34% рассчитывают создать или начать использовать такую фабрику в течение года. Тяга к автономии растет быстрее, чем способность проверять результаты ее работы, и чем больше автономии получают агенты, тем дороже обходятся ошибки, которые удается пропустить.

Так что же не дает разработчикам спать по ночам?

По словам респондентов, немало вещей, и опасения по поводу безопасности возглавляют список. Четыре из семи основных опасений по поводу кода, сгенерированного ИИ, связаны с безопасностью: например, 44% очень или крайне обеспокоены новыми или трудноуловимыми уязвимостями, а 42% — критическими уязвимостями.

Но угроза больше не ограничивается только безопасностью кода, который пишет ИИ. 61% разработчиков и технических менеджеров очень или крайне обеспокоены атаками, использующими ИИ для поиска и эксплуатации уязвимостей быстрее и в большем масштабе во ВСЕМ коде, включая существующий, что делает это главной проблемой в опросе этого года. Если злоумышленники используют ИИ для круглосуточного поиска изъянов, уязвимость, ожидающая следующего квартального ревью, дает массу времени для того, чтобы кто-то другой нашел ее первым.

ИИ погашает технический долг или увеличивает его?

И то, и другое почти для всех. 95% респондентов отмечают как минимум одно положительное влияние сгенерированного ИИ кода на технический долг своей команды (93% в прошлом году), а 89% — как минимум одно отрицательное влияние (88% в прошлом году).

Самый полезный вывод здесь касается того, на чем учится ИИ. 78% разработчиков и технических менеджеров согласны с тем, что высокое качество их кодовой базы положительно влияет на качество кода, генерируемого инструментами ИИ, а 64% согласны с тем, что низкое качество ухудшает результаты работы ИИ. Представьте себе агента как очень быстрого нового сотрудника, который копирует любой пример, находящийся ближе всего в кодовой базе: если этот пример чист, вы получаете больше чистого кода, а если это беспорядок, вы получаете беспорядок со скоростью агента.

Когда происходит верификация и имеет ли значение время ее проведения?

Для большинства команд это происходит поздно, и данные свидетельствуют о том, что время проведения верификации связано с результатами. Среди респондентов, чьи команды проверяют ИИ-код, 81% говорят, что ИИ-код анализируется или проверяется во время код-ревью или пул-реквеста, 51% — в конвейере CI/CD и 43% — в режиме реального времени, по мере того как агент генерирует код.

Команды, которые проводят автоматизированную проверку инлайн (в процессе написания ИИ-кода), сообщают о более высоких результатах, чем те, кто этого не делает. 61% из них утверждают, что ИИ положительно повлиял на безопасность кода (по сравнению с 46% команд без инлайн-проверки), и этот разрыв сохраняется для показателей уязвимости (49% против 38%), качества кода (75% против 63%) и времени вывода на рынок (89% против 81%). Это скорее корреляции, чем доказательства причинно-следственной связи, но они указывают в одном направлении: выявление проблемы, пока агент еще владеет контекстом, обходится гораздо дешевле, чем ее обнаружение в пул-реквесте, поверх которого наслоилось еще три изменения.

Управляют ли команды ИИ-кодом и окупается ли это?

Больше команд управляют ИИ-кодом, чем год назад, хотя гораздо меньше команд делают это эффективно. 55% респондентов теперь говорят, что в их организации есть руководства, политики или контроли качества (quality gates) для кода, сгенерированного ИИ, которые отличаются от правил для кода, написанного разработчиками (по сравнению с 41% ранее). Только 23% описывают четко определенные, отдельные руководства или автоматизированные проверки (рост с 14%), в то время как наиболее распространенным подходом по-прежнему остаются неформальные правила, проверяемые вручную (32%, рост с 27%).

Разница между этими двумя группами видна в результатах. Команды с четко определенными правилами на 31% чаще заявляют, что ИИ положительно повлиял на уровень дефектов (66% против 51%), и на 32% чаще говорят то же самое о затратах на переделку или исправления (70% против 53%). Они также являются единственной группой, где ИИ снижал комплаенс-риски чаще, чем повышал их (снижение у 23% против повышения у 16%), что является полезным противовесом упомянутым выше опасениям по поводу безопасности.

Почему ROI все еще кажется недостижимым?

Потому что выгода реальна, но меньше, чем ожидалось, и большая часть сэкономленного времени тратится на что-то другое. 43% респондентов говорят, что ИИ-кодинг еще не принес ожидаемой отдачи: 47% ожидают ROI в 50% или более от своих инструментов ИИ-кодинга, но только 27% сообщают о столь высокой отдаче на данный момент, а 22% вообще не уверены, какую отдачу они получили.

Похоже, именно в области управления (governance) разрыв начинает сокращаться. 32% респондентов, использующих управляемые агенты, отмечают наблюдаемый ROI в 50% и более, по сравнению с 19% тех, кто использует одобренные агенты, но полагается на неформальное ручное управление.

Две вещи сдерживают их развитие. Первая — это рутинная работа, которая никуда не делась: респонденты оценивают около 27% своей работы как рутину (24% в прошлом году), а 54% говорят, что она занимает более четверти их недели, что выше показателя в 38%. Вторая — это стоимость, которая выросла сильнее, чем любая другая проблема, которую мы отслеживаем: 45% очень или крайне обеспокоены стоимостью передовых инструментов и агентов для ИИ-программирования, по сравнению с 30% ранее.

Какие инструменты ИИ-программирования команды используют сейчас?

Claude показал самый большой скачок среди всех инструментов в этом году. 85% респондентов говорят, что они или их команда использовали Claude или Claude Code для разработки программного обеспечения в прошлом году (рост с 48%), в то время как доля GitHub Copilot упала с 75% до 65%, а Cursor выросла с 31% до 41%. Интересно, что, несмотря на то, что стоимость является серьезной проблемой, респонденты, которые говорят об этом, выбирают уровни моделей так же, как и все остальные, поэтому опасения по поводу затрат еще не привели к выбору более дешевых моделей.

Насколько больше получают пользователи SonarQube от ИИ-программирования?

Заметно больше — как в отношении качества и безопасности кода, так и в отношении производительности. На протяжении всего этого отчета проверка и управление постоянно упоминались как практики, стоящие за ускорением внедрения ИИ, которые действительно приносят результат. Команды с четко определенными руководящими принципами и ранней проверкой сообщают о более высоком ROI, чем команды, полагающиеся на неформальные правила и позднюю проверку. Это именно та работа, для которой создан SonarQube, и пользователи SonarQube среди наших респондентов показывают, как это выглядит на практике.

Пользователи SonarQube на 81% чаще, чем те, кто не использует этот инструмент, говорят, что сгенерированный ИИ код оказал очень положительное влияние на безопасность кода. Аналогичные разрывы наблюдаются в отношении уровня уязвимостей (на 65% чаще сообщают об очень положительном влиянии), уровня дефектов (42%), технического долга (46%) и качества кода (66%). Они также на 39% чаще сообщают об очень положительном влиянии на производительность разработчиков.

Как и в случае с другими сравнениями в отчете, это лишь ассоциации — сравнение не учитывает размер компании, регион или роль, — но пользователи SonarQube также с большей вероятностью придерживаются практик, к которым постоянно возвращается этот отчет: четко определенные руководящие принципы, систематический контекст для агентов, проверка в CI и измерение результатов.

Как внедрить уверенность в коде на фабрике программного обеспечения?

Начните с того, чтобы относиться к уверенности как к тому, что вы проектируете, а не как к тому, на что вы надеетесь. Здесь, в Sonar, мы описываем это как формулу:

Уверенность в коде = Намерение × Направляющие принципы × Проверка × Доказательства

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

• Намерение: Запишите свои правила в виде стандартов и ограничений, достаточно конкретных для того, чтобы агенты могли им следовать, а автоматизированные проверки — их обеспечивать.
• Направляющие принципы: Предоставьте агентам контекст кодовой базы и направляющие принципы через общие систематические процессы, перенесите управление на этап начала написания кода агентом, установите контроль над разрешениями и доступом к инструментам, а также поддерживайте кодовую базу в здоровом состоянии, поскольку именно на ней обучается ИИ.
• Проверка: Проверяйте каждое изменение независимо, в процессе написания кода агентом, при создании pull request и в CI, и никогда не позволяйте модели проверять свою собственную работу.
• Доказательства: Ведите учет того, что было проверено и что выявили проверки, измеряйте влияние ИИ на производительность и ROI перед дальнейшим масштабированием, а также сделайте расходы на токены прогнозируемыми и привязанными к готовому к выпуску результату.

Так с чего же начать оптимизацию результатов ИИ-программирования?

Начните с элемента выше, который ваша команда оценила бы ближе всего к нулю, если бы вы были полностью честны, и для многих команд это будет намерение. Только 23% респондентов описывают четко определенные, специфичные для ИИ руководящие принципы или автоматизированные проверки, что означает, что большинство правил, которым должны следовать агенты, все еще существуют только в головах рецензентов, и превращение их в то, с чем можно сверить работу агента, — это очень практичный первый шаг.

Прочитайте полный отчет State of Code Developer Survey 2027 для получения дополнительных данных и аналитики, а также подробного обзора каждого элемента формулы уверенности в коде, и будьте готовы перейти к автономной разработке программного обеспечения, которая может показать результаты: программное обеспечение, которое вы можете уверенно выпускать, прибыль, о которой вы можете отчитаться, и доказательства, за которыми вы можете стоять, когда кто-то спросит, откуда вы знаете, что это работает.