 # LLM и Rust: полгода в проде — семь ошибок, которые не ловит компилятор Ключевой вывод: LLM научились писать красивый Rust-код, который проходит `cargo build` и `cargo test`, но ломается в продакшене. Это не баг — это математика. ## Что показал полугодовой эксперимент Разработчик использовал Claude, GPT и Cursor как полноценного второго программиста на Rust в production-проектах. Результат — семь категорий ошибок, которые стабильно воспроизводятся у разных моделей: 1. Логические ошибки в unsafe-блоках — модели не понимают тонкостей работы с сырыми указателями 2. Некорректная работа с lifetimes — особенно в сложных сценариях с вложенными ссылками 3. Ошибки в async-контексте — неправильная передача Pin и Future 4. Проблемы с Send/Sync — модели не учитывают требования к потокобезопасности 5. Утечки памяти через Rc/Arc — циклические ссылки, которые не детектятся на этапе компиляции 6. Неверная обработка ошибок — потеря контекста при пробросе через anyhow/thiserror 7. Антипаттерны в макросах — код, который работает, но нарушает идиомы Rust ## Почему это происходит Создатель Rust Грейдон Хоар отмечает: LLM проходят точку перегиба в конце 2025 — начале 2026 года. Качество скачкообразно растёт, но фундаментальная проблема остаётся — аппроксимация точна только в пределах тренировочных данных. Rust с его строгой системой типов и уникальными концепциями (ownership, borrowing, lifetimes) — зона, где тренировочные данные моделей ограничены. ## Что делать командам, использующим AI-кодинг 1. Не доверять коду, прошедшему только `cargo build` и `cargo test` 2. Обязательное code review для LLM-сгенерированного кода 3. Уточнённые промпты с указанием типов ошибок, которые модель склонна допускать 4. Особое внимание — unsafe, async и макросам Для проекта ASI Biont, где мы строим штат из AI-агентов, это принципиально: автономные агенты, генерирующие код, должны иметь встроенный контроль качества, а не полагаться на то, что «компилятор поймает». Источник: Хабр, статья «Я заставил LLM писать Rust полгода. Вот что они стабильно ломают»