Положение дел — в цифрах и с источниками
К 2026 году несколько независимых работ перестали говорить о впечатлениях и начали измерять. Наиболее цитируемый вывод умещается в одну фразу: лишь около 35 % серверного кода, сгенерированного ИИ, одновременно безопасны И корректны согласно эмпирическим оценкам. Иными словами, в большинстве случаев произведённый код либо неверен, либо уязвим, либо и то и другое, даже когда он «выглядит» работающим.
Доля кода, содержащего хотя бы одну уязвимость, оценивается в 62–92 % в зависимости от исследования. Это широкий диапазон, и читать его следует именно так: методологии различаются (тестируемые языки, определение уязвимости, учитываемая критичность, корпус запросов). Ни одну отдельную цифру из этого диапазона не следует приводить изолированно, не указав исследование и его метод; честной информацией является диапазон, а не отдельная точка.
Риск не теоретический. «Vibe Security Radar» от Georgia Tech фиксирует резкое ускорение числа CVE, связанных с кодом, сгенерированным ИИ, в первом квартале 2026 года: 6 в январе, 15 в феврале, 35 в марте — то есть за эти три месяца больше, чем за весь 2025 год вместе взятый.
Что касается восприятия, недоверие следует за цифрами: 87 % разработчиков заявляют, что сомневаются в надёжности кода, сгенерированного ИИ. Те, кто пользуется им больше всех, зачастую первыми не доверяют ему вслепую.
Уточнение по методу, честности ради: этот корпус — это прежде всего отраслевые исследования по безопасности: отчёты компаний по безопасности, аудиты, бенчмарки, а не свод рецензируемой академической литературы. В нём насчитывается лишь одна по-настоящему академическая работа (статья на arXiv); остальное исходит из индустрии. Это не делает цифры ложными, но требует читать их как то, чем они являются: сходящиеся независимые измерения, а не устоявшийся научный консенсус.
Одну из этих работ стоит назвать, потому что она в точности задаёт рамку спора: независимый бенчмарк Vibe-Eval (2026) каталогизирует режимы отказа нескольких массовых генераторов — Lovable, Bolt, Cursor, Replit, v0 — по критериям безопасности приложений. Это именно та почва, на которой движок, публикующий датированную проверку во время выполнения, может помериться напрямую, а не отсылать к доверию.
- ~35 % серверного кода, сгенерированного ИИ, одновременно безопасны и корректны (эмпирические оценки).
- От 62 % до 92 % сгенерированного кода содержат уязвимости — широкий диапазон, разные методы.
- Связанные CVE: 6 → 15 → 35 в месяц (янв. → март 2026, Vibe Security Radar, Georgia Tech).
- 87 % разработчиков сомневаются в надёжности кода, сгенерированного ИИ.
Почему: вероятностная модель выдаёт правдоподобный код, а не гарантированный
Причина структурная, а не конъюнктурная. Большая языковая модель выдаёт наиболее вероятный токен с учётом контекста. Применительно к коду это даёт наиболее правдоподобное продолжение — не обязательно корректное и не обязательно безопасное. У модели нет внутреннего понятия «эта схема компилируется», «этот запрос параметризован», «этот контроль доступа существует»; у неё есть понятие «как выглядит код такого рода».
Именно это делает проблему коварной: галлюцинированный код правдоподобен. Он хорошо читается, иногда компилируется, разворачивается и отказывает в работе — или хуже того, внешне работает, оставляя при этом SQL-инъекцию, секрет в открытом виде, отсутствующую проверку авторизации. Повторяющиеся категории уязвимостей, задокументированные в исследованиях (инъекции, плохое обращение с секретами, отсутствие валидации ввода, нарушенный контроль доступа), — это как раз те, которые модель воспроизводит, потому что их изобилие в её обучающих данных.
Добавление указания в запрос («пиши безопасный код») смещает вероятности, но не меняет природу объекта: ничто не гарантирует результат, потому что ничто его не проверяет. Указание — не доказательство.
Различие, которое меняет всё: ИИ пишет спецификацию, а билдер компилирует код
Blueprint Maker исходит из этой констатации и отказывается позволять модели писать код. Конвейер разделяет две роли, которые ничто не обязывает смешивать. ИИ делает то, что умеет лучше всего: понимает предметную область бизнеса и производит структурированную спецификацию — схему сущностей, связей и правил в формате JSON. Он проектирует, а не программирует.
Затем детерминированные билдеры — написанные однажды, протестированные, версионированные — превращают эту спецификацию в код: схему базы данных, экраны, маршруты, панели. Таким образом, код никогда не «галлюцинируется» LLM: он производится программой, поведение которой известно. Свойства компонентов не угадываются, они выводятся из спецификации по фиксированным правилам. Одна и та же спецификация на входе всегда даёт один и тот же код на выходе.
Это разделение не устраняет магическим образом всякий риск, но переносит проблему туда, где она разрешима: вместо того чтобы надеяться, что вероятностная модель не внесла изъяна в тысячи уникальных строк, мы гарантируем по построению, что шаблоны кода (запросы, формы, проверки) выходят из единого, поддающегося аудиту генератора, который можно исправить раз и навсегда.
- ИИ → понимает область → производит спецификацию (не код).
- Детерминированные билдеры → компилируют спецификацию → производят код.
- Код не выводится моделью строка за строкой: он генерируется известной программой.
Предъявляемая защита: опубликованная проверка во время выполнения (K-15 / Health Score)
Писать код более безопасным методом остаётся обещанием, пока это не доказано. Решающее различие не в том, чтобы утверждать «наш код надёжен», а в том, чтобы измерить это и опубликовать измерение. Каждое приложение, произведённое Blueprint Maker, проходит автоматизированную проверку во время выполнения под названием K-15: код компилируется, приложение реально запускается, а затем проходится экран за экраном автоматизированным браузером. Критерий бинарный: оно работает или не работает.
Агрегированный результат — доля приложений, проходящих весь набор этих проверок в скользящем семидневном окне, — публикуется и датируется под названием Health Score. Это предъявляемая метрика надёжности: проверяемая, не декларативная, произведённая автоматическим судьёй, а не маркетинговым доводом.
Именно этого не публикует ни один чисто вероятностный генератор, и по фундаментальной причине: произвести такое измерение предполагает детерминированный, воспроизводимый способ тестировать каждый вывод в реальных условиях. Конвейер, который заставляет модель писать код и поставляет его как есть, не имеет систематического барьера времени выполнения, который можно было бы показать. Прозрачность в отношении надёжности возможна лишь тогда, когда надёжность построена так, чтобы быть измеримой.
Наши ограничения, честно
Проверка во время выполнения доказывает, что приложение собирается, запускается и корректно проходится; она резко сокращает класс ошибок «правдоподобный, но сломанный код». Она не заменяет полный аудит безопасности приложения, тест на проникновение или проверку соответствия. Blueprint Maker на сегодняшний день не заявляет о сертификации SOC 2 или ISO: мы предпочитаем публиковать реальную датированную метрику, а не логотип, который ничего не говорит о поставленном продукте.
Правильное прочтение таково: у кода, сгенерированного ИИ, есть измеренная проблема надёжности; единственный правдоподобный ответ — не обещание, а опубликованная проверка; разделение проектирования (ИИ) и изготовления (детерминированные билдеры) делает эту проверку возможной и воспроизводимой. Это фундамент, а не индульгенция, и он лучше, чем цифра, которую не показывают.
Источники
Cloud Security Alliance, Vibe Coding / AI Governance Gap: https://labs.cloudsecurityalliance.org/research/csa-research-note-vibe-coding-ai-governance-gap-20260602-csa/
The Security Crisis in AI-Generated Code (2026): https://blog.vibecoder.me/security-crisis-ai-generated-code-2026
IOActive, The Security Gap in AI-Generated Code: https://www.ioactive.com/wp-content/uploads/2026/05/IOA-The-Security-Gap-in-AI-Generated-Code.pdf
AppStuck, AI-Generated App Security Risks (2026): https://www.appstuck.com/blog/ai-generated-app-security-risks
Vibe-Eval, AI App Security Benchmark 2026: https://vibe-eval.com/data-studies/ai-app-security-benchmark-2026/
Sherlock Forensics, AI Code Security Report 2026: https://www.sherlockforensics.com/pages/ai-code-security-report-2026.html
OX Security, Vibe Coding Security: https://www.ox.security/blog/vibe-coding-security/
arXiv, Coding With AI: https://arxiv.org/pdf/2512.23982