Как измерить эффект AI‑кодинга без роста security debt

Семь метрик, которые сводят скорость и риск в одну рамку — от PR size до release confidence

Почему обычных метрик больше не хватает

Команда внедрила AI-ассистент. Через квартал CTO видит в дашборде красивые цифры: PR merged за день, acceptance rate 68%, deployment frequency выросла в полтора раза. Кажется, всё работает.

Потом приходит Security. Открытых critical CVE стало вдвое больше. Hotfix-релизов — на треть больше, чем год назад. Change failure rate — 18% там, где было 10%. AppSec-команда говорит, что не успевает разбирать очередь.

Это не противоречие. Это следствие измерения разных вещей разными людьми. Метрики скорости и метрики безопасности живут в разных системах, в разных командах и в разных разговорах. AI-кодинг сделал разрыв между ними критически опасным.

Эта статья — практический гайд для CTO, VP Engineering, Tech Lead и AppSec-команд: как свести speed и risk в одну рамку измерений, чтобы понимать реальный эффект AI-ассистентов, а не только удобную его часть.

Часть 1. Что сломалось в стандартных метриках с приходом AI

"Ложный позитив" в DORA

DORA-метрики — deployment frequency, lead time for changes, change failure rate (CFR), failed deployment recovery time — стали стандартом для DevOps-команд за последнее десятилетие. В 2024–2025 годах DORA добавила пятую метрику: rework rate — долю незапланированных деплоев из-за production-инцидентов [1].

На практике AI-кодинг создаёт парадокс в этих данных: deployment frequency растёт, lead time сокращается — и кажется, что всё хорошо. Но research DORA 2026 зафиксировал, что рост AI-adoption связан с ростом delivery instability [2]. Это значит, что классические throughput-метрики не отражают реальное качество процесса.

Конкретные данные Cortex (Benchmark Report, 2025): PRs per author выросли на 20% год к году — и одновременно incidents per pull request выросли на 23,5%, а change failure rate — примерно на 30% [3]. PR merged successfully — это не PR без проблем. Это PR, прошедший CI-пайплайн. AI-код хорошо проходит автоматические проверки синтаксиса, форматирования и базовых тестов — именно потому, что обучен на паттернах, которые CI-системы обычно пропускают. Но архитектурные несоответствия, небезопасные паттерны авторизации и logic errors по-прежнему проходят.

"Ванильные" метрики AI-ассистентов

Lines of code generated, acceptance rate, number of AI completions — именно эти цифры чаще всего попадают в отчёты руководству. Но они ничего не говорят о том, что происходит с кодом дальше: выживает ли он в ревью, доходит ли до прода, ломает ли что-нибудь [4].

Опрос JetBrains (2025): 66% разработчиков убеждены, что текущие метрики не отражают их реального вклада [5]. Если сами инженеры не доверяют измерениям — это системная проблема, а не вопрос настройки дашборда.

Jellyfish (2025): только 20% команд используют engineering metrics для оценки влияния AI — при том, что 90% команд уже используют AI в рабочем процессе [6]. Инвестируют все, измеряют единицы.

Часть 2. Семь метрик единой рамки

Задача не в том, чтобы создать новый дашборд ради дашборда. Задача — выбрать минимальный набор индикаторов, каждый из которых отвечает на конкретный операционный вопрос. Ниже — семь таких метрик и их связь с реальным риском.

1. PR Size (размер pull request)

Что измеряем: количество изменённых файлов и строк на один PR; динамика в сравнении с до-AI периодом.

Почему важно: Apiiro проанализировала кодовые репозитории Fortune 50 и обнаружила, что AI-assisted developers производят в 3–4× больше коммитов, чем их коллеги без AI — но эти коммиты упаковываются в меньшее количество PR, каждый из которых значительно крупнее по охвату и затрагивает больше файлов и сервисов [7]. Именно это делает каждый merge более опасным: blast radius одной проблемы растёт вместе с размером PR.

Большие PR разрушают review-процесс не потому, что люди ленятся. Человеческое внимание не масштабируется линейно с объёмом кода — рецензент дочитывает diff из 500 строк принципиально иначе, чем diff из 50. Уязвимость, которую легко заметить в компактном изменении, теряется в потоке.

Операционный вывод: если средний PR size растёт с внедрением AI — это ранний сигнал, что review-процесс перегружен. Необходимо ввести правило максимального размера PR или разбивки агентских задач на атомарные изменения.

2. Review Latency (время от открытия PR до merge)

Что измеряем: медиана и 90-й перцентиль времени от открытия PR до merge; доля PR с review latency выше порогового значения (например, >24 часов, >3 дней).

Почему важно: исследование CodeRabbit (2025), проанализировавшее 470 open-source PR, показало, что AI-co-authored PRs содержат в среднем 10,83 issues против 6,45 у человекописанных — то есть в ~1,7× больше [8]. При этом high-issue outliers значительно чаще встречаются именно в AI-PR, создавая тяжёлую нагрузку на рецензентов.

Следствие: review latency растёт — не потому что разработчики медлят, а потому что объективная плотность проблем выше. Это создаёт backlog. Рецензент, работающий с перегруженной очередью, начинает прокликивать PR без глубокого разбора — и это прямой путь к production-инцидентам.

CodeRabbit также выявил, что performance inefficiencies (избыточный I/O и подобное) встречаются в AI-PR почти в 8× чаще, чем у людей [9]. Такие проблемы редко блокируют CI, но стабильно ухудшают production-производительность после релиза.

Операционный вывод: растущая review latency при росте PR throughput — признак review debt, а не эффективности. Это означает, что команда не успевает качественно проверять то, что AI генерирует.

3. Code Churn (короткоживущий код)

Что измеряем: процент кода, пересмотренного или удалённого в течение двух недель после коммита.

Почему важно: GitClear проанализировала 211 миллионов изменённых строк кода из репозиториев Google, Microsoft, Meta и корпоративных клиентов за 2020–2024 годы. Churn (доля нового кода, пересмотренного в течение двух недель) вырос с 5,5% в 2020-м до 7,9% в 2024-м [10]. Доля рефакторинга (moved code) упала с 25% в 2021-м до менее чем 10% в 2024-м — падение на 60%. Копипаст (copy/pasted lines) впервые в истории превысил долю moved code.

Это не проблема конкретного инструмента — это системный паттерн. AI-ассистент оптимизирован для скорости генерации, а не для долгосрочной поддерживаемости кода. Профессор MIT Armando Solar-Lezama описал это так: AI — это кредитная карточка, которая позволяет накапливать технический долг со скоростью, недостижимой для людей [11].

Высокий churn — прямой индикатор того, что команда тратит время на исправление недавно сгенерированного кода вместо развития продукта. Если время на коррекцию превышает время на генерацию — производительность становится отрицательной, несмотря на видимость активности в метриках.

Операционный вывод: churn выше 8% на AI-сгенерированном коде — сигнал о системной проблеме с качеством или с контекстом, который получает модель. Необходимо пересмотреть prompt-стратегии и политику ревью.

4. Hotfix/Rollback Rate (частота экстренных исправлений)

Что измеряем: доля деплоев, потребовавших немедленного вмешательства в виде hotfix или rollback; rework rate (доля незапланированных деплоев из-за production-инцидентов).

Почему важно: DORA в 2024 году уточнила формулировку: change failure rate — это деплои, потребовавшие немедленного вмешательства (rollback или hotfix), а rework rate — деплои, которые были незапланированными, но произошли из-за production-инцидента [1]. Вместе эти две метрики дают полную картину delivery instability.

Высокий hotfix/rollback rate при растущем deployment frequency — классическая ловушка AI-кодинга. Команда ускоряется, но стабильность падает. DORA 2024 зафиксировал: 25% рост AI-usage связан с ростом скорости code review и документации — и одновременно с падением delivery stability на 7,2% [12]. Эти тренды не противоречат друг другу: они описывают одно и то же явление с разных сторон.

Для высококритичных систем CFR ниже 2% считается показателем высокоэффективных команд, по данным DORA 2025 Survey [13]. Ориентир реалистичный, но 15% команд при сбоях тратят на восстановление более недели [14].

Операционный вывод: если после внедрения AI-ассистентов hotfix rate растёт — значит, проблемы не поймали до merge. Это вопрос не только скорости, но и того, где именно в процессе происходит контроль.

5. Blocked Criticals (число критических уязвимостей, остановленных до прода)

Что измеряем: количество критических (CVSS ≥ 7.0) уязвимостей, выявленных и заблокированных до merge или релиза; trend по времени.

Почему важно: Apiiro исследовала Fortune 50 предприятия и зафиксировала рост security findings с 1 000 до 10 000+ в месяц с декабря 2024 по июнь 2025 — то есть 10-кратный рост за полгода [7]. Только за этот же период число privilege escalation paths в AI-генерированном коде выросло на 322%, design flaws — на 153%, secrets exposure — на 40%.

Veracode (2025 GenAI Code Security Report), протестировавшая 100+ LLM на 80 задачах: 45% всех AI-сгенерированных кодовых примеров вводят уязвимости из OWASP Top 10 [15]. Java — самый рискованный язык: failure rate превышает 70%. Устойчивый паттерн: LLM выбирают небезопасный метод в 45% случаев, когда у них есть выбор между безопасным и небезопасным вариантом. И это не улучшается с ростом мощности моделей — Veracode прямо отмечает, что security performance не коррелирует с датой выхода модели.

Критическая уязвимость, остановленная до merge, стоит условно ноль. Та же уязвимость в production — это инцидент-ответ, потенциальный breach, compliance-последствия и время команды. Blocked criticals — единственная метрика, которая показывает реальную работу защитного слоя, а не просто наличие инструментов.

Операционный вывод: если в команде нет метрики blocked criticals — нет и понимания, работает ли AppSec-процесс. Baseline надо установить до широкого внедрения AI, чтобы было с чем сравнивать.

6. Security Debt (накопленный долг по безопасности)

Что измеряем: количество high/critical уязвимостей, открытых дольше порогового срока (обычно 90 дней или 1 год); динамика накопления и скорость закрытия.

Почему важно: Veracode (2026 State of Software Security): 82% организаций несут security debt в 2026 году — рост с 74% в 2025-м. Critical security debt (high-severity flaws, не закрытые дольше года) — у 60% организаций, рост с 50% год назад [16]. High-risk vulnerabilities выросли на 36% год к году.

Среднее время исправления security flaw увеличилось с 171 дня в 2020-м до 252 дней в 2025-м — рост на 47% за пять лет [17]. Это означает, что инструменты для создания уязвимостей масштабировались значительно быстрее, чем инструменты для их исправления.

В финансовом секторе картина ещё хуже: 77% финансовых организаций несут security debt, 63% — critical debt, а 82% critical security debt приходит из third-party code и supply chain [18]. Это прямое следствие того, что AI-ассистенты активно используют зависимости — и зачастую включают транзитивные пакеты, которые никто не проверял.

Veracode определяет security debt как уязвимости, не закрытые более года. Это консервативное определение. На практике риск накапливается быстрее: 90 дней — уже значимый срок для exploitable flaws.

Операционный вывод: рост security debt на фоне роста AI-adoption — не случайность. Это прямое следствие того, что скорость генерации кода опередила скорость контроля. Метрику надо отслеживать в разрезе: first-party code vs. third-party dependencies, чтобы понимать, где именно концентрируется риск.

7. Release Confidence (уверенность в выпуске)

Что измеряем: составной индикатор готовности к релизу — процент критических уязвимостей, закрытых до выпуска; наличие заблокированных criticals в очереди; CFR за предыдущий период; наличие незакрытых production-инцидентов, связанных с текущей веткой.

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

Capgemini World Quality Report (2025): организации фиксируют средний прирост производительности в 19%, но треть участников видит минимальные или нулевые результаты — и ключевой фактор разрыва — это наличие или отсутствие управления качеством на финальном этапе [19]. Jellyfish (2025): 90% команд используют AI, но только 20% измеряют его влияние [6]. Release confidence — это попытка восполнить этот пробел без создания бюрократии.

Операционный вывод: release confidence не заменяет детальные security-отчёты, но позволяет за секунды получить ответ на ключевой вопрос перед деплоем. Длинный SAST-отчёт за 10 минут до релиза никто не читает. Короткий статус с тремя индикаторами — читает каждый.

Часть 3. Где в процессе должны жить эти метрики

Проблема смещения контроля вправо

Исторически security-проверки жили в конце: QA, penetration testing, pre-production scan. С ростом скорости разработки этот подход перестал работать — не потому что инструменты плохие, а потому что к моменту финальной проверки цена исправления выросла кратно.

С AI-кодингом ситуация стала ещё острее. CodeRabbit в своём анализе сформулировал точно: если review-процесс не успевает за объёмом кода, который генерирует AI — команда не получила velocity, а создала bottleneck [4]. PR merge стал узким местом качества — не потому что люди стали хуже, а потому что объём и сложность изменений выросли.

Три критические точки контроля

Первая точка — до генерации кода. Здесь имеет смысл определять политики: какие категории задач можно делать с AI без дополнительного review, какие требуют обязательной проверки безопасности. Работа с аутентификацией, IAM, secrets, конфигурациями cloud-инфраструктуры — это категории повышенного риска, требующие особого внимания.

Вторая точка — до merge. Именно здесь концентрируется основная работа. Это точка, в которой ещё можно остановить изменение без последствий для production. SAST, SCA, анализ новых зависимостей, проверка конфигов и CI/CD-файлов — всё это должно работать автоматически на уровне PR, а не только в плановых сканах.

Инструменты вроде Semgrep, SonarQube, Snyk и их аналоги работают на этом уровне. Но у них есть фундаментальная проблема: они генерируют noise. По данным SecurityInfoWatch, в 2025 году ожидается до 50 000 новых CVE, большинство помечены как high или critical — и команды буквально тонут в предупреждениях, среди которых реальных угроз меньшинство [20]. Это и есть alert noise — метрика номер шесть в нашей рамке.

Третья точка — до релиза. Это финальный gate: не длинный security-отчёт, который никто не читает за 10 минут до деплоя, а короткий ответ на вопрос "что реально блокирует выпуск прямо сейчас". Release confidence как метрика живёт именно здесь.

Именно в этой логике работает HighVibe — как дополнительный слой контроля до merge и до релиза: анализ конкретного изменения и его контекста, короткий и понятный сигнал вместо длинного отчёта, практический ответ о том, можно ли безопасно принять это изменение сейчас. Не замена SAST/SCA/SBOM, а дополнение к ним — там, где классические инструменты дают или слишком много шума, или слишком мало контекста.

Часть 4. Типичные ошибки при измерении эффекта AI-кодинга

Ошибка 1: Считать acceptance rate показателем качества

Высокий acceptance rate говорит только о том, что разработчики принимают предложения AI. Он не говорит ничего о том, что происходит с этим кодом в review, в тестировании и в production. CodeRabbit прямо указывает: acceptance rate — это сигнал доверия к инструменту, но не качества кода [4].

Ошибка 2: Игнорировать третьесторонние зависимости

82% critical security debt в финансовом секторе приходит из third-party code [18]. AI-ассистенты активно используют внешние пакеты — и не всегда существующие. Феномен package hallucinations (генерация несуществующих npm/pip-пакетов) документирован и может привести к typosquatting-атакам. SCA-проверки и анализ lock-файлов — обязательны.

Ошибка 3: Смотреть на deployment frequency в отрыве от CFR

Deployment frequency растёт — хорошо. Но если CFR растёт пропорционально — это не velocity, это нестабильность с высокой частотой. Эти две метрики нужно смотреть вместе, в динамике.

Ошибка 4: Не разделять "работает" и "безопасно"

AI хорошо обучен генерировать синтаксически корректный, функционально работающий код. Именно поэтому он проходит CI. Именно поэтому PR merge rate высокий. Но "функционально работает" не равно "безопасно для merge и релиза". Veracode зафиксировала: LLMs последовательно выбирают небезопасный путь в 45% случаев при выборе между безопасным и небезопасным методом [15].

Ошибка 5: Относиться к alert noise как к неизбежному

Alert fatigue — одна из главных причин, по которым critical уязвимости проходят мимо команд: когда всё помечено как срочное, реально срочное теряется в потоке. Задача не в том, чтобы видеть больше сигналов, а в том, чтобы видеть правильные сигналы с правильным контекстом.

Часть 5. Практический фреймворк внедрения

Шаг 1: Установить baseline до широкого внедрения AI

Измерить текущий PR size, review latency, churn rate, hotfix/rollback rate, количество открытых critical/high уязвимостей и время их закрытия. Без этих данных невозможно понять, что изменилось после внедрения AI-ассистентов.

Шаг 2: Определить политику по категориям задач

Не все задачи несут одинаковый риск. CRUD-операции, UI-компоненты, вспомогательные утилиты — более низкий риск, достаточен стандартный review. Аутентификация, авторизация, работа с секретами, конфиги cloud, CI/CD-файлы, миграции БД — обязательны дополнительные проверки безопасности и более строгий review. Задокументировать политику и обеспечить её enforcement через автоматические gates.

Шаг 3: Встроить security-проверки в PR-процесс

Настроить SAST, SCA, проверку секретов как блокирующие шаги в CI на уровне PR — не только в плановых сканах. Определить, что является блокирующим (CVSS ≥ 7.0, hardcoded credentials, критические advisory), а что — рекомендательным. Сократить noise: чем меньше ложных срабатываний видит разработчик, тем выше вероятность, что реальные проблемы будут замечены.

Шаг 4: Ввести review checklist для AI-генерированного кода

CodeRabbit рекомендует специфические вопросы для AI-PR: есть ли обработка исключений, null-check, guardrails? Соответствует ли код локальным паттернам именования? Нет ли hardcoded credentials? Есть ли тесты с production-like inputs? Этот checklist не добавляет бюрократии — он фокусирует внимание ревьюера на категориях проблем, которые AI систематически пропускает [8].

Шаг 5: Настроить дашборд из семи метрик

Важно, чтобы метрики скорости и метрики риска были в одном месте. PR size и review latency рядом с blocked criticals и security debt — только так видна полная картина. Инженерные платформы (LinearB, Jellyfish, Swarmia) поддерживают кастомные метрики. SAST/SCA-инструменты дают данные по security. Задача — связать их в единый view.

Шаг 6: Проводить регулярные ретроспективы по quality-метрикам

Ежемесячный review: как изменился churn, изменилось ли time-to-fix security flaw, есть ли тренд на накопление security debt. Это не аудит, а инструмент обучения команды. Если видно, что конкретные типы задач стабильно генерируют проблемы с AI-кодом — пересмотреть политику для этой категории.

Часть 6. Что говорят данные о будущем

Тренды за 2024–2026 годы устойчивы и указывают в одном направлении: объём AI-generated кода будет расти, скорость генерации будет расти, и проблема измерения качества будет только острее.

GitClear прогнозирует, что при текущей динамике неуправляемый AI-generated код к концу второго года приводит к росту maintenance costs в 4× относительно базового уровня [10]. Forrester прогнозирует, что 75% tech decision-makers столкнутся с умеренным или серьёзным technical debt к 2026 году. Gartner — что prompt-to-app подходы приведут к росту software defects на 2 500% к 2028 году [21].

Это не аргументы против AI-кодинга. Это аргументы в пользу того, что контроль качества и безопасности должен масштабироваться вместе со скоростью. "2025 был годом AI speed. 2026 будет годом AI quality" — такую формулировку использовала команда CodeRabbit в конце 2025 года [8]. Это точное описание того, где находится индустрия.

DORA продолжает расширять рамку: новая метрика rework rate, более тонкое разделение throughput и stability, фокус на "reliability" как quasi-метрике [2]. Это движение в правильную сторону — от бинарного "быстро / медленно" к многомерной оценке delivery performance.

Заключение: что делать дальше

Измерение эффекта AI-кодинга без учёта security — это измерение половины картины. Скорость и риск — не противоположные полюса, между которыми надо выбирать. Это два измерения одного процесса, которые необходимо отслеживать вместе.

Семь метрик — PR size, review latency, code churn, hotfix/rollback rate, blocked criticals, security debt, release confidence — дают эту единую рамку. Ни одна из них не требует принципиально новой инфраструктуры. Большинство данных уже есть в существующих системах — они просто не собраны вместе и не отображаются рядом с метриками скорости.

Начать можно с малого: установить baseline по трём-четырём метрикам до следующего этапа расширения AI-adoption. Посмотреть, как меняется churn и review latency через квартал. Запросить у security-команды данные по blocked criticals за последние полгода. Это уже даст достаточно информации для содержательного разговора о том, где реально находится команда.

Источники

[1] DORA — "DORA's software delivery performance metrics" — https://dora.dev/guides/dora-metrics/

[2] DasRoot — "DevOps Metrics: DORA Metrics and Measuring Success" — https://dasroot.net/posts/2026/04/devops-metrics-dora-measuring-success/

[3] QASource — "AI-generated Code Security Risks: Why Incidents Per Pull Request Have Increased by 23.5%" — https://www.qasource.com/blog/ai-generated-code-security-risks

[4] CodeRabbit — "Measuring what matters in the age of AI-assisted development" — https://www.coderabbit.ai/blog/measuring-what-matters-in-the-age-of-ai-assisted-development

[5] JetBrains Research — "The State of Developer Ecosystem 2025" — https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/

[6] Jellyfish — "2025 AI Metrics in Review" — https://jellyfish.co/blog/2025-ai-metrics-in-review/

[7] Apiiro — "4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks" — https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/

[8] CodeRabbit — "State of AI vs Human Code Generation Report" — https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

[9] BusinessWire — "CodeRabbit's State of AI vs Human Code Generation Report" — https://www.businesswire.com/news/home/20251217666881/en/CodeRabbits-State-of-AI-vs-Human-Code-Generation-Report-Finds-That-AI-Written-Code-Produces-1.7x-More-Issues-Than-Human-Code

[10] GitClear — "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones" — https://www.gitclear.com/ai_assistant_code_quality_2025_research

[11] DevOps.com — "AI in Software Development: Productivity at the Cost of Code Quality?" — https://devops.com/ai-in-software-development-productivity-at-the-cost-of-code-quality-2/

[12] LeadDev — "How AI generated code compounds technical debt" — https://leaddev.com/technical-direction/how-ai-generated-code-accelerates-technical-debt

[13] Axify — "Complete Guide to Change Failure Rate [2026 Edition]" — https://axify.io/blog/change-failure-rate-explained

[14] Swarmia — "What the 2025 DORA report tells us about AI readiness" — https://www.swarmia.com/blog/dora-2025-report-ai-readiness/

[15] Veracode — "AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks" — https://www.businesswire.com/news/home/20250730694951/en/AI-Generated-Code-Poses-Major-Security-Risks-in-Nearly-Half-of-All-Development-Tasks-Veracode-Research-Reveals

[16] Veracode — "2026 State of Software Security: Risky Debt is Rising" — https://www.veracode.com/blog/2026-state-of-software-security-report-risky-security-debt/

[17] Veracode — "State of Software Security 2025" — https://www.veracode.com/resources/analyst-reports/state-of-software-security-2025/

[18] Security Magazine — "77% of Financial Service Organizations Accrued Security Debt in 2025" — https://www.securitymagazine.com/articles/102091-77-of-financial-service-organizations-accrued-security-debt-in-2025

[19] Capgemini — "World Quality Report 2025" — https://www.capgemini.com/news/press-releases/world-quality-report-2025-ai-adoption-surges-in-quality-engineering-but-enterprise-level-scaling-remains-elusive/

[20] SecurityInfoWatch — "Why Traditional Vulnerability Scoring Falls Short in 2025" — https://www.securityinfowatch.com/cybersecurity/article/55316020/why-traditional-vulnerability-scoring-falls-short-in-2025

[21] BuildMVPFast — "AI Generated Code Technical Debt: How to Manage It" — https://www.buildmvpfast.com/blog/ai-generated-code-technical-debt-management-2026