GitHub reconstruyó el runtime que sustenta GitHub Copilot CLI, la aplicación Copilot y Copilot SDK, después de que dependiera de TypeScript, Node.js y el motor V8. El resultado, según el material publicado en el blog de GitHub, supera las 800.000 líneas de Rust destinadas a producción, la mayoría desarrolladas con ayuda de agentes de inteligencia artificial mediante 128 solicitudes de extracción integradas gradualmente en la rama principal.
El autor afirma que el trabajo se completó en unos meses y con la participación principalmente de un solo desarrollador, mientras el resto del equipo continuaba desarrollando capacidades del runtime y ampliando el alcance de su uso. GitHub señala que el rendimiento mejoró «en órdenes de magnitud» después de la migración, sin ofrecer cifras detalladas en la parte disponible del material para medir dicha mejora.
El problema no estaba únicamente en la interfaz de línea de comandos
El runtime de Copilot no se limita a ejecutar la CLI. Es una capa compartida que utilizan varias versiones y productos, entre ellos GitHub Copilot CLI, la aplicación Copilot y Copilot SDK, además de VS Code, Visual Studio, Cloud Agent, Copilot Code Review, Copilot Cowork, Copilot Studio y las aplicaciones Excel, Outlook, PowerPoint y Word.
En el diseño anterior, el runtime y la interfaz de la CLI estaban muy entrelazados. Cuando los productos necesitaban acceso programático, el SDK se construía prácticamente sobre la CLI, ejecutando un proceso independiente de Node.js y comunicándose con él mediante JSON-RPC. Este enfoque era rápido y flexible, pero imponía un coste operativo a cada aplicación consumidora.
Crear un nuevo CopilotClient implicaba ejecutar un proceso adicional que alojaba Node.js y V8, analizar código JavaScript generado a partir de TypeScript y asumir la memoria asociada al motor. Además, los fallos en Node.js podían finalizar la sesión, mientras que las aplicaciones necesitaban supervisar al menos dos procesos. Según el material, los paquetes de SDK escritos en C#, TypeScript, Python, Rust, Go y Java asumían como mínimo unos 100 megabytes del conjunto de memoria de trabajo por el runtime adicional, incluso cuando no necesitaban Node.js para nada más.
¿Por qué se eligió Rust?
GitHub definió objetivos claros para la nueva capa: separar el runtime de la TUI, reducir las dependencias y el coste operativo, permitir la integración dentro del mismo proceso y mejorar la escalabilidad y la fiabilidad. También necesitaba una interfaz C ABI que permitiera utilizar el runtime desde las seis versiones del SDK mediante distintos mecanismos de FFI.
El material afirma que Rust ayudó a cumplir estos requisitos, además de proporcionar una cadena de herramientas compatible con una postura de seguridad más moderna, reducir los riesgos de la cadena de suministro y ofrecer un mayor respaldo para código correcto por diseño. Sin embargo, también aclara que la experiencia no constituye una recomendación para convertir cualquier proyecto grande de TypeScript a Rust: la elección respondió a requisitos específicos relacionados con el tiempo de inicio, la memoria, la integración y la previsibilidad del consumo de recursos.
Sustitución gradual en lugar de una reescritura integral
GitHub no ejecutó el proyecto mediante una rama de larga duración ni a través de una única conversión al final del proceso. Optó por un enfoque dentro de la rama principal, en el que cada componente de TypeScript se sustituía individualmente por un componente de Rust. Cada solicitud de extracción añadía una capa fina de enlace que invocaba Rust y eliminaba la implementación antigua en el mismo cambio, de modo que la rama siguiera siendo apta para su lanzamiento y el código nuevo se probara directamente dentro del sistema.
- El trabajo habitual del resto de los desarrolladores continuó sin detener el proyecto.
- Cada cambio se volvió más pequeño y fácil de revisar que una reescritura integral.
- Las pruebas de extremo a extremo de la CLI y el SDK se ejecutaron con cada paso.
- Las regresiones se detectaron y corrigieron durante la migración, en lugar de posponerlas hasta el momento de la conversión final.
GitHub también rechazó mantener durante mucho tiempo dos versiones paralelas de cada componente. El repositorio recibía cientos de solicitudes de extracción por semana, y mantener dos implementaciones en distintos lenguajes y dos conjuntos de dependencias habría aumentado la complejidad. La comparación entre dos versiones se vuelve más difícil en los componentes que gestionan estado mutable, como el formateo de sesiones, porque interactúan con callbacks y se conectan con amplias partes del sistema.
¿Qué revelan las cifras?
La estimación inicial, realizada en mayo de 2026, situaba el volumen en unas 130.000 líneas de TypeScript, pero no reflejaba la magnitud real del trabajo. Los componentes que se habían contabilizado dentro de la capa TUI se trasladaron posteriormente al runtime, mientras que seguía llegando nuevo código TypeScript al mismo tiempo que avanzaba la migración. Por ello, unas 430.000 líneas de TypeScript pasaron realmente por el proceso de traslado.
Durante el mismo periodo, se incorporaron al proyecto unas 300.000 líneas de producción de TypeScript y se eliminaron unas 430.000, mientras que se incorporaron unas 1.200.000 líneas de Rust y se eliminaron unas 365.000. Estas cifras muestran que la aparente estabilidad del volumen de TypeScript en el repositorio no significaba que no hubiera avances, sino que ocultaba un gran movimiento de adiciones, eliminaciones y redistribución de responsabilidades.
¿Por qué importa esta noticia?
El valor práctico de la experiencia no reside únicamente en el uso de Rust, sino en la forma de gestionar la reescritura de una capa fundamental compartida por numerosos productos. La sustitución atómica de cada componente, manteniendo la rama apta para su lanzamiento y ejecutando las pruebas de forma continua, reduce los riesgos de una «gran conversión» y facilita revertir los cambios o localizar el origen de un fallo.
Por otro lado, el material no demuestra que este enfoque sea adecuado para cualquier organización ni que los agentes de inteligencia artificial puedan garantizar por sí solos la calidad de una reescritura de esta magnitud. Además, la parte disponible no ofrece mediciones publicadas del consumo antes y después, ni detalla el coste humano de las revisiones, las pruebas o la corrección de regresiones. Por tanto, la lección más clara está relacionada con la ingeniería gradual y la separación de capas, no con considerar Rust o los agentes como una solución general para todas las migraciones.