El ingeniero de GitHub Stephen Toub publicó, el 16 de septiembre, una retrospectiva de una reescritura a gran escala liderada por el agente Copilot: el runtime del agente Copilot se convirtió por completo de TypeScript/Node.js a Rust. Las aproximadamente 430.000 líneas originales de TypeScript en producción terminaron convertidas en 832.378 líneas de Rust en producción, además de 468.000 líneas de pruebas unitarias en Rust y 174.000 líneas de pruebas de extremo a extremo.
El trabajo se extendió del 12 de mayo al 21 de agosto, unas 14,5 semanas. Durante ese periodo se fusionaron 128 pull requests de forma incremental en la rama main, con lanzamientos continuos: en total, 135 versiones (100 prelanzamientos, 35 versiones estables), un promedio de unas 1,3 al día.
La mayor parte del código lo escribió el modelo: ¿qué le queda al humano?
El veredicto de Toub sobre esta práctica es directo:
"A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months."
Un proyecto que, antes de los agentes, habría requerido a todo un equipo de desarrolladores durante uno o dos años, ahora se completó principalmente por un solo desarrollador en apenas unos meses.
Los modelos principales fueron Claude Opus 4.8, GPT-5.6 Sol y la serie Claude Haiku; los subagentes encargados de optimizar el rendimiento se inclinaron por Opus 4.8 y GPT-5.6 Sol. Aquí se aprecia una señal reveladora: en esta reescritura de nivel de producción de su propio componente, GitHub (del grupo Microsoft) utilizó principalmente modelos de su competidor Anthropic, y no exclusivamente de OpenAI.
Las tareas humanas quedaron muy bien delimitadas. En las interacciones de este ingeniero líder, el 31% del tiempo se dedicó a "revisión, pruebas y CI", el 17,4% a "cuestionar decisiones técnicas" y el 15% a "forzar que el trabajo se completara por completo". La última palabra sobre arquitectura, decisiones de diseño y fusiones finales siempre quedó en manos humanas. El modelo se encargó del volumen de código; el humano, de la dirección y la validación.
La verificación se apoyó en las pruebas existentes: unos cincuenta tropiezos
Esta reescritura no estableció un nuevo conjunto de criterios de aceptación; en su lugar, se hizo que las pruebas de extremo a extremo ya existentes se ejecutaran continuamente sobre el nuevo código en Rust, con despliegues incrementales para que las regresiones salieran a la luz en un alcance reducido y se detectaran a tiempo. Algunas cifras técnicas del proceso también resultan reveladoras: la tasa de aciertos de la caché de prompts alcanzó el 96,22%, y la compresión de contexto se activó 5.116 veces a lo largo de las sesiones.
Los tropiezos también se documentaron con honestidad. A lo largo de todo el proceso hubo más de 50 problemas conocidos, divididos en cinco categorías: migración incompleta, problemas de estado y ciclo de vida, inconsistencias en el contrato de comportamiento, problemas en el límite con el host, y expectativas de prueba mal escritas. La gran mayoría se corrigió antes de llegar a la versión estable. Esta última categoría merece especial atención para quienes hacen migraciones: cuando se usan pruebas antiguas para validar una implementación nueva, a veces el error está en la prueba, no en el código nuevo.
Qué significa esto para los equipos de ingeniería
Casos como este, de "usar IA para rehacer por completo un componente propio central", dicen más sobre los límites reales de los agentes de programación actuales que cualquier tabla de benchmarks. Hay tres lecciones directamente aplicables: primero, no hay que esperar una reescritura de una sola vez: los 128 pull requests fusionados de forma incremental y varios lanzamientos al día solo funcionan gracias a la integración continua, que reparte el riesgo; segundo, los criterios de aceptación deben fijarse de antemano, ya que aquí todo dependió de las pruebas E2E existentes como referencia, y sin esa referencia no hay forma de juzgar si el modelo "escribió bien"; tercero, el esfuerzo humano se desplazó de escribir código a revisar, decidir y detectar huecos, lo que amplía en un orden de magnitud la escala de reescritura que una sola persona puede supervisar.
Conviene retener un matiz: las ventajas arquitectónicas (integración en el mismo proceso, menor consumo de memoria, arranque más rápido) se describen en el texto original solo de forma cualitativa, sin cifras de antes y después sobre memoria, latencia o rendimiento. Cuánto beneficio real de rendimiento trajo la reescritura es algo que, por ahora, no se puede verificar a partir de esta retrospectiva. El camino de TypeScript a Rust tampoco es estándar para la mayoría de los equipos: solo funciona cuando ya existe un conjunto de pruebas sólido y la disposición a lanzar versiones a diario.
Fuentes: GitHub Blog (Stephen Toub), CocoLoop; las cifras de 832.000 líneas, 128 pull requests, 14,5 semanas, 96,22% de tasa de aciertos de caché y unos 50 problemas conocidos se contrastaron con la retrospectiva oficial.