Los LLM fallan con Rust inseguro: seis meses de pruebas revelan errores críticos

El autor pidió a varios LLM que escribieran código unsafe Rust en proyectos de producción durante seis meses y revisó cada bloque con Miri y sanitizers. El resultado fue decepcionante: los modelos cometen los mismos errores de forma predecible y constante.

Siete categorías de errores de los LLM en unsafe Rust

Los modelos fallan una y otra vez en los mismos puntos:

• Aliasing — violación de la regla sobre referencias que no se solapan
• Provenance — intentos de usar punteros obtenidos de forma incorrecta
• Layout en alloc/dealloc — discrepancia de tamaño y alineación entre la asignación y la liberación
• ManuallyDrop — olvidan llamar a drop o usan el objeto después de drop
• Carreras en callbacks de FFI — condiciones de carrera al llamar a funciones de C desde hilos
• Send/Sync manuales — implementan mal los traits de seguridad entre hilos
• Memoria sin inicializar — tratan datos sin inicializar como si estuvieran inicializados

Por qué Miri destapó los problemas

Miri es un intérprete de Rust que rastrea el comportamiento indefinido. Cuando un LLM genera código con infracciones poco evidentes a primera vista (por ejemplo, un puntero temporal con una procedencia incorrecta), el compilador normal lo deja pasar, pero Miri lo detecta. Con los sanitizers (AddressSanitizer, ThreadSanitizer) salieron a la luz carreras y errores de use-after-free que pueden no manifestarse en pruebas ordinarias.

«Cada categoría viene con un ejemplo mínimo y una corrección» — el

autor muestra que no son simples observaciones, sino patrones de error reproducibles.

Qué significa

Los LLM aún no están listos para escribir unsafe Rust sin supervisión humana. Generan bien la sintaxis y la lógica general, pero fallan de forma sistemática al trabajar con memoria y multihilo. En el código crítico (software de sistemas, bibliotecas de sistema), el unsafe Rust escrito por modelos debe revisarse obligatoriamente con Miri.