Rust y código generado por IA: el compilador como revisor

Los asistentes de código cambiaron el problema. Antes costaba escribir software, y ahora cuesta más saber si lo escrito es correcto. Por eso la revisión pasó a ser el cuello de botella.

Rust tiene aquí una propuesta interesante, y merece analizarse sin exagerar.

Lo que sabemos sobre el código generado

Veracode analizó en 2025 80 tareas de programación con más de 100 modelos. En el 45 % de los casos, el código introducía una vulnerabilidad. Java tuvo la peor tasa, con más del 70 %, y Python, C# y JavaScript quedaron entre el 38 % y el 45 %. Según la empresa, los resultados no mejoraban con los modelos nuevos.

Dos advertencias: Veracode vende herramientas de seguridad, y sus pruebas se centraron en errores como inyección y cross-site scripting. Pero el mensaje general es razonable: el código generado se parece al que aprendió, incluidos sus errores.

El compilador no se cansa

Un revisor humano se fatiga. Revisa bien las primeras cien líneas y peor las mil siguientes. El compilador de Rust revisa siempre igual, y rechaza clases enteras de errores antes de llegar a una revisión:

Esto crea un ciclo útil con la IA. Si el asistente genera código con un problema de propiedad, el compilador lo rechaza con un mensaje preciso. El asistente lo lee y lo corrige. El ciclo ocurre antes de que una persona mire el código.

Hay evidencia de que funciona, con matices. RustAssistant, un trabajo de Microsoft Research, conecta un modelo con el compilador y reporta cerca del 74 % de errores de compilación reales corregidos. Pero otro trabajo sobre traducción de C a Rust advierte que los mensajes del compilador no bastan por sí solos: hacen falta instrucciones de reparación guiadas.

El caso más llamativo es Bun, que en 2026 pasó de Zig a Rust con asistentes de IA, y con su suite de pruebas como red de seguridad. Lo presentó con una idea muy cercana a esta nota: los errores del compilador son mejor ciclo de retroalimentación que una guía de estilo. Aun así, reportó 19 regresiones.

Y hay un riesgo sutil: corregir un error de compilación no significa que el programa haga lo correcto. A veces el fallo solo se traslada a una etapa posterior, y resulta más difícil de encontrar.

Lo que el compilador sí detecta

• Fallos de memoria en código seguro.
• Carreras de datos.
• Casos no tratados en un match.
• Valores opcionales usados sin comprobar.
• Errores ignorados, con una advertencia si no usas un Result.

Lo que el compilador no detecta

Aquí es donde se equivocan quienes prometen de más. Rust no sabe qué debería hacer tu programa, de modo que estos errores pasan sin aviso:

• Autorización ausente: una ruta que debería exigir permisos, y no lo hace.
• Lógica de negocio equivocada: un descuento mal calculado compila perfectamente.
• Inyección SQL: si concatenas texto, Rust no te salva. Usa consultas parametrizadas.
• Secretos en el código: una clave escrita en el repositorio compila sin problemas.
• Dependencias inventadas o maliciosas: los asistentes pueden sugerir paquetes que no existen, y alguien podría registrarlos después.
• unsafe innecesario: un modelo puede usarlo para "resolver" un error del compilador. Es la señal de alarma más clara.

Una configuración sensata

Si tu equipo usa asistentes, esto cierra buena parte del riesgo. Lo primero es prohibir unsafe en el código propio. Con esta línea, cualquier bloque unsafe deja de compilar:

#![forbid(unsafe_code)]

fn main() {
    println!("Este proyecto no permite código unsafe");
}

Si de verdad necesitas unsafe, aíslalo y audítalo. Lo segundo es endurecer el control de calidad en integración continua:

cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo nextest run
cargo deny check
cargo audit

Cada comando atiende un riesgo:

Encuéntralas todas en nuestra caja de herramientas.

Cómo revisar lo que escribe un asistente

La revisión humana no desaparece, pero cambia de foco. Si el compilador ya cubrió la memoria, la persona puede concentrarse en lo importante:

1. La intención: ¿resuelve el problema correcto?
2. La autorización: ¿quién puede ejecutar esto?
3. Los límites: ¿qué pasa con datos vacíos, enormes o maliciosos?
4. Las dependencias nuevas: ¿existen, se mantienen, las necesitas?
5. Las pruebas: ¿comprueban algo, o solo repiten la implementación?
6. Cada unsafe, unwrap y clone: ¿tiene justificación?

Entonces, ¿Rust es mejor para la IA?

Lo honesto es decir que no hay un estudio concluyente sobre si el Rust generado es más seguro en general. Lo que sí está claro es el mecanismo: más errores detectados por una máquina significa menos carga para quien revisa. El costo es que el asistente tardará más ciclos en conseguir que compile, y que necesitas personas que entiendan lo que aprueban.

La IA no elimina la necesidad de criterio, sino que la vuelve más valiosa.