Un runtime de lenguaje en producción fue reconstruido en 832.378 líneas de Rust para reemplazar a TypeScript, y la diferencia de rendimiento es contundente: una prueba que ejecuta 1.000 ciclos de sesión de un solo turno pasó de 7,55 por segundo a 120, mientras que la memoria de un lote de agentes con 10 clientes cayó de 1.383MB a 126MB. El trabajo se extendió del 12 de mayo al 21 de agosto de 2026, lo dirigió principalmente un solo desarrollador que supervisaba agentes de programación y quedó documentado en un informe técnico detallado firmado por Stephen Toub, ingeniero distinguido de Microsoft.
Claves del caso
- Los agentes convirtieron unas 430.000 líneas de TypeScript en producción en 832.378 líneas de Rust, repartidas en 128 pull requests fusionados durante 14,5 semanas.
- Una prueba de 1.000 ciclos de sesión de un solo turno pasó de 7,55 por segundo en TypeScript a 120 por segundo con Rust en proceso, y un lote de agentes con 10 clientes bajó de 1.383MB a 126MB de memoria.
- De los 31.247 mensajes de usuario registrados en los logs, solo unos 2.600 los escribió una persona: aproximadamente uno de cada doce.
Las cifras detrás de la migración
Además del código de producción, los agentes generaron 468.689 líneas de pruebas unitarias en Rust. Los pull requests de la migración llegaban a un ritmo de 1,3 por día mientras se publicaban 135 versiones públicas en paralelo, porque los módulos se sustituyeron uno a uno en lugar de hacer un cambio único. The Register informó de una factura de tokens cercana a los 120.000 dólares.
El andamiaje temporal cuenta la misma historia: las exportaciones N-API que unían ambos mundos llegaron a un máximo de 2.019 el 3 de agosto, junto a 3.356 puntos de llamada en TypeScript. Ambas cifras terminaron en cero.
Qué sostiene realmente este runtime
El motor resulta invisible para casi todos los que lo usan. Sustenta la CLI de Copilot, la aplicación de escritorio de Copilot, el SDK de Copilot en seis lenguajes y el agente en la nube, y viaja dentro de las versiones recientes de VS Code y Visual Studio. También llega hasta Excel, Outlook, PowerPoint y Word.
La versión original corría sobre TypeScript con Node.js y V8: rápida para iterar, pero débil en latencia de arranque y densidad de servidor cuando el mismo motor tuvo que incrustarse mediante una ABI de C en tantos anfitriones. Toub delimitó con cuidado la conclusión: el proyecto no pretende sostener que todo programa grande en TypeScript deba pasarse a Rust, y aclaró que aquí pesaban de forma especial la incrustación por ABI de C, un consumo bajo en régimen estable y un uso de recursos predecible.
Por qué los agentes dedicaron más tiempo a leer que a escribir
Los logs registraron 12.760.995 eventos y 1.857.409 inicios de herramienta. Solo los comandos de inspección de Git consumieron 608 horas medidas. La tasa de aciertos de la caché de prompts alcanzó el 96,22%; sin ella, sesiones de esa duración habrían resultado inasumibles.
La imagen popular de una IA escupiendo código es casi la contraria; a esta escala, el trabajo se parecía mucho más a una investigación iterativa.
Migrar session.ts, un archivo de 30.000 líneas que toca todas las partes del runtime, exigió una sesión de 25 horas que arrancó con 56 minutos de lectura y 122 llamadas de herramienta para aclarar dudas antes de la primera edición. Después generó 15 sesiones hijas en siete oleadas e intercambió con ellas 89 mensajes de coordinación. Los modelos se repartieron según sus fortalezas: se usaron tanto GPT-5.6 Sol como Claude Opus 4.8 de Anthropic.
Lo que el compilador no pudo detectar
El borrow checker, la pieza de Rust que domina cualquier conversación sobre su dificultad, apenas apareció. De 8.678 errores de compilación, los problemas de propiedad, préstamos y tiempos de vida supusieron el 1,7%, mientras que la resolución de nombres e importaciones llegó al 37%. El código unsafe quedó contenido en 158 bloques repartidos en 36 archivos, casi todos en las fronteras con la ABI de C, la API de Windows y POSIX.
Las regresiones fueron otra historia. Se rastrearon decenas, la mayoría aflorando en canales de prueba, y no se cerraron del todo hasta el 14 de septiembre. Se agruparon en migraciones incompletas, problemas de estado y de tiempo de vida, contratos de comportamiento incumplidos, fallos en la frontera con el anfitrión y pruebas con expectativas equivocadas: nada que un compilador evalúe. En la RustConf de Montreal, la consultora Lisa Crossman advirtió contra tratar al compilador como un oráculo y recordó que Rust impide a un agente escribir código inseguro en memoria, pero no le impide escribir correctamente el programa equivocado. Toub llegó a un punto parecido: la idea de que el código que compila es código correcto solo sirve como chiste.
Perspectivas
El caso de referencia es Bun, el runtime de JavaScript propiedad de Anthropic, donde su creador Jarred Sumner trasladó unas 535.000 líneas de Zig a Rust casi por completo con agentes de Claude; el port experimental ya superaba el 99,8% de las pruebas de Bun en Linux x64 glibc el 30 de julio, aunque las versiones estables siguen saliendo de Zig y el creador de Zig, Andrew Kelley, despachó el resultado como código basura sin revisar. GitHub tomó el camino opuesto y sustituyó los módulos uno por uno sin reestructurar nada, lo que significa que el verdadero trabajo de optimización todavía no ha empezado. El patrón recuerda a una reescritura similar en Rust hecha por dos ingenieros en OpenAI: equipos humanos diminutos, un rendimiento enorme de los agentes y la revisión como único cuello de botella que queda.
Preguntas frecuentes
¿Escribieron los agentes de IA todo el código en Rust?
Los agentes produjeron la mayor parte, pero las personas siguieron al mando del diseño, la revisión y las decisiones finales. Los logs muestran unos 2.600 mensajes escritos por humanos frente a 31.247 mensajes de usuario en total, es decir, una intervención humana cada doce turnos aproximadamente.
¿Cuánto más rápido es el runtime en Rust?
En una prueba publicada que mide 1.000 ciclos de sesión de un solo turno con un cliente compartido y 100 canalizaciones concurrentes, la versión en Rust alcanzó 120 ciclos por segundo frente a 7,55 de TypeScript, una mejora de 15,9 veces. La memoria de un lote de agentes con 10 clientes bajó de 1.383MB a 126MB.
¿Deberían otros proyectos en TypeScript migrar a Rust?
Toub se negó expresamente a generalizar. Aquí el argumento a favor de Rust se apoyaba en la incrustación mediante una ABI de C, un coste de arranque bajo y un uso de recursos predecible en muchas aplicaciones anfitrionas, requisitos que la mayoría de bases de código en TypeScript no tienen.
