Приближается сезон планирования, и для многих инженерных руководителей бюджетные обсуждения в этом году включают статью расходов, которой едва ли существовало два года назад: инструменты для написания кода с помощью ИИ и потребляемые ими токены. Историю внедрения легко рассказать, так как большинство разработчиков программного обеспечения теперь работают с агентами кодирования каждую неделю, и объем кода соответственно вырос. Более сложный вопрос, который все чаще задают финансовые отделы, заключается в том, что весь этот код на самом деле принес бизнесу.
Прежде чем мы перейдем к тому, что с этим делать, давайте посмотрим, где находится ценность кода, созданного ИИ, и где она имеет тенденцию улетучиваться.
Как выглядит бизнес-ценность в разработке с использованием ИИ?
ИИ-агенты для кодирования теперь являются частью повседневной профессиональной разработки. JetBrains' 2026 Developer Ecosystem Survey выяснили, что 90% профессиональных разработчиков используют ИИ-агенты на работе по крайней мере еженедельно, а 68% используют их ежедневно. В BairesDev's Q3 2026 Dev Barometer 42% опрошенных разработчиков программного обеспечения заявили, что ИИ пишет по крайней мере половину их кода, по сравнению с 12% годом ранее. Эти цифры измеряют уровень внедрения и активность, но они мало что говорят об окупаемости.
Разработка программного обеспечения приносит пользу только тогда, когда работающее изменение доходит до продакшена и делает то, что нужно бизнесу. Пока это не произошло, код несет затраты в виде токенов, вычислительных ресурсов, часов на ревью и внимания инженеров, не давая бизнесу ничего, что он мог бы использовать.
Именно здесь картина становится неприятной, поскольку активность и ценность теперь расходятся. Телеметрия от 22 000 разработчиков в Faros's Q2 2026 AI Engineering Report показывает, что команды с высоким уровнем внедрения ИИ завершают на 66% больше эпиков, в то время как количество развертываний в неделю упало почти на 12%, а количество инцидентов на один pull request утроилось. Исследование CloudBees State of Code Abundance 2026 показало, что 67% руководителей технологических предприятий сообщают о значительной росте объема кода, однако лишь 31% затрат на ИИ можно связать с конкретными бизнес-результатами, а 81% столкнулись с ростом проблем в продакшене из-за сгенерированного ИИ кода. Код движется быстрее, в то время как поставляемая им ценность отстает.
Таким образом, рентабельность инвестиций (ROI) агентной разработки сводится к соотношению между верифицированными изменениями, которые поставляются и остаются поставленными, и полными затратами на их создание. Увеличение первого и снижение второго заставляет ИИ окупать себя, в то время как измерение одного лишь объема генерации имеет тенденцию приносить прирост, который никогда не отображается в отчете о прибылях и убытках (P&L).
Куда улетучивается ценность кода, созданного ИИ?
Ценность редко исчезает в один драматичный момент. Она размывается четырьмя различными силами, каждая из которых имеет свой собственный профиль затрат, поэтому полезно рассмотреть их по очереди.
Производственные циклы, растянутые из-за повторных попыток. Агенты редко доставляют код с первой попытки. Когда генерация не проходит сборку или ревью, агент пробует снова, часто регенерируя гораздо больше, чем требовалось для исправления дефекта, и каждый такой цикл потребляет токены и календарное время. По мере перехода инструментов ИИ от лицензий с фиксированной оплатой к тарификации по факту использования, эти циклы становятся заметными для финансов расходами, и качество кода оказывает прямое влияние на размер счета: исследование Sonar показало, что агенты, работающие в более чистых кодовых базах, использовали на 7.2% меньше входных токенов и на 8.5% меньше выходных токенов при выполнении тех же задач, без какого-либо значительного изменения процента выполнения.
Переделка. Сгенерированный ИИ код обладает неприятной привычкой выглядеть правильно. 61% разработчиков говорят, что ИИ часто производит код, который выглядит корректно, но ненадежен, а 38% говорят, что его ревью требует больше усилий, чем проверка работы коллеги. Дефекты, которые проходят быструю проверку, всплывают позже, после интеграции или релиза, и работу приходится делать дважды, поэтому время, сэкономленное при генерации, тратится снова на исправление. Разработчики по-прежнему теряют примерно четверть своей недели на рутинную возню, независимо от того, насколько интенсивно они используют ИИ.
Устранение последствий. Проблемы, ускользнувшие от ревью, оседают в кодовой базе в виде технического долга. Исследователи Carnegie Mellon, изучавшие 807 открытых репозиториев, внедривших Cursor, обнаружили увеличение добавленных строк кода в первый месяц в три-пять раз, которые оказались временными, наряду с устойчивым увеличением количества предупреждений статического анализа на 30% и увеличением сложности кода на 41%. Исследование охватывает проекты с открытым исходным кодом и один инструмент, поэтому оно не описывает каждую корпоративную команду или ИИ-агент, но оно четко показывает риск. Долг такого рода обходится дорого в двух отношениях: он замедляет работу инженеров, поддерживающих код, и увеличивает стоимость каждого последующего запуска агента, которому приходится с ним работать.
Инциденты. Проблемы, прошедшие ранние этапы, в конечном итоге доходят до клиентов. Метрики DORA 2024 research связали каждое увеличение внедрения ИИ на 25% с предполагаемым снижением стабильности поставок на 7.2%, а их 2025 report показало, что ИИ все еще ассоциируется с растущей нестабильностью. Инциденты — это то место, где инженерные затраты превращаются в бизнес-затраты из-за упущенной выгоды, нарушения соглашений об уровне обслуживания (SLA), регуляторных рисков и внимания руководства, отвлекаемого от роста.
Как накапливаются затраты на написание кода с помощью ИИ?
Затраты на кодирование с помощью ИИ накапливаются, потому что четыре силы, хотя и отличные друг от друга, подкрепляют друг друга, когда никто не вмешивается. Неверифицированный код, покидающий цикл агента, может превратиться в переделку при ревью, а переделка, упускающая что-то, может превратиться в долг по устранению последствий. Этот долг усложняет изменение кодовой базы как для людей, так и для агентов, что удлиняет следующий цикл и увеличивает следующий счет за токены, а дефекты, избежавшие всего этого, становятся инцидентами. Результатом являются затраты, которые растут с каждым циклом, выполняемым без верификации, и проблема, на исправление которой внутри цикла агента ушли бы минуты, может в конечном итоге превратиться в разбор полетов после инцидента (postmortem).
Почему пропускная способность — это цифра, которая имеет значение?
Скорость генерации — это самый простой для сбора показатель, что, вероятно, и является причиной его появления на стольких дашбордах, но это также и показатель, менее всего связанный с ценностью.
Пропускная способность — это скорость, с которой верифицированные, работающие изменения достигают продакшена, и она держится на уровне, когда скорость и стабильность улучшаются одновременно. Данные DORA иллюстрируют риск, когда они расходятся: в 2024 году увеличение внедрения ИИ на 25% было связано с предполагаемым снижением пропускной способности поставок на 1.5% наряду с падением стабильности. К 2025 году связь с пропускной способностью стала положительной, в то время как связь с нестабильностью сохранилась. DORA описывает ИИ как усилитель, который преувеличивает сильные стороны надежных систем поставки и слабости ненадежных.
Любой, кто стоял в очереди в супермаркете с одной открытой кассой, уже знает этот принцип: линия движется только так быстро, как ее самая медленная точка. Агенты переместили эту самую медленную точку с написания кода на его верификацию. Каждое изменение, возвращающееся в цикл для еще одной попытки, повторно потребляет пропускную способность этого этапа, поэтому сокращение таких циклов является одним из наиболее прямых способов повышения пропускной способности там, где она ограничена.
В этом заключается экономическое обоснование верификации. При хорошем выполнении она защищает скорость ИИ, давая ей шанс дожить до поставки, и работающая программа верификации проявляется в виде растущей пропускной способности и падающей стоимости одного принятого изменения. Количество обнаруженных ею проблем говорит гораздо меньше о том, работает ли она.
Как команды могут сократить переделки в агентной разработке?
Единого переключателя, который решает эту проблему, не существует, но пять практик дают измеримый результат при совместном применении.
1. Направляйте агентов до того, как они начнут писать код. Множество повторных попыток начинается с того, что агенту не хватает контекста о вашей архитектуре и стандартах. Предоставление этого контекста заранее повышает качество с первой попытки и избавляет от необходимости исследовать кодовую базу, что увеличивает затраты на токены.
2. Выполняйте проверку внутри цикла агента. Проверяйте код по мере его генерации, чтобы проблемы обнаруживались, пока агент еще работает над изменением. Агент, который видит уязвимость безопасности или логическую ошибку в процессе написания, может исправить ее до того, как изменение попадет к проверяющему, в то время как та же ошибка, обнаруженная на этапе ревью, требует целого цикла доработки, а в продакшене она приводит к инциденту.
3. Применяйте к каждому изменению единый независимый стандарт перед слиянием. Команды наиболее надежно сокращают объем доработок, когда применяют единый детерминированный стандарт качества и безопасности как к человеческому, так и к сгенерированному ИИ коду, причем этот стандарт проверяется системой, отдельной от той, которая создала код, поскольку модель, оценивающая собственный результат, не может обеспечить независимую верификацию. Исследования DORA также указывают на небольшие размеры пакетов изменений (batch sizes) и надежное тестирование как на фундаментальные факторы, определяющие, улучшает ли ИИ поставку, поэтому имеет смысл сохранять изменения достаточно маленькими для качественного ревью.
4. Автоматически исправляйте то, что обнаруживает проверка. Замечания, которые ожидают своего часа в бэклоге, превращаются в техдолг, поэтому устраняйте их на этапе пулл-реквеста при сбое Quality Gate (контроля качества) и непрерывно сокращайте существующий бэклог, повторно проверяя каждое исправление до того, как его увидит разработчик.
5. Отчитывайтесь по метрикам, которые связывают расходы на ИИ с поставленной ценностью. Замените метрики активности метриками разработки ПО, которые финансовый директор может проверить, такими как стоимость принятого изменения, процент принятия с первой попытки, время от первого черновика до слияния, уровень переделок, частота сбоев изменений и динамика бэклога исправлений. Эффективность цикла CI (непрерывной интеграции), то есть доля проблем, выявленных до слияния, является опережающим индикатором для всех них.
Но дает ли верификация реальный результат?
Это справедливый вопрос, особенно когда верификация кажется еще одним шагом между агентом и слитым пулл-реквестом. Организации, которые проводят верификацию систематически, сообщают о лучших результатах. В отчете 2026 State of Code Developer Survey пользователи SonarQube на 44% реже сообщали об инцидентах в продакшене, вызванных сгенерированным ИИ кодом. Они также чаще, чем не-пользователи, отмечали положительное влияние ИИ на затраты на переделки и исправления (47% против 40%) и показатели дефектности (44% против 37%), при этом аналогичный разрыв наблюдался и в отношении уровня уязвимостей (39% против 31%).
Затраты также зависят от качества. Как мы видели ранее, исследование Sonar показало, что агенты, работающие в более здоровых кодовых базах, использовали на 7.2% меньше входных и на 8.5% меньше выходных токенов для выполнения тех же задач, что делает качество кода самостоятельным рычагом управления затратами на ИИ. Контекст оказывает дополнительное влияние: когда Sonar Vortex предоставляет агентам точный и управляемый контекст, вместо того чтобы заставлять их искать файлы в кодовой базе по одному, исследования Sonar показывают снижение потребления токенов до 36% при задачах рефакторинга.
Как Sonar помогает превратить скорость ИИ в готовое программное обеспечение?
Sonar обеспечивает независимую верификацию ИИ-кода на протяжении всего цикла разработки с участием агентов — от первого черновика агента до главной ветки, причем каждая функция нацелена на определенный аспект:
- Sonar Vortex предоставляет агентам стандарты вашего проекта и контекст кодовой базы до того, как они начнут писать код, а затем проверяет их результат в процессе работы, что сокращает количество повторных попыток и сопутствующие затраты на токены.
- SonarQube выполняет детерминированный анализ более чем для 40 языков с уровнем ложноположительных срабатываний 3.2%, а его шлюзы качества (quality gates) обеспечивают соблюдение единого стандарта для каждого пулл-реквеста, независимо от того, написал ли код человек или агент, что сокращает объем переделок и следующие за ними инциденты.
- Gitar проверяет каждый пулл-реквест, диагностирует сбои CI, а затем итеративно работает над исправлениями до тех пор, пока сборка не пройдет успешно, сокращая время от первого черновика до слияния.
- SonarQube Remediation Agent генерирует исправления при сбое шлюза качества и в фоновом режиме сокращает существующий бэклог, повторно проверяя каждое исправление до открытия пулл-реквеста, благодаря чему бэклог со временем уменьшается, а не накапливается.
В совокупности эти возможности дают времени, сэкономленному ИИ при генерации, гораздо больше шансов дойти до продакшена в виде работающего программного обеспечения, поставляемого быстрее и с меньшими затратами на одно изменение.
С чего начать
Сгенерированный ИИ код становится бизнес-ценностью только тогда, когда он попадает в продакшен и успешно там работает. Повторные попытки, переделки, устранение неполадок и инциденты — это то место, где эта ценность теряется, и эти проблемы накапливаются, если их не контролировать, поэтому чем раньше вы их обнаружите, тем большую часть инвестиций в ИИ вы сохраните.
Если вы готовите бюджет на ИИ на следующий год, начните с измерения того, какая доля сгенерированных ИИ изменений доходит до релиза и остается в нем, и во сколько обходится каждое из таких изменений. Эта базовая линия расскажет об окупаемости вашего ИИ-кодинга больше, чем любой подсчет строк сгенерированного кода, и даст вам нечто осязаемое, что можно показать финансовому отделу, как только верификация начнет менять эти показатели.
Начните сокращать потери от ИИ-кодинга с помощью Sonar.
