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

Компания DX, специализирующаяся на аналитике инженерной эффективности и продуктивности разработки и вошедшая в состав Atlassian, опубликовала отчёт о влиянии ИИ на разработку по итогам II квартала 2026 года. DX работает с метриками продуктивности разработки и опыта разработчиков; её платформу используют крупные технологические и финансовые компании, включая GitHub, Airbnb, Pinterest и Morgan Stanley.

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

Когда DX только начала отслеживать влияние искусственного интеллекта на инженерные команды, главной задачей было сравнить группы пользователей ИИ с их исходными показателями за предыдущие периоды и ответить на простой вопрос: как меняется объём результатов разработки после внедрения ИИ‑инструментов? Но теперь, когда уровень использования искусственного интеллекта в индустрии превысил 90%, сравнивать пользователей ИИ с контрольной группой, которая им не пользуется, уже практически невозможно.

Поэтому фокус смещается: вместо вопроса «использует ли команда ИИ?» гораздо важнее понять, что это использование даёт на практике. В отчёте DX оценивает результаты более чем 500 инженерных организаций сразу по нескольким направлениям: скорости разработки, эффективности, качеству и влиянию на конечный результат. Это принципиально важно, потому что рост количества написанного кода сам по себе ещё не означает роста продуктивности всей системы.

На руководителей разработки при этом всё сильнее давит необходимость обосновывать быстро растущие расходы на ИИ‑инструменты. Данные за II квартал показывают: объективный прирост скорости есть, но распределён он очень неравномерно. Например, медианный недельный TrueThroughput за четыре квартала вырос на 37% — с 1,42 до 1,94 PR на разработчика в неделю. Однако основной прирост приходится на небольшие организации с численностью инженерных команд менее 100 человек и компании технологического сектора; крупные организации и компании из традиционных отраслей отстают, причём разрыв увеличивается.

В отчёте DX выделяет несколько важных тенденций.

1. ИИ генерирует уже больше половины кода

В I квартале 2026 года на код, созданный с помощью ИИ, приходилось 34%, а во II квартале — уже 52%. Причём речь идёт не просто о коде, который разработчики получили от ассистента, а о коде, который в итоге попал в смерженные изменения. Иначе говоря, искусственный интеллект всё глубже встраивается в реальный процесс разработки.

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

2. Появляются тревожные сигналы по качеству

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

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

3. По части опыта разработчиков ситуация ухудшается

За четыре квартала индекс опыта разработчиков (DXI) снизился с 67 до 65. При этом влияние ИИ неоднозначно: по одним направлениям он действительно помогает, по другим создаёт новые проблемы. Улучшается качество документации, растёт сопровождаемость кода, ускоряется адаптация новых сотрудников. Одновременно увеличивается размер PR, замедляется ревью и ухудшается инкрементальная доставка изменений. В сумме эффект пока остаётся отрицательным.

Особенно показательно, что отдельные метрики качества движутся в противоположных направлениях. По данным отчёта, сопровождаемость кода выросла примерно на 3,8%, то есть разработчикам в среднем стало проще понимать и поддерживать код. Но уверенность в изменениях при этом снизилась примерно на 6,1%: разработчики стали меньше уверены в том, что внесённые изменения не приведут к сбоям в продакшене. Получается характерный для нынешнего этапа внедрения ИИ парадокс: код может становиться локально понятнее, а уверенность в поведении системы после изменений — снижаться.

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

4. ИИ упрощает понимание кодовой базы, но одновременно снижает доверие к сгенерированному коду

Данные за II квартал показывают необычное расхождение двух метрик качества ПО, которые раньше обычно менялись в одном направлении. С I квартала 2026 года сопровождаемость кода выросла на 3,8%, а уверенность в изменениях, наоборот, снизилась на 6,1%.

Первая метрика показывает, насколько легко разработчикам понимать и сопровождать кодовую базу. Вторая — насколько они уверены, что внесённые изменения не приведут к сбоям в продакшене. Обычно эти показатели связаны: чем понятнее и лучше сопровождается код, тем увереннее разработчики вносят в него изменения.

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

Это важное различие: «код легко понять» и «код безопасно менять» — не одно и то же. По мере того как доля сгенерированного ИИ кода растёт, качество инженерного процесса всё сильнее зависит не только от читаемости самого кода, но и от того, насколько хорошо команда умеет проверять его поведение, тестировать изменения и оценивать их влияние перед выпуском.

5. Экономия времени пока не превращается в новую разработку

По оценке DX, разработчики, использующие искусственный интеллект, теперь экономят в среднем от 4 до 6 часов в неделю. Однако доля времени на новую разработку — то есть соотношение времени, которое уходит на создание новой функциональности, и времени на поддержку и сопутствующие задачи — за тот же период практически не изменилась.

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

По всей видимости, выигрыш во времени частично поглощается другими этапами разработки. Код удаётся создавать быстрее и в большем объёме, но затем его всё равно нужно проверить, протестировать, интегрировать и довести до продакшена. На этом фоне рост размера PR, более медленное ревью и ухудшение инкрементальной доставки могут съедать часть времени, которое искусственный интеллект экономит непосредственно на написании кода.

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

6. Расходы на ИИ растут намного быстрее, чем отдача от него

За четыре квартала медианные расходы организаций на инструменты на базе ИИ выросли примерно с $1,5 тыс. до $44 тыс. в квартал. В технологическом секторе рост оказался ещё резче — почти в 28 раз.

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

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

Во второй половине 2026 года этот вопрос, вероятно, станет особенно острым. Руководителям, которые не смогут показать связь между растущими расходами на ИИ и измеримыми результатами разработки, будет всё сложнее обосновывать дальнейшее увеличение бюджетов.

Что это значит для руководителей

Данные за II квартал 2026 года показывают, что рынок переходит от простого внедрения ИИ к оценке его реальной окупаемости. Сам по себе факт, что компания закупила ИИ‑инструменты и разработчики активно ими пользуются, уже мало о чём говорит. Теперь главный вопрос звучит иначе: привели ли эти вложения к измеримому улучшению разработки.

Поэтому руководителям стоит смещать фокус с покупки новых инструментов на весь процесс вокруг них. Если искусственный интеллект ускоряет написание кода, но затем изменения застревают на ревью, тестировании, интеграции или выпуске, локальный выигрыш в скорости не превращается в рост эффективности команды. В таком случае ИИ не устраняет узкие места, а лишь переносит их дальше по процессу разработки.

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

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

Поэтому следующая стадия внедрения ИИ — не «дать каждому разработчику ассистента», а перестроить инженерные процессы под новую скорость производства кода. Иначе выигранные часы просто растворятся в существующих издержках процессов, а растущие расходы на ИИ так и не превратятся в заметную бизнес‑ценность.

Сравнить показатели своей команды с данными более чем 500 инженерных организаций по скорости разработки, качеству и стоимости ИИ‑инструментов можно в полной версии отчёта.

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

• 8 сентября, 20:00. «Что надо знать про работу LLM моделей». Записаться

• 22 сентября, 20:00. «Можно ли доверять ИИ‑коду: как находить галлюцинации, уязвимости и устаревшие решения». Записаться

Полный список бесплатных уроков сентября смотрите в дайджесте.