Les LLMs écrivent du Rust avec sept catégories d’erreurs cachées que le compilateur ne détecte pas

Un développeur a passé six mois à utiliser Claude, GPT et Cursor comme un deuxième programmeur Rust à part entière dans du code de production. Au cours de cette période, il a soigneusement suivi les erreurs et compilé une liste impressionnante : sept catégories d'erreurs que les LLM font systématiquement. Le plus troublant — ces erreurs passent le compilateur, les tests unitaires et même l'analyseur statique clippy. Pourtant, elles violent la sécurité de la mémoire ou détruisent l'architecture de l'application.

Sept Catégories d'Erreurs Cachées

Voici les catégories que les LLM cassent encore et encore:

• Lifetime laundering — les variables vivent plus longtemps que le système de types de Rust le permet. Cela entraîne une use-after-free à l'exécution.
• Mutex through await — un verrou qui maintient le mutex pendant l'attente asynchrone. Deadlock garanti.
• Drop dans les transactions — oublient d'appeler drop quand ils doivent fermer une ressource (fermer un fichier, annuler une transaction). Fuites de ressources.
• Unaligned read — déréférencement de mémoire avec un alignement incorrect. Le processeur s'écrase sur ARM, se casse silencieusement sur x86.
• Async cancellation — annulation incorrecte d'opérations asynchrones. Laisse des états suspendus.
• Orphan rule — violation de la règle orpheline lors de l'implémentation des traits. Se compile dans un projet, se casse en ajoutant une dépendance.
• Tableaux sur la pile — allocation de énormes tableaux sur la pile (au lieu du tas). Débordement de pile, segfault.

Pourquoi C'est Dangereux pour la Production

L'intérêt de Rust est que le compilateur détecte les erreurs pendant le développement, pas en production. Mais ces sept erreurs échappent au compilateur — parce qu'elles ne violent pas la syntaxe ou les règles de typage formel. En conséquence, le code se compile sans avertissements, passe les tests unitaires, s'exécute via clippy et est déployé en production. Tout se casse là, mais il est trop tard. C'est pire qu'une erreur de compilateur explicite, car le développeur est confiant que tout va bien.

Pourquoi les LLM cassent cela

Rust est un langage marginal dans l'ensemble de données des LLM. Python, JavaScript et Java représentent 70% du code sur lequel les modèles ont été entraînés. Rust — peut-être 2-3%. De plus, Rust nécessite une compréhension approfondie de la propriété, des lifetimes et du système de types, que les LLM ne comprennent que superficiellement. Les modèles voient des motifs et les copient. Ils savent que « vous écrivez généralement comme ça », mais ne savent pas pourquoi cela fonctionne en Java et se casse en Rust. Donc ils reproduisent les motifs incorrectement, créant l'illusion de code compilable.

Rust casse les LLM parce que c'est un langage où vous devez penser, ne

pas simplement copier des motifs.

Conclusions Pratiques

Le développeur ne conseille pas d'abandonner complètement les LLM, mais recommande:

• Ne vous fiez pas aux LLM pour les sections critiques: cryptographie, opérations de mémoire, concurrence
• Exiger un examen formel du code même si le compilateur ne se plaint pas
• Utilisez Miri — un interpréteur qui détecte les comportements indéfinis pendant le développement
• Apprenez Rust suffisamment pour écrire du code vous-même ou pouvoir trouver des bugs dans le code LLM

Ce Que Cela Signifie

Les LLM sont un outil utile, mais pas un remplacement pour les humains. Dans les langages dynamiques, ils fonctionnent bien (Python, JavaScript), car il y a moins de règles qui doivent être comprises intuitivement. En Rust, vous devez soit vérifier chaque ligne, soit maintenir des humains dans la boucle de décision. Pour les frameworks comme Next.js ou Django, un assistant LLM est un accélérateur puissant. Pour Rust en production, c'est plus un brouillon pour examen humain qu'un collègue à part entière.