Los LLM escriben Rust con siete categorías de errores ocultos que el compilador no detecta

Un desarrollador pasó seis meses usando Claude, GPT y Cursor como un segundo programador de pleno derecho en código Rust de producción. Durante ese tiempo registró minuciosamente los fallos y elaboró una lista llamativa: siete categorías de errores que los LLM cometen de forma sistemática. Lo más preocupante es que estos errores superan el compilador, los tests unitarios e incluso el analizador estático clippy. Aun así, corrompen la memoria o rompen la arquitectura de la aplicación.

Siete tipos de errores ocultos

Estas son las categorías en las que los LLM fallan una y otra vez:

• Lifetime laundering: las variables viven más de lo que permite el sistema de tipos de Rust. Esto provoca use-after-free en runtime.
• Mutex a través de await: un bloqueo que mantiene el lock durante una espera asíncrona. Deadlock garantizado.
• Drop en transacciones: se olvida llamar a drop cuando hay que cerrar un recurso (cerrar un archivo, revertir una transacción). El recurso se fuga.
• Unaligned read: desreferenciar memoria con una alineación incorrecta. El procesador falla en ARM y se rompe silenciosamente en x86.
• Async cancellation: cancelación incorrecta de operaciones asíncronas. Deja estados colgados.
• Orphan rule: incumplir la regla orphan al implementar traits. Compila en un proyecto y se rompe al añadir una dependency.
• Arrays en la pila: reservar arrays enormes en el stack (en lugar del heap). Desbordamiento de pila, segfault.

Por qué es peligroso en producción

La gran ventaja de Rust es que el compilador detecta los errores durante el desarrollo, no en producción. Pero el compilador deja pasar estos siete errores porque no infringen la sintaxis ni las reglas formales de tipado.

El resultado: el código compila sin warnings, supera los tests unitarios, pasa por clippy y se despliega en producción. Allí todo se rompe, pero ya es tarde. Esto es peor que un error explícito del compilador, porque el desarrollador está convencido de que todo va bien.

Por qué los LLM fallan en esto

Rust es un lenguaje marginal en el dataset de los LLM. Python, JavaScript y Java suman el 70% del código con el que se entrenaron los modelos. Rust quizá represente un 2-3%. Además, Rust exige un conocimiento profundo de ownership, lifetimes y el type system, que los LLM entienden de forma superficial.

Los modelos ven patrones y los copian. Saben que «aquí normalmente se escribe así», pero no saben por qué eso funciona en Java y se rompe en Rust. Por eso reproducen los patrones de forma incorrecta y generan la ilusión de un código que compila.

Rust rompe a los LLM porque es un lenguaje en el que hay que pensar,

no limitarse a copiar patrones.

Conclusiones prácticas

El desarrollador no aconseja abandonar por completo los LLM, pero recomienda:

• No depender de los LLM en las partes críticas: criptografía, gestión de memoria, concurrency
• Exigir una formal code review aunque el compilador no se queje
• Usar Miri, un intérprete que detecta undefined behavior durante el desarrollo
• Aprender Rust lo suficiente como para escribir el código uno mismo o saber encontrar bugs en el código generado por LLM

Qué significa esto

Los LLM son una herramienta útil, pero no sustituyen a una persona. En lenguajes dinámicos (Python, JavaScript) funcionan bien, porque hay menos reglas que deban entenderse de forma intuitiva. En Rust hay que revisar cada línea o mantener a una persona en el circuito de toma de decisiones.

Para frameworks como Next.js o Django, un asistente LLM es un potente acelerador. Para Rust en producción, se parece más a un borrador para human review que a un colega de pleno derecho.