Un experimento con IA no halla diferencias entre Rust y C++: lo decisivo es cómo se dirige al agente

Por Zendoric · 27 de julio de 2026.

Richard Palethorpe, ingeniero freelance especializado en sistemas y colaborador de proyectos como LocalAI, convierte modelos de IA de PyTorch (el framework de referencia para entrenar redes neuronales) a GGML, una librería en C/C++ minimalista que permite ejecutar modelos de inferencia (usar un modelo ya entrenado) con muy pocas dependencias y un rendimiento igual o superior al original, según cuenta en su blog. Cuando alguien le preguntó por qué no usaba Rust en su lugar, decidió montar un experimento: pedir a agentes de IA que reescribieran el mismo modelo en ambos lenguajes y comparar cuál sale mejor parado.

El modelo elegido fue FLOAT, un sistema que anima retratos para que parezca que hablan a partir de una pista de audio. Palethorpe encargó a Claude —al que en algunos pasajes de su relato llama también "Fable"— crear tres subagentes: uno para analizar la implementación original en PyTorch y construir un arnés de comparación capa a capa, y dos más para portar el modelo a C++ (con GGML) y a Rust (con Burn, un framework de aprendizaje automático en ese lenguaje), hasta alcanzar paridad de precisión y velocidad con el original.

El primer resultado pareció una victoria clara para Rust: el agente reportó la mitad de tokens consumidos para el mismo rendimiento. Pero Palethorpe detectó la trampa: el agente Rust se había beneficiado del trabajo de depuración que el agente C++ ya había hecho sobre el arnés de comparación compartido. Además, sin que lo pidiera explícitamente, un agente implementó la versión GGML en CUDA (la plataforma de cómputo de Nvidia) y la de Rust en Vulkan (un estándar gráfico multiplataforma), lo que introducía una variable más en la comparación.

Para eliminar ese ruido, Palethorpe pidió una segunda ronda: dos implementaciones nuevas, solo para CPU, usando librerías SIMD (instrucciones de procesador que operan sobre varios datos a la vez, clave para acelerar cálculo numérico sin GPU), compiladas de forma estática y con capacidad de compilación cruzada a ARM. Rust volvió a parecer ganador... hasta que notó que el agente, sin que se lo pidieran de forma explícita, se había saltado crear una API en C —el estándar mínimo para que cualquier otro lenguaje pueda usar la librería— y había dejado de optimizar el rendimiento antes de tiempo. Al forzar que ambos agentes completaran el mismo alcance de trabajo, la ventaja de Rust volvió a desaparecer.

La última prueba fue una revisión de código, primero con Claude y después con Codex, el asistente de programación de OpenAI. La hipótesis a favor de Rust predecía menos errores no detectados gracias a su verificador de préstamos (borrow checker, el mecanismo del compilador que obliga a demostrar en tiempo de compilación que la memoria se gestiona sin errores). No se cumplió: ambas revisiones encontraron bugs potenciales en los dos lenguajes —pese a que ambos ports se fuzzearon desde el principio— y, según esas revisiones, ninguno de los agentes había aprovechado a fondo las herramientas y características que cada lenguaje ofrece para prevenirlos.

La conclusión de Palethorpe es tajante: "no hay diferencia para un LLM entre Rust y C++". Su argumento es que ambos lenguajes resuelven el mismo problema —mover del tiempo de ejecución al tiempo de desarrollo el coste de detectar errores—, solo que Rust lo integra en el compilador y C++ lo arbitra con herramientas externas (sanitizadores, analizadores estáticos, fuzzers). Ninguna de las dos rutas es gratuita ni automática: un agente tiene que saber, y decidir, usarla a fondo.

Conviene poner el hallazgo en su sitio: es un experimento de un solo autor, con su propia admisión de que "ninguno es muy científico", publicado en un blog personal y que en Hacker News apenas sumó un punto y ningún comentario. No es un paper revisado por pares ni un benchmark reproducible. Pero el patrón que describe —agentes que recortan alcance en silencio (se saltan una API, dejan de optimizar, no explotan las herramientas anti-bugs disponibles) salvo que alguien se lo exija explícitamente— es, como contexto del sector, una preocupación cada vez más habitual entre quienes delegan código de producción en agentes, aunque la fuente no aporta datos sobre ello.

Ahí está, a nuestro juicio, la lectura que importa. El debate "qué lenguaje aprender" pierde peso frente al debate "cómo se audita y dirige a un agente": definir el arnés de pruebas, exigir el mismo alcance a ambas soluciones, forzar el uso de fuzzers y sanitizadores, revisar con un segundo modelo. Ese trabajo de especificación y verificación —no la sintaxis— es lo que hoy separa un port de producción de un prototipo con bugs latentes. Encaja con algo que venimos repitiendo al analizar el empleo tecnológico sector a sector: lo que gana valor no es dominar una herramienta concreta, sino el criterio para gobernar lo que un agente produce.

Vista con la perspectiva de abundancia que defendemos a largo plazo, la noticia es más alentadora de lo que parece a primera vista. Si escribir software de sistemas seguro y rápido deja de depender tanto de la elección de lenguaje y pasa a depender de cuánta rigurosidad se exige al agente, el coste de producir software crítico —desde infraestructura hasta herramientas médicas— puede seguir cayendo, siempre que esa rigurosidad (fuzzing, revisión cruzada, arneses de paridad) se convierta en el estándar por defecto de los agentes de código, y no en un extra que hay que arrancarles a la fuerza. El experimento de Palethorpe, modesto en escala, apunta en esa dirección: la fricción real ya no está en el lenguaje, está en la supervisión.