# У ИИ-ускорения есть счёт за безопасность

Gartner говорит, что 90% инженерных руководителей видят выигрыш от ИИ-инструментов для кода — чистый прирост продуктивности около 19%. То же исследование говорит: у непроверенного ИИ-кода на 23% выше плотность багов, а 14,3% сгенерированных фрагментов несут уязвимости против 9,1% у написанного человеком. Эти две цифры почти никто не ставит в одно предложение. А зря — это одна и та же история.

- **Author:** Фёдор Чищин
- **Published:** 2026-06-19
- **Tags:** security, methodology
- **Source:** https://fedorthinks.com/ru/blog/the-speedup-has-a-bill

---

Две цифры из одного и того же [исследования Gartner](https://www.gartner.com/en/articles/enterprise-ai-coding-agent-market),
и их почти никогда не цитируют вместе. Первая: 90% инженерных руководителей видят улучшения от
ИИ-инструментов для кода, чистый прирост продуктивности около **19%.** Вторая: у непроверенного
ИИ-кода **на 23% выше плотность багов**, а **14,3% сгенерированных фрагментов содержат уязвимости**
против 9,1% у кода, написанного человеком.

Первая цифра идёт в заголовок. Вторая — в отчёт об инциденте через полгода. Им место в одном
предложении.

## Ускорение реально — и долг тоже

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

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

## «Непроверенный» — несущее слово

Заметьте, где живёт цифра про плотность багов: в **непроверенном** ИИ-коде. Вот подсказка. Дефекты —
не врождённое свойство тупой модели; это то, что получаешь, когда скорость генерации убегает вперёд
верификации. Быстрое письмо без сопоставимого роста проверки — это просто быстрое накопление
неосмотренного риска.

Это та же мысль, к которой я постоянно прихожу: когда агент пишет большую часть кода, твой рычаг
переезжает в ревью. Ускорение — _валовое._ Чистое — это валовое минус то, во что обойдутся
непроверенные баги потом, а «потом» — это место, где уязвимости дороже всего.

## Как сохранить скорость и погасить счёт

Это чинится не замедлением. Это чинится тем, что проверка масштабируется вместе с письмом:

- **Сделайте ревью осознанным и измеримым.** Не взгляд, а настоящий гейт, который выдаёт сигнал до
  мёржа. Чем быстрее генерируешь, тем это важнее.
- **Добавьте проверки именно на безопасность.** Доля уязвимостей _выше_, а не ниже, — значит,
  опирайтесь на SAST и второй моделью ред-тимьте дифф. Не считайте код безопасным потому, что он
  запускается.
- **Стройте проверяемый код намеренно.** Принципы вроде SOLID, DRY и KISS здесь не эстетика; чистый
  структурированный код — это код, который человек или агент реально может верифицировать. Халтура
  прячет баги.
- **Меряйте долю дефектов рядом со скоростью.** Будете мерить только ускорение — оптимизируете цифру,
  которая вам льстит, и проигнорируете ту, что выставляет счёт.

## Итог

Выигрыш в продуктивности от ИИ-кода настоящий. И идёт он с измеримым ростом багов и уязвимостей,
который победная версия удобно опускает.

**+19% к скорости и +14% к доле уязвимостей — это одна история, так что цитируйте их вместе и
гасите счёт ревью.** Масштабируйте проверку так же быстро, как генерацию, жёстко опирайтесь на
ревью безопасности и держите код достаточно чистым, чтобы его можно было осмотреть. Ускорение
реально. Счёт — тоже.