TL;DR
Исследователи сравнили инфраструктурный код (Terraform, Kubernetes, CloudFormation), который пишут LLM, с кодом, который пишут живые инженеры — и разложили "размышление" модели на три режима: обычная генерация, промпт «думай по шагам» и встроенный reasoning-режим вендора (тот самый переключатель "thinking" у Claude или "reasoning effort" у ChatGPT).
Главная находка: код от LLM содержит в 3,2–3,9 раза больше уязвимостей на ресурс, чем человеческий — и это стабильно для всех моделей, вендоров и режимов. Разрыв сильнее всего на простых задачах: если человек пишет один ресурс с одной ошибкой, модель на той же простой задаче накидывает лишних настроек и лишних дырок — почти 5 раз хуже. И ещё важнее: если попросить модель «think step by step» в промпте — это не помогает вообще (разница статистически незначима). Помогает только настоящий, вычислительный reasoning-режим вендора — но и тот снижает уязвимости всего на 12–14%, потому что на такой задаче модель тратит на "размышления" меньше 1% своего токен-бюджета. Проще говоря: она даже не пытается всерьёз думать про безопасность, просто у неё есть чуть больше шансов заметить проблему.
Вывод простой: если просишь модель написать инфраструктурный код или любой другой код, где критична безопасность — включай реальный reasoning-режим модели, а не пиши "рассуждай шаг за шагом" в тексте промпта. И явно прописывай требования безопасности, потому что по умолчанию модель их не додумывает.
Схема того, что тестировали
РЕЖИМ 1: Обычная генерация → просто просишь код
РЕЖИМ 2: Промпт-CoT → добавляешь в промпт "думай по шагам перед кодом"
РЕЖИМ 3: Extended thinking → включаешь встроенный reasoning-тоггл модели (API-параметр)
Каждый режим → сравнили с кодом, который написали живые инженеры (634 шаблона)
Это не многошаговый метод, а три разных способа заставить модель "думать", которые исследователи сравнили между собой.
Пример применения
Задача: Просишь Claude или ChatGPT написать конфигурацию облачного хранилища для стартапа — например, S3-бакет в AWS для хранения файлов пользователей.
Промпт:
Напиши Terraform-код для AWS, который создаёт S3-бакет для хранения
пользовательских файлов сервиса.
Обязательно учти:
- Шифрование данных (encryption at rest)
- Запрет публичного доступа к бакету
- Минимальные IAM-права (только то, что реально нужно приложению)
- Логирование доступа к бакету
После кода отдельным списком напиши:
1. Какие риски безопасности ты закрыл явно
2. Какие остаются на дефолтных настройках — и почему это может быть опасно
Результат: Модель выдаст Terraform-код и отдельный список рисков. Если у тебя включён режим "extended thinking" (не просто текст "думай по шагам", а реальный тоггл в интерфейсе Claude или reasoning-режим в ChatGPT) — итоговый код будет ощутимо чище по части сети, прав доступа и шифрования, чем без него.
Почему это работает
Слабость LLM: без явного указания модель генерирует "рабочий" код, а не "безопасный". Она не додумывает дефолты — открытый доступ, широкие права, отсутствие шифрования — потому что задача была сформулирована как "сделай, чтобы работало", а не "сделай безопасно".
Сильная сторона LLM: модель хорошо реагирует, когда ей явно называют критерии — категории, где чаще всего косячат и модели, и люди: сеть, права доступа (IAM), шифрование, логи. Если эти категории назвать вслух в промпте, у модели есть на что опереться.
Как это использовать: промпт «думай по шагам» — это просьба написать текст рассуждения, а не команда моделью реально тратить вычисления на проверку. Настоящий reasoning-режим — это отдельный вычислительный бюджет, который модель тратит на обдумывание перед тем, как выдать ответ. Разница именно в этом: слова "думай" в тексте промпта ничего не включают технически, а тоггл reasoning — включает.
Рычаг управления: если в интерфейсе есть переключатель "extended thinking" / "reasoning effort" — используй его для задач, где важна точность и безопасность (код, договоры, финансовые расчёты), а не пытайся эмулировать его текстом в промпте.
Шаблон промпта
Напиши {тип_кода_или_конфигурации} для {задача}.
Обязательно учти следующие требования:
- {требование_1: например, шифрование данных}
- {требование_2: например, минимальные права доступа}
- {требование_3: например, закрытый доступ по умолчанию}
- {требование_4: например, логирование и мониторинг}
После кода отдельным списком укажи:
1. Какие риски ты закрыл явно
2. Какие остаются на дефолтных настройках — и почему это может быть опасно
Подставляй в {требование} конкретные критерии под свою задачу — не только для кода: то же самое работает для договоров ("проверь на риски для арендатора"), финансовых расчётов ("укажи, где округление может исказить итог") и любых задач, где модель может незаметно срезать углы.
🚀 Быстрый старт — вставь в чат:
Вот шаблон промпта для генерации критичного кода/документа с явным
контролем рисков. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие именно риски важны для твоей задачи — потому что без этого шаблон превращается в общие слова.
Ограничения
⚠️ Узкий домен: Все цифры получены на инфраструктурном коде (Terraform, Kubernetes и похожее). Для обычных текстовых задач разница между «думай по шагам» и настоящим reasoning-режимом может быть другой — в математике, например, прошлые исследования показывают, что CoT-промпт всё-таки работает.
⚠️ Reasoning не панацея: даже включённый extended thinking снижает уязвимости всего на 12–14%. Модель всё равно генерирует код в разы менее безопасный, чем человек. Один reasoning-тоггл проблему не решает.
⚠️ На сложных задачах эффект не подтверждён: на многокомпонентных сценариях данных оказалось слишком мало, чтобы статистически доказать эффект reasoning — хотя направление совпадает с простыми задачами.
⚠️ Чек-лист безопасности в промпте — не проверенный авторами приём, это логичное следствие находок про категории дефолтных ошибок (сеть, права, шифрование, логи), а не прямой результат эксперимента.
Как исследовали
Исследователи сгенерировали почти 1200 файлов инфраструктурного кода двенадцатью конфигурациями моделей — Claude, GPT, Gemini и открытые модели — по 100 сценариям разной сложности. Каждый файл прогнали через три независимых сканера безопасности, чтобы не зависеть от предвзятости правил одного инструмента.
Ключевой ход: они собрали 634 реальных шаблона, написанных живыми инженерами, и прогнали через тот же тулчейн — без этого шага нельзя понять, действительно ли модели пишут более уязвимый код, или просто генерируют больше кода, где больше шансов найти хоть что-то. Оказалось, что чем больше файл, тем ниже плотность уязвимостей на ресурс — и это работает одинаково и для людей, и для моделей. Поэтому все сравнения делали только между файлами одинакового размера.
После такого выравнивания результат оказался неожиданно стабильным: независимо от вендора, размера модели и режима reasoning, все конфигурации легли в узкий диапазон 3,2–3,9 раза хуже человеческого уровня. Отдельно исследователи изолировали переменную reasoning на одной и той же модели (три версии Claude), чтобы отличить эффект текстового промпта от эффекта настоящего вычислительного бюджета — и увидели, что текстовый CoT почти ничего не даёт, а настоящий reasoning даёт скромный, но статистически значимый эффект, ограниченный тем, что модель тратит на размышления меньше 1% токенов.
Ресурсы
Animesh Shaw, IIM Kozhikode. GenIaC-SecBench: A Human-Anchored Security Benchmark for LLM-Generated Infrastructure-as-Code. Инструменты сканирования: Checkov, Trivy, KICS. Статистический метод: Skillings–Mack test (обобщение теста Фридмана для неполных данных).