Из 6080 AI-патчей для шести свежих уязвимостей в open source только 26% закрыли дыру без побочных эффектов. Еще 20,1% формально убирали уязвимость, но по дороге меняли поведение приложения, а 53,9% результатов оказались дефектными в более неприятном смысле: баг оставался, появлялась новая дыра или случалось сразу оба сценария. Для русскоязычных команд, которые уже ставят LLM в цепочку разработки и AppSec, сигнал предельно ясный: скорость выросла, доверие к автозаплаткам — пока нет.
Поводом стал отчет исследовательской команды Off-by-1 Labs из 1Password, о котором 7 августа 2026 года как пишет Dark Reading. Исследователи взяли шесть недавно раскрытых уязвимостей в open source — среди них были проблемы в ActiveMQ, EXIM, SpringAI, Chrome, Linux и Gemini CLI — и прогнали через две frontier-модели с киберзащитными режимами: ChatGPT-5.5 with Trusted Access for Cyber и Anthropic Opus 4.8 with Cyber Verification Program. Всего система сгенерировала 6480 вариантов патчей; 400 случаев исследователи исключили из отчетной выборки, потому что модель, по их оценке, пыталась подтянуть готовое решение извне. На выходе остались те самые 6080 AI-патчей, которые и дали статистику, неприятную даже по нынешним меркам AI-хайпа.
Важна не только сама доля провалов, но и их характер. Исследователи разложили результаты по пяти сценариям: от полноценного исправления без изменения логики до патча, который не чинит ничего и еще подбрасывает новый риск. Самая тревожная деталь в том, что зеленый тестовый прогон здесь часто ничего не гарантирует. Больше трети даже формально успешных патчей исследователи назвали fragile — хрупкими. Иными словами, модель не лечит причину, а ставит заплатку ровно на тот вход, который видела в proof-of-concept. В одном из кейсов со SpringAI модель просто экранировала конкретные символы во входных данных, блокируя известную вредоносную строку, но не устраняя корень проблемы. Чуть меняется вход — и уязвимость здорова, просто ненадолго притворилась мертвой.
Это не единичный конфуз одной лаборатории. Контекст у рынка уже сложился, и он не слишком обнадеживает. Veracode недавно проверила более 100 моделей на 80 задачах и получила средний security pass rate на уровне 56%; в 44% случаев AI-код вносил детектируемые проблемы из OWASP Top 10. Картина складывается почти симметричная с 1Password: LLM заметно лучше научились выдавать правдоподобный код, чем безопасный и устойчивый код. Отсюда и неприятная асимметрия для защитников: находить и эксплуатировать баги AI уже помогает вполне бодро, а вот надежно чинить их — пока куда хуже. Не случайно даже OpenAI в своей инициативе Patch the Planet, запущенной 22 июня 2026 года вместе с Trail of Bits, изначально строит процесс вокруг экспертной верификации, а не вокруг полностью автономного ремонта.
На этом фоне особенно нервно выглядят привычки самих разработчиков. По данным Cursor, с начала 2026 года доля AI-сгенерированных изменений, которые доходят до коммита без отдельного ручного просмотра diff, выросла более чем в пять раз. Уже 26 марта показатель дошел до 36%, а в начале мая поднимался выше 38%. То есть индустрия одновременно получает два встречных движения: модели все еще ошибаются на уровне патчей, а люди все охотнее принимают их выводы без полноценной проверки. Для обычной фичи это уже риск. Для security-fix — почти приглашение к регрессии, обходу защиты или тихо приехавшей новой уязвимости, которую заметят только после релиза.
Практический вывод для команд довольно приземленный. AI-патчи имеет смысл воспринимать не как исправления, а как черновики исправлений. Их можно использовать, чтобы быстрее пройти первый круг: локализовать проблему, накидать гипотезы, собрать тесты, подготовить несколько вариантов правки. Но дальше начинается работа, которую модель пока не снимает с людей: функциональная и регрессионная проверка, анализ побочных эффектов, статический анализ на уровне всей программы, просмотр зависимостей и call path, а для чувствительных мест — ручной review инженером, который понимает предметную область. И да, это звучит скучнее, чем обещания «автономного AppSec». Зато дешевле, чем потом объяснять бизнесу, почему срочный security patch выключил прод или открыл обход в соседнем модуле.
Главный вопрос теперь не в том, смогут ли модели писать патчи быстрее человека. Смогут, и уже пишут. Вопрос в другом: кто и чем будет доказывать, что этот патч чинит причину, а не симптом, и не разносит систему по швам в другом месте. Похоже, следующая гонка в AppSec развернется не вокруг генерации кода, а вокруг генерации качественной верификации. Подробности исследования собраны в материале .