LLM не справляются с небезопасным Rust: полгода тестирования показал критические ошибки

Автор давал LLM писать unsafe Rust код в боевых проектах полгода и проверял каждый блок Miri и санитайзерами. Результат разочаровал: модели делают одни и те же ошибки предсказуемо и стабильно.

Семь категорий ошибок LLM в unsafe

Rust Модели постоянно допускают ошибки в одних и тех же местах: Aliasing — нарушение правила о неперекрывающихся ссылках Provenance — попытки использовать указатели, полученные неправильно Layout при alloc/dealloc — несоответствие размера/выравнивания при выделении и освобождении ManuallyDrop — забывают вызвать drop или обращаются с объектом после drop Гонки в FFI-колбэках — race conditions при вызове C-функций из потоков Ручные Send/Sync — неправильно реализуют трейты потокобезопасности * Uninit-память — обращаются к неинициализированным данным как к инициализированным ## Почему Miri раскрыл проблемы Miri — интерпретатор Rust, который отслеживает undefined behavior. Когда LLM генерирует код с незаметными на первый взгляд нарушениями (например, временный указатель с неправильным провенансом), обычный компилятор пропускает, а Miri ловит. Под санитайзерами (AddressSanitizer, ThreadSanitizer) вскрывались гонки и use-after-free, которые в обычных тестах могут не проявиться.

«Каждая категория идёт с минимальным примером и фиксом» — автор

показывает, что это не просто наблюдения, а воспроизводимые паттерны ошибок.

Что это значит LLM пока не готовы писать unsafe Rust без человеческого контроля.

Они хорошо генерируют синтаксис и общую логику, но в области работы с памятью и многопоточностью систематически ошибаются. Для критичного кода (системное ПО, системные библиотеки) unsafe Rust от моделей нужно обязательно проверять под Miri.