Los LLM fallan con unsafe Rust: seis meses de pruebas revelaron errores críticos

El autor hizo que LLM escribiera código unsafe Rust en proyectos en producción durante seis meses y verificó cada bloque con Miri y sanitizadores. El resultado fue decepcionante: los modelos cometían los mismos errores de forma predecible y consistente.

Siete categorías de errores del LLM en unsafe Rust

Los modelos cometen errores consistentemente en los mismos lugares:

• Aliasing — violación de la regla de referencias no superpuestas
• Provenance — intentos de usar punteros obtenidos incorrectamente
• Layout en alloc/dealloc — desajuste de tamaño/alineación durante asignación y desasignación
• ManuallyDrop — olvidan llamar drop o acceden al objeto después de drop
• Condiciones de carrera en callbacks FFI — condiciones de carrera al llamar funciones C desde threads
• Manual Send/Sync — implementan incorrectamente traits de seguridad de threads
• Memoria Uninit — tratan datos sin inicializar como inicializados

Por qué Miri reveló los problemas

Miri es un intérprete Rust que rastrea comportamiento indefinido. Cuando LLM genera código con violaciones sutiles a primera vista (por ejemplo, un puntero temporal con proveniencia incorrecta), el compilador regular las pierde, pero Miri las detecta. Bajo sanitizadores (AddressSanitizer, ThreadSanitizer), se descubrieron condiciones de carrera y use-after-free, que podrían no aparecer en pruebas regulares.

"Cada categoría viene con un ejemplo mínimo y una solución" — el autor

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

Qué significa esto

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 cometen errores sistemáticamente en la gestión de memoria y multithreading. Para código crítico (software de sistema, librerías de sistema), el unsafe Rust de los modelos debe verificarse con Miri.