11 мин

130

Полгода я использовал Claude, GPT и Cursor как основной инструмент для написания Rust-кода в проде. Не как «помощник для бойлерплейта», а как полноценного второго разработчика на монолите примерно в 80 тысяч строк (бэкенд обработки потоковых данных, tokio, sqlx, немного unsafe в hot path). Доля сгенерированного кода в коммитах последних шести месяцев около 40%, остальное это правки, рефакторинг и места, куда модель я не пускаю.

За это время накопилась коллекция ошибок, которые модели делают с пугающей регулярностью, и которые проходят cargo build, проходят cargo test, иногда даже проходят cargo clippy, и при этом являются либо UB, либо логически некорректным кодом, либо тем самым «работает на моей машине».

Я не буду писать, какая модель лучше. К моменту публикации статьи рейтинг устареет. Я расскажу про категории ошибок, которые воспроизводятся у всех топовых моделей весной 2026 года, и которые упираются не в качество обучающих данных, а в фундаментальные слепые пятна архитектуры трансформеров применительно к системе типов Rust.

Цифры, которые буду приводить дальше, получены так: я завёл бенчмарк из 50 типовых задач (написать функцию, отрефакторить, добавить фичу), прогонял каждую через четыре модели в течение полугода, и руками классифицировал ошибки. Это не academic-level статистика, но порядки величин показывает.

Почему именно Rust ломает LLM

С Python модель угадывает по контексту почти всегда. С Go угадывает почти всегда. С Java и TypeScript промахивается на сигнатурах, но компилятор это ловит. Rust отличается тем, что значительная часть его корректности живёт в местах, которые модель физически не видит в окне контекста: в коде вызывающей стороны, в трейтах из другого крейта, в drop-порядке, в lifetime-связях между параметрами функции и её возвращаемым значением.

Трансформер генерирует токены последовательно, и его внимание распределено по тексту, который ему дали. Borrow checker рассуждает о графе заимствований во времени. Эти две модели мира пересекаются только частично, и в местах непересечения происходят интересные ошибки.

Категория первая. Lifetime laundering

Самая частая ошибка, которую я видел у всех моделей. В моём бенчмарке она воспроизводится в 34 из 50 задач, где функция возвращает ссылку. Выглядит так:

fn first_word<'a>(s: &'a str) -> &'a str {
    s.split_whitespace().next().unwrap_or("")
}

Это валидный код. Теперь просим модель добавить кеширование:

fn first_word<'a>(s: &'a str, cache: &mut HashMap<String, &'a str>) -> &'a str {
    if let Some(cached) = cache.get(s) {
        return cached;
    }
    let word = s.split_whitespace().next().unwrap_or("");
    cache.insert(s.to_string(), word);
    word
}

Компилируется. Изолированный тест проходит. Является ловушкой замедленного действия.

Чтобы увидеть в чём беда, надо посмотреть на вызывающий код:

let mut cache: HashMap<String, &str> = HashMap::new();

{
    let s1 = String::from("hello world");
    first_word(&s1, &mut cache);
}
// s1 уже дропнут, но в cache лежит &str с лайфтаймом, привязанным к s1

let s2 = String::from("foo bar");
first_word(&s2, &mut cache); // ошибка компиляции

Один лайфтайм 'a параметризует и входную строку, и значения в HashMap. Компилятор вынужден выбрать пересечение этих лайфтаймов, и в реальной кодовой базе оно схлопывается в пустое множество практически сразу. Сигнатура выглядит элегантно, а используется только в синтетических примерах.

Правильная сигнатура должна разделить два лайфтайма (<'a, 'b> с понятным контрактом) или хранить в кеше String, а не &str. LLM этого выбора не делает, потому что не видит вызывающую сторону. Лечится только привычкой смотреть на каждую функцию с лайфтаймами как на контракт со всем приложением.

Категория вторая. Send и Sync, которых там нет

Просите модель сделать «структуру, которую можно шарить между потоками». Получаете:

pub struct Cache {
    inner: Arc<Mutex<HashMap<String, Vec<u8>>>>,
}

impl Cache {
    pub async fn get(&self, key: &str) -> Option<Vec<u8>> {
        let guard = self.inner.lock().unwrap();
        guard.get(key).cloned()
    }
}

Код компилируется. Тесты проходят. В проде это deadlock на любой нагрузке, где задачи начинают вытесняться рантаймом между потоками. std::sync::Mutex держится через .await, и при работе под tokio::spawn это противоречит контракту планировщика.

Clippy ловит это правилом await_holding_lock, но только если оно включено явно, и только если guard живёт через await в простой форме. В реальном коде guard прячется внутри замыкания, внутри if let, внутри блока с ранним возвратом, и lint молчит. В моём бенчмарке clippy поймал 7 случаев из 23, где модель сделала эту ошибку.

Модели путают std::sync::Mutex и tokio::sync::Mutex примерно в половине случаев, даже если в Cargo.toml подключён tokio и весь остальной код асинхронный. Происходит это потому, что в обучающих данных std::sync::Mutex встречается на порядок чаще, и при генерации он выигрывает по вероятности токенов. Никакая семантика языка тут роли не играет, это чистая статистика корпуса.

Категория третья. Drop order и RAII-капканы

let conn = pool.get().await?;
let tx = conn.transaction().await?;
let result = do_work(&tx).await?;
tx.commit().await?;
Ok(result)

Просим отрефакторить под обработку ошибок с откатом. Модель делает так:

async fn run(pool: &Pool) -> Result<Data> {
    let conn = pool.get().await?;
    let tx = conn.transaction().await?;
    match do_work(&tx).await {
        Ok(result) => {
            tx.commit().await?;
            Ok(result)
        }
        Err(e) => {
            tx.rollback().await?;
            Err(e)
        }
    }
}

Вроде разумно. Только предположим, что commit().await сам вернул ошибку, и tx дропается с незавершённой транзакцией. Какой Drop у транзакции в вашей библиотеке? У sqlx он сделает implicit rollback в блокирующем режиме внутри async-рантайма, что в tokio логируется как warning о блокирующем вызове в async-контексте. У deadpool-postgres он отправит rollback в фоновую задачу, которая может не выполниться, если рантайм уже останавливается. Модель про это не знает, потому что поведение Drop у конкретной библиотеки не зафиксировано в её сигнатурах, оно зафиксировано в документации и в исходниках.

Я отдельно проверял: если в промпте явно указать «используется sqlx 0.7», результат становится заметно лучше, но всё равно не идеальным. Модель помнит API, но не помнит контракты Drop.

Категория четвёртая. Unsafe, который выглядит безопасно

Это самая опасная категория. Просим написать быстрый парсер, который читает заголовок из байтового буфера:

pub fn read_header(buf: &[u8]) -> Option<Header> {
    if buf.len() < std::mem::size_of::<Header>() {
        return None;
    }
    let header = unsafe {
        std::ptr::read(buf.as_ptr() as *const Header)
    };
    Some(header)
}

Если Header это #[repr(C)] структура с правильным выравниванием, и если буфер пришёл из источника, который гарантирует выравнивание, всё работает. Если буфер пришёл из сети и лежит со сдвигом в один байт, на x86 это сработает медленнее, на ARM это паника или мусор, а с точки зрения abstract machine это UB в обоих случаях. Правильный вариант это read_unaligned, но модель его предлагает только если в промпте есть слова «unaligned» или «network».

Я собрал 40 примеров unsafe-кода, который мне сгенерировали разные модели за полгода, и прогнал через cargo miri. Результат: 13 примеров явное UB на любых входных данных, 9 примеров UB при определённых входных данных (out-of-bounds, неправильное выравнивание, нарушение Stacked Borrows), 18 корректны. То есть примерно 55% unsafe-кода от моделей это пороховая бочка. При этом весь этот код проходил обычные тесты и code review глазами, потому что в большинстве случаев UB не проявлялось на типовых входах.

Miri умеет ловить такие вещи, но мало кто его гоняет в CI, потому что он медленный (10x к обычным тестам в моём проекте) и не поддерживает FFI. После полугода я всё равно его включил для всех файлов с unsafe, пусть и в отдельной ночной джобе.

Категория пятая. Async cancellation

Эту категорию я хочу разобрать подробнее, потому что она самая болезненная и наименее обсуждаемая. Модели плохо понимают, что фьючи в Rust отменяемы в любой точке .await. Типичный пример:

async fn process(stream: TcpStream, db: &Db) -> Result<()> {
    let data = read_message(&stream).await?;
    db.insert(&data).await?;
    send_ack(&stream).await?;
    Ok(())
}

Если этот future вызывается через tokio::select! или внутри конструкции с таймаутом, и его отменили между db.insert и send_ack, мы записали данные, но не подтвердили их клиенту. Клиент повторит запрос, мы вставим данные второй раз. Поздравляю с дубликатами в БД.

В моём бенчмарке из 12 задач, где требовалось написать обработчик с таймаутом или race-конструкцией, ни одна модель ни разу не упомянула cancel safety сама. Когда я спрашивал «эта функция cancel-safe?», модели в половине случаев уверенно отвечали «да», и приводили неправильное обоснование. В одном случае Claude написал «функция cancel-safe, потому что все await-точки идемпотентны», что одновременно неверно и звучит правдоподобно.

Корень проблемы в том, что cancel safety это свойство, которое нигде не выражено в типах. Когда я пишу

async fn process(...) { ... }

сигнатура не отличается от cancel-safe и не-cancel-safe варианта. Borrow checker не помогает. Clippy не помогает. Документация tokio помогает, но её надо читать, и для каждой используемой функции отдельно. Например, tokio::io::AsyncReadExt::read cancel-safe, а read_exact уже нет, и это написано мелким шрифтом.

Чтобы LLM это понимала, ей нужна не просто сигнатура, а полный контекст вызывающего кода. А его модель не видит, потому что он живёт в другом файле, иногда в другом крейте, иногда вообще в библиотечном tokio::time::timeout где-то в стеке вызовов.

Лечится это так. Во-первых, любую функцию, которая может оказаться внутри select! или timeout, я помечаю комментарием // cancel-safe или // NOT cancel-safe, и модель видит этот комментарий при следующих правках. Это руками, но работает. Во-вторых, для критичных секций использую паттерн «spawn и join вместо await»:

async fn process(stream: TcpStream, db: Arc<Db>) -> Result<()> {
    let data = read_message(&stream).await?;
    // С этого момента отмена не должна нас рвать
    let handle = tokio::spawn(async move {
        db.insert(&data).await?;
        send_ack(&stream).await?;
        Ok::<_, Error>(())
    });
    handle.await?
}

Этот код тоже не идеален (spawn означает потерю кооперативной отмены), но он явно отделяет «отменяемая часть» от «неотменяемой». LLM такой паттерн сама не предлагает почти никогда, но если показать один раз в кодовой базе, дальше она его повторяет.

Это место, где Rust почти достроил мост, но не достроил. Язык даёт инструмент (async fn), но не даёт способа выразить инвариант «эту функцию нельзя отменять между точками A и B». Люди справляются через дисциплину и review. LLM не справляется никак.

Категория шестая. Семвер-конфликты в blanket impl

Модели любят предлагать impl<T: Foo> Bar for T. Это удобный паттерн, который покрывает много типов одной реализацией. Проблема в том, что blanket impl в публичном API крейта это semver hazard первого порядка.

Допустим, в crate A есть:

pub trait Bar { fn bar(&self) -> String; }
impl<T: Display> Bar for T {
    fn bar(&self) -> String { format!("{}", self) }
}

Crate B зависит от A и пишет:

pub struct MyType;
impl Display for MyType { ... }
impl Bar for MyType {
    fn bar(&self) -> String { "custom".into() }
}

В момент написания crate A не имел impl для MyType (потому что не знал про него), всё компилируется. Если crate A в следующем минорном релизе добавит ещё один blanket impl или сузит существующий, у crate B сломается компиляция. Формально это breaking change со стороны A, но определяется он только в момент сборки B.

Модель не знает, как ваш крейт используется снаружи, поэтому охотно предлагает blanket impl там, где должен быть explicit impl для конкретных типов. В моём опыте это вторая по болезненности категория после async cancellation, потому что ошибка проявляется не на CI вашего крейта, а на CI потребителей через несколько месяцев.

Правило, которое я для себя вывел: blanket impl в публичном API допустим только если трейт sealed (закрыт от внешних реализаций), и в любом другом случае надо писать impl поштучно. LLM сама это правило не применяет, надо проверять глазами.

Категория седьмая. Allocator и большие массивы на стеке

fn process_batch() -> [u8; 1024 * 1024] {
    let mut buf = [0u8; 1024 * 1024];
    fill(&mut buf);
    buf
}

Один мегабайт на стеке, возвращаемый по значению. В debug-сборке это stack overflow с большой вероятностью. В release rustc на 1.84 умеет делать NRVO в большинстве случаев, но это не гарантия: достаточно одного промежуточного let x = process_batch(); с последующей передачей в функцию, и копия материализуется. Я проверял на godbolt с rustc 1.84 и -C opt-level=3: вариант с прямым return оптимизируется, вариант с переменной перед return иногда нет.

Связанная ошибка: модель часто пишет Box::new([0u8; 1024 * 1024]), думая, что это аллоцирует напрямую в куче. Начиная с rustc 1.70 в release-сборке это иногда оптимизируется в placement-аллокацию, но в debug всё равно проходит через стек и падает. Гарантированно безопасный путь это vec![0u8; N].into_boxed_slice() или Box::<[u8]>::new_uninit_slice на nightly с последующим assume_init.

LLM это знает, если спросить прямо («аллоцируй в куче без промежуточного стека»), и не знает по умолчанию. Цена ошибки маленькая (заметна сразу), но в proc-макросах и code-gen, где массив создаётся внутри сгенерированного кода, отлов занимает час.

Промпты, которые реально работают

За полгода я вывел несколько шаблонов, которые статистически снижают количество ошибок в моём бенчмарке. Делюсь.

Первое, всегда указывайте версии крейтов и async-рантайм в начале промпта. Не «напиши обработчик HTTP», а «напиши обработчик HTTP, axum 0.7, tokio 1.35, sqlx 0.7 с postgres». В моём бенчмарке это снизило количество ошибок категории 2 (Mutex) с 46% до 19%.

Второе, явно требуйте обозначить cancel safety каждой async-функции. Промпт «для каждой async-функции добавь комментарий cancel-safe или not cancel-safe и обоснуй» работает заметно лучше, чем «напиши cancel-safe код». Первый заставляет модель пройтись по каждой функции, второй она игнорирует.

Третье, для unsafe требуйте отдельный блок с safety invariants. Промпт «перед каждым unsafe-блоком напиши // SAFETY: с перечислением инвариантов» работает почти всегда, и заодно даёт material для code review.

Четвёртое, для нетривиальных lifetime-сигнатур требуйте показать пример вызывающего кода. Это вынуждает модель выйти из локальной оптимизации и проверить, что сигнатура осмысленна снаружи. У меня это закрыло почти все ошибки категории 1.

Пятое, не давайте модели проектировать trait-иерархии без явного контракта. Сначала вы пишете trait-определения и документацию, потом модель пишет реализации. Если попросить модель спроектировать трейты «с нуля под задачу X», результат стабильно хуже среднего человеческого.

Что я в итоге поменял в процессе

Перестал давать модели маленькие изолированные задачи. Чем меньше контекста, тем больше она оптимизирует локально и тем чаще ломает архитектурные инварианты.

Включил miri в ночной CI для всего unsafe-кода. Это медленно, но один пойманный UB окупает неделю миришной тормозни. Если у вас есть FFI, можно использовать cargo-careful как промежуточный вариант.

Добавил clippy::pedantic и clippy::nursery для файлов, где много AI-кода. Многие категории ошибок ловятся именно там.

Завёл правило: любой код от модели, где есть unsafe, unwrap, transmute, Arc, Mutex, blanket impl или ручная имплементация Send/Sync, требует пристального review глазами. Без исключений.

Полностью отказался от того, чтобы доверять модели проектирование trait-иерархий. Это место, где она ошибается стратегически, и где правки потом стоят дорого.

Что из этого следует

LLM это полезный инструмент для Rust, но он не заменяет понимания языка. Он усиливает того, кто понимает borrow checker, async cancellation и unsafe-контракты, и опасен для того, кто не понимает. Парадокс в том, что чем сложнее язык, тем больше выигрыш от модели на рутине, и тем больше потери от модели на тонких местах.

Главный вывод полугода такой. Через год rustc будет в CI у каждого, кто всерьёз пользуется LLM, и не потому что разработчик так захотел, а потому что без него код от модели становится финансовым риском. Языки с богатой системой типов перестают быть «сложнее, чем Python», и становятся «безопаснее в эпоху LLM, чем Python». Если этот сдвиг произойдёт, Rust выиграет не благодаря маркетингу memory safety, а благодаря тому, что компилятор отрабатывает за code reviewer там, где у других языков code reviewer нет вообще.

Те ошибки, которые я описал в статье, это то, что осталось после фильтра компилятора. Десять лет назад я бы сказал, что таких ошибок не бывает. Сейчас они стабильно генерируются раз в неделю на одном разработчике.

Если у вас есть свои примеры, где модель уверенно сломала Rust, поделитесь в комментариях. Я веду коллекцию и однажды сделаю из неё отдельный пост с разбором каждого случая.

Пишу про Rust в тг, если интересно залетайте!

Жду замечаний и предложений в комментариях, спасибо за прочтение статьи!

P.S. Rust сегодня исполняется 11 лет 🦀🎉

С версии 1.0 многое изменилось, но история языка всё ещё пишется.

От первого стабильного релиза до сегодняшнего дня Rust вырос в топовый язык, сформированный аккуратным дизайном и крутым сообществом, которое постоянно поднимает планку качества в разработке ПО.

А когда вы начали работать с Rust?