El motor de software que sostiene a GitHub Copilot y a una cantidad creciente de productos de Microsoft quedó escrito por completo en Rust, y la mayor parte del trabajo de conversión la hicieron agentes de IA, informó The Register.
La migración costó alrededor de 120.000 dólares en consumo de tokens, más unas tres semanas de tiempo de un desarrollador. Los responsables también tuvieron que lidiar con varias decenas de regresiones en el código resultante, lo que apunta a las dificultades que la IA sigue teniendo para entender Rust.
El trabajo actualizó el motor módulo por módulo hasta terminarlo, con más de 135 versiones publicadas a lo largo de 14,5 semanas. Se abrieron alrededor de 1,3 solicitudes de incorporación de código por día.
En total, los agentes convirtieron 430.000 líneas de TypeScript en 800.000 líneas de Rust de producción. Para mantener la conversión lo más simple posible, se reemplazaron los módulos de TypeScript caso a caso, sin buscar optimizar la estructura del motor en sí. Ese trabajo viene después.
¿Cuánto rindió el cambio de lenguaje?
Una prueba midió con qué rapidez el motor completaba 1.000 ciclos de vida de sesión de un solo turno, usando un cliente compartido y 100 flujos concurrentes. La implementación original en TypeScript completó 7,55 ciclos por segundo, mientras que Rust corriendo dentro del mismo proceso llegó a 120 por segundo, una mejora de 15,9 veces en esa carga concreta.
En memoria la distancia fue parecida. Un lote de 10 clientes de agentes consumió 1.383 MB con TypeScript, y la reescritura en Rust consumió 126 MB atendiendo al mismo enjambre. Dentro de Rust el trabajo se mantuvo en el proceso, en vez de lanzar procesos externos en segundo plano para completarlo, algo que TypeScript sí exigía.
| Medición | TypeScript | Rust |
|---|---|---|
| Ciclos de sesión por segundo | 7,55 | 120 |
| Memoria con 10 clientes | 1.383 MB | 126 MB |
| Líneas de código | 430.000 | 800.000 |
De Visual Studio Code a Microsoft Office
A primera vista, la mayoría de los usuarios no dimensiona hasta dónde llega el motor de Copilot. Sostiene la interfaz de línea de comandos de GitHub Copilot, la aplicación Copilot, el SDK y el agente en la nube de GitHub Copilot. Aparece en Visual Studio Code, en Visual Studio, en Excel, en Outlook, en PowerPoint y en incontables servicios en la nube de Microsoft.
En su origen el motor estaba escrito en TypeScript y usaba Node.js como marco de trabajo y V8 como motor de ejecución. TypeScript y Node resultaban excelentes para desarrollar rápido, pero al usarlos a gran escala flaqueaban en arranque veloz y en densidad de servidor.
"Esto no es de ninguna manera una afirmación de que todo programa grande en TypeScript debería convertirse en Rust. Nuestros requisitos ponían el acento en la integración a través de una ABI de C, en una sobrecarga baja al arrancar y en régimen permanente, y en un uso predecible de los recursos. Rust hizo posibles esos objetivos", escribió el ingeniero distinguido de Microsoft Stephen Toub en una publicación donde explicó el proceso completo.
El proyecto usó Copilot para reescribir Copilot, que a su vez recurrió a varios modelos de lenguaje. Toub mencionó a GPT-5.6 Sol y a Claude Opus 4.8, repartidos según la fortaleza natural de cada uno para las distintas partes del trabajo.
Agentes que leen mucho y conversan entre ellos
Toub evaluó el uso de agentes como un éxito en lo grueso. Hecho a mano, el proyecto habría tomado años y costado millones.
Los agentes mostraron varias conductas emergentes que sorprendieron, anotó Toub. La primera, que dedicaron mucho más tiempo a reunir información que a escribir código.
"La imagen popular de la IA vomitando código está casi al revés. A esta escala, el trabajo se parecía mucho más a una investigación iterativa, inspeccionar el estado actual, formar una hipótesis, hacer un cambio dirigido, y repetir", escribió.
Otra sorpresa fue la frecuencia con que las sesiones interactuaban con otras sesiones, ya fueran las que ellas mismas habían lanzado o sesiones completamente ajenas.
Una de las conversiones más espinosas fue la del archivo session.ts, que superaba las 30.000 líneas de TypeScript y tocaba todos los aspectos del motor. La sesión encargada de portarlo terminó tomando 25 horas. Partió dedicando 56 minutos a leer la documentación y haciendo 122 llamadas a herramientas para aclarar dudas. Después lanzó 15 sesiones hijas, cada una con su propio árbol de trabajo y su propio agente. Y ahí empezaron a comunicarse entre ellas.
Con una habilidad de orquestación incorporada, una sesión encontró a todas las demás sesiones activas y envió mensajes a aquellas cuyas misiones se solapaban, para pedirles coordinación.
Lo que el compilador no alcanza a ver
Por sus beneficios de rendimiento, Rust se ha vuelto un lenguaje buscado para reescribir aplicaciones. El creador de Bun, Jarred Sumner, portó hace poco el entorno de ejecución de JavaScript propiedad de Anthropic, que contenía unas 535.000 líneas de código Zig, a Rust casi por completo con agentes de Claude. Al 30 de julio, el port experimental a Rust pasaba el 99,8 por ciento de las pruebas existentes de Bun en Linux x64 con glibc, mientras las versiones estables seguían saliendo desde la base de código en Zig.
Ese trabajo costó 165.000 dólares en tokens.
Rust también trae peligros escondidos, como comprobó Toub. Para un modelo de lenguaje, igual que para un programador flojo, si el código compila entonces es Rust válido.
A lo largo del proceso, el proyecto se topó con decenas de regresiones dentro del código. Una regresión es algo que antes funcionaba y que después de una actualización dejó de hacerlo.
El compilador no tiene idea, por ejemplo, de si las funciones están en el orden correcto, de si el trabajo se completa a un costo aceptable, de si cumple los requisitos que el desarrollador nunca escribió, ni de si el resultado es coherente consigo mismo.
En la RustConf, celebrada en Montreal la semana pasada, la consultora Lisa Crossman advirtió sobre la práctica de tratar al compilador como un "oráculo", o sea como la última palabra sobre si un código Rust es válido.
"Rust le impide al agente escribir código con memoria insegura. No le impide al agente escribir el programa equivocado correctamente", dijo.
Un desarrollador humano con criterio trata al compilador como un profesor y descifra los errores como un camino hacia una mejor comprensión del dominio del lenguaje. Un modelo de lenguaje, en cambio, lo usa como una caja negra a la que puede golpear con rodeos burdos e ineficientes hasta que alguno pase el filtro. Quizás a eso apuntaba el creador de Zig, Andrew Kelley, cuando llamó al código Rust de Bun "basura sin revisar".
En el caso de Toub, las regresiones aprobadas por el compilador venían de semánticas y comportamientos ambiguos, de desvíos entre ramas, de funcionalidades que quedaron sin portar y de comportamientos distintos en el código de reemplazo.
"Eso no es de ninguna manera un argumento contra el compilador de Rust", escribió Toub. "Pero 'si compila, está correcto' sirve solamente como chiste".
