GitHub reescribe el runtime de Copilot en 832.000 líneas de Rust
Índice de contenidos
Claves de la noticia
- GitHub ha sustituido por Rust todo el runtime que comparten Copilot CLI, la app, los SDK y numerosas integraciones de Microsoft.
- La migración produjo 832.378 líneas de Rust de producción y 468.689 de pruebas unitarias mediante 128 pull requests, con agentes escribiendo la mayor parte del código.
- Las pruebas de GitHub reducen entre un 94,0 % y un 95,3 % tres flujos interactivos, aunque la compañía reconoce decenas de regresiones durante el cambio.
GitHub ha completado una de las migraciones de software asistidas por IA más grandes que ha documentado públicamente: el runtime de Copilot ha pasado de TypeScript sobre Node.js y V8 a una implementación íntegra en Rust. El equipo integró el cambio por piezas, lo distribuyó continuamente a usuarios reales y empleó Copilot para escribir la mayor parte de las más de 800.000 líneas de producción resultantes.
Un solo motor debajo de productos muy distintos
El componente coordina modelos, herramientas, sesiones, archivos, autenticación y persistencia. Nació para el agente en la nube, pero terminó sirviendo a Copilot CLI, la aplicación, seis SDK y funciones de VS Code, Visual Studio, revisión de código, Cowork, Studio y Office.
Cada cliente del SDK levantaba la CLI como subproceso, cargaba Node y V8, y cruzaba una frontera JSON-RPC incluso para llamadas que conceptualmente podían ejecutarse dentro de la aplicación. GitHub cifra el consumo mínimo aproximado en 100 MB de memoria de trabajo por cliente, además del tiempo de arranque.
La solución conserva dos puertas sobre el mismo motor nativo: un complemento para Node y una ABI de C con solo 19 funciones exportadas. Esta última permite que cada SDK cargue el runtime en su propio proceso. La arquitectura elimina Node y V8 del camino obligatorio sin exigir que todas las aplicaciones consumidoras estén escritas en Rust.
La mejora interactiva supera el 94 %
GitHub publicó cuatro escenarios contra un servidor local de respuestas deterministas. Esa metodología excluye deliberadamente inferencia y latencia de red: mide arranque, creación de sesión, eventos, persistencia y cierre, justo la parte alterada por la migración. Un cálculo sobre esos valores muestra que los tres flujos interactivos reducen su duración entre un 94,0 % y un 95,3 % cuando el runtime se carga dentro del proceso.
| Escenario | TypeScript/Node | Rust en proceso | Reducción |
|---|---|---|---|
| Cliente, sesión y un turno | 5,25 s | 292 ms | 94,4 % |
| Reanudar 32 turnos | 5,64 s | 264 ms | 95,3 % |
| Diez ciclos concurrentes | 12,34 s | 742 ms | 94,0 % |
| Mil ciclos de un turno | 132,52 s | 20,93 s | 84,2 % |
La tabla no demuestra que Copilot genere código 18 veces más rápido: el modelo está fuera de la prueba. Sí demuestra que el envoltorio local puede dejar de dominar tareas cortas. En cliente, sesión y un turno se eliminan unos 4,96 segundos; en la reanudación de 32 turnos, unos 5,38. Cuanto más breve es la respuesta del modelo, más visible resulta el coste fijo que GitHub acaba de retirar.
El escenario de mil ciclos mejora menos en porcentaje porque el trabajo repetido que permanece gana peso. Aun así, pasa de más de dos minutos a unos 21 segundos. GitHub advierte además de que el período de comparación incluyó otros cambios, de modo que no atribuye toda la diferencia exclusivamente a Rust. Esa cautela impide presentar el ejercicio como un benchmark universal entre lenguajes.
128 cambios en lugar de un gran salto
El plan inicial calculó unas 130.000 líneas de TypeScript, pero el objetivo siguió creciendo mientras otros desarrolladores añadían funciones. GitHub estima que por la migración pasaron alrededor de 430.000 líneas de producción de TypeScript. El resultado final alcanzó 832.378 líneas de Rust de producción y 468.689 de pruebas unitarias, además de 174.675 líneas de pruebas de extremo a extremo en TypeScript y unas 130.000 repartidas entre los SDK.
Un recuento de esas dos primeras cifras indica que las pruebas unitarias equivalen al 56,3 % del volumen de producción en Rust. No es una medida de cobertura, pero sí revela el tamaño del arnés que acompañó al port. El trabajo aterrizó en 128 pull requests y, durante aproximadamente catorce semanas y media, la rama principal produjo 135 versiones: 100 preliminares y 35 estables. Cada componente reemplazó de forma incremental su equivalente anterior, manteniendo la rama publicable.
Esta estrategia contrasta con una reescritura de big bang. Cuando aparecía una regresión, el equipo podía relacionarla con una porción reciente y revertir o corregir sin esperar al cambio completo. Es una lección aplicable al uso empresarial de agentes: la velocidad para producir código no reduce el valor de acotar los cambios. La experiencia de Bolt Forge y sus trazas de programación ya mostró que los itinerarios de prueba, fallo y reparación son parte del activo, no residuos del proceso.
Los agentes aceleraron también los errores
GitHub había identificado decenas de regresiones al 14 de septiembre, todas corregidas entonces. Las familias más frecuentes fueron contratos de comportamiento distintos, cambios de estado o ciclos de vida, partes omitidas durante la traducción, límites con el host y pruebas que validaban una conducta equivocada. Un ejemplo sencillo: valores conceptualmente enteros terminaron como números de coma flotante y rompieron SDK con tipos estrictos.
La fuente declara que ninguna regresión conocida procedió de un bloque unsafe, pero no convierte el sistema en automáticamente seguro. Dependencias, herramientas de compilación, bibliotecas C y contratos FFI siguen cruzando fronteras. Tampoco garantiza que no queden fallos silenciosos. Esa franqueza encaja con los seis incidentes de agentes publicados por OpenAI: una instrucción correcta no sustituye pruebas, permisos y observabilidad sobre la ejecución.
Elegir un runtime depende del contrato: GitHub necesitaba arranque rápido, memoria contenida, ABI estable e integración dentro de procesos ajenos.
La escala cambia qué proyectos resultan viables
Stephen Toub, responsable técnico de la migración, sostiene que antes habría requerido un equipo durante uno o dos años y habría perdido frente a otras prioridades. Con agentes, un desarrollador coordinó la mayor parte del port durante unos meses, apoyado por especialistas, revisores, integración continua y usuarios de versiones preliminares. No fue una orden única para reescribir el repositorio: hubo instrucciones específicas, reparto de componentes, revisiones y pruebas en cada paso.
El resultado permite una conclusión más útil que “la IA escribió 800.000 líneas”. Los agentes abarataron una migración porque el equipo convirtió el trabajo en 128 unidades revisables y mantuvo un sistema de pruebas casi tan relevante como el código generado. Las mejoras interactivas del 94 % al 95,3 % muestran el premio técnico; las decenas de regresiones muestran el precio de traducir semántica a esa velocidad. La contribución duradera no es el volumen producido, sino un método: migración incremental, medición aislada del componente y límites explícitos para que la productividad no oculte los fallos.
