GitHub reescribe el runtime de Copilot en Rust: 800.000 líneas y 128 pull requests
El motor del agente de Copilot deja TypeScript, Node.js y V8 para pasar a Rust en producción. La mayor parte del código lo escribieron agentes de IA, sin un corte único.
GitHub ha reescrito de arriba abajo el runtime del agente de Copilot, el motor que sostiene el CLI, la aplicación de Copilot y el SDK, y lo ha pasado de TypeScript sobre Node.js y V8 a más de 800.000 líneas de Rust en producción. La mayor parte del código la escribieron agentes de IA, repartidos en 128 pull requests que fueron entrando en la rama principal de forma incremental, sin esperar a un corte único al final.
La operación no la hizo un equipo entero durante uno o dos años, como habría sido lo habitual, sino principalmente un solo desarrollador en unos pocos meses, mientras el resto seguía ampliando las capacidades del runtime. Los fallos de regresión que aparecieron se corrigieron sobre la marcha. GitHub dice que el rendimiento ha mejorado en órdenes de magnitud; la cifra es suya, no de una medición externa.
Por qué había que portarlo
El runtime no es solo el motor del CLI. Es una pieza compartida que hay por debajo de VS Code, Visual Studio, el agente cloud de Copilot, Copilot Code Review, Copilot Cowork, Copilot Studio y varios productos de Office. Casi todos empezaron con su propio bucle de agente y acabaron sustituyéndolo por el SDK, que es la puerta de entrada al runtime. La idea es que un arreglo en un sitio arregle todos los productos a la vez, algo que pesa mucho en un sector donde el bucle de agente tiene que seguir siendo competitivo cada pocos meses.
El problema era la naturaleza de lo que se compartía. El CLI estaba escrito en TypeScript sobre Node.js y V8, con Ink y React para la interfaz de terminal. Para una aplicación de consola es una elección razonable. Deja de serlo cuando esa misma implementación tiene que vivir dentro de otros programas, con requisitos de arranque rápido y de densidad de servidores por el consumo de memoria.
A eso se sumó la arquitectura. La interfaz y el runtime quedaron entrelazados, y cuando hizo falta un SDK para acceder al motor por programa, se tomó la decisión pragmática de montarlo encima del CLI, justo al revés de lo que dicta la lógica. El CLI ganó un modo headless que leía comandos de stdin y escribía en stdout, y un protocolo JSON-RPC se encargaba de mover las llamadas entre el proceso externo y el CLI.
El resultado: crear un CopilotClient lanzaba un subproceso con Node y V8 dentro. Cada consumidor del SDK en C#, Python, Go, Java y Rust cargaba con un segundo runtime de lenguaje por cliente, con un mínimo del orden de 100 MB de working set que su aplicación no necesitaba para nada. Y cada evento, cada mensaje y cada lectura o escritura del sistema de ficheros de sesión cruzaba una frontera entre procesos.
Lo que cambia para quien lo despliega
Menos capas móviles y un binario nativo. Eso se traduce en arranque más rápido, menos memoria por instancia y mejor densidad cuando el runtime se embebe en otro servicio. Para quien integra el SDK desde Go o Java, la diferencia es que deja de arrastrar un intérprete de JavaScript solo para hablar con el agente.
Queda por ver el detalle completo del protocolo y hasta qué punto se mantiene la compatibilidad hacia atrás de las API del SDK, que es lo que decidirá si actualizar cuesta una tarde o una semana.
