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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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