Migración del runtime de GitHub Copilot a Rust: los agentes hicieron asequible la reescritura

GitHub completó una migración del runtime de GitHub Copilot a Rust que abarcó aproximadamente 830.000 líneas de producción, una reescritura que, según la empresa, los agentes hicieron económicamente viable. El proyecto sustituyó la implementación en TypeScript del runtime, mientras el propio Copilot ayudaba a generar, revisar, probar y corregir el nuevo código.

No se trataba de una demostración construida alrededor de una biblioteca aislada. El runtime coordina modelos, herramientas, sesiones, extensiones y aplicaciones host dentro de un producto de programación en producción. GitHub siguió lanzando versiones públicas de la CLI mientras los ingenieros modificaban la maquinaria que había debajo.

El conflicto más relevante no es Rust frente a TypeScript. Es la velocidad del código generado por agentes frente al trabajo de verificación humana necesario para mantener una gran migración conductualmente correcta. Los resultados de GitHub sugieren que los agentes pueden comprimir el tiempo de implementación, pero no eliminan la responsabilidad de ingeniería.

El proyecto se desarrolló del 12 de mayo al 21 de agosto, según el detallado relato de GitHub sobre la migración del runtime. Durante ese período, el equipo integró 128 pull requests de migración y lanzó 135 versiones públicas de la CLI.

Esta secuencia importa porque desafía una suposición habitual sobre las reescrituras. Las grandes reescrituras suelen exigir una larga congelación de funcionalidades, un reemplazo separado o años de migración incremental. GitHub, en cambio, modificó la implementación mientras mantenía el producto en marcha.

El resultado ofrece a los líderes de ingeniería una prueba a escala de producción poco común del desarrollo de software asistido por IA. También aporta una advertencia: la generación de código fue solo una parte del trabajo y, con frecuencia, no la más difícil.

Qué cambió con la migración del runtime de GitHub Copilot a Rust

GitHub sustituyó un runtime de producción sin tratar la reescritura como un proyecto separado y oculto que solo saldría a la luz tras completarse.

La arquitectura anterior situaba un límite de proceso entre los kits de desarrollo de software y la CLI de Copilot. Un límite de proceso exige que los componentes se comuniquen entre procesos distintos del sistema operativo, normalmente mediante mensajes serializados y gestión del ciclo de vida.

El nuevo diseño admite alojamiento tanto dentro del proceso como fuera de él. El alojamiento dentro del proceso sitúa el runtime dentro de la aplicación que lo llama, evitando algunos costes de arranque, comunicación y memoria asociados a un proceso independiente.

Este cambio arquitectónico amplió el alcance del proyecto más allá de traducir sintaxis. El equipo tuvo que preservar el comportamiento observable del runtime mientras modificaba la propiedad, la concurrencia, el manejo de errores, la gestión de estado y los límites de integración.

El historial final de código de GitHub mostró aproximadamente 830.000 líneas de Rust de producción y 469.000 líneas de pruebas unitarias en Rust. La implementación en TypeScript se redujo a cero al final del proyecto.

Estas cifras requieren contexto. Las líneas de código no miden de forma consistente la calidad, la dificultad ni la producción de los desarrolladores. El código generado puede ser verboso, y las pruebas pueden incluir fixtures, asistentes o casos ampliados mecánicamente.

Sin embargo, las cifras establecen la escala de la migración. No fue una conversión de fin de semana de una utilidad de línea de comandos. Involucró un runtime con múltiples hosts, comportamiento de extensiones, orquestación de modelos, sesiones persistentes, integraciones específicas de plataforma y bibliotecas externas.

GitHub utilizó una capa temporal de interoperabilidad durante la transición. La interoperabilidad permite que código escrito en distintos lenguajes se invoque a través de una interfaz definida mientras ambas implementaciones siguen activas.

El proyecto expuso funciones de Rust mediante N-API, la interfaz estable utilizada por módulos nativos en aplicaciones Node.js. De este modo, los llamadores de TypeScript podían invocar componentes de Rust recién migrados antes de que se trasladara toda la cadena de dependencias.

La superficie temporal creció a medida que los ingenieros introducían implementaciones en Rust bajo llamadores existentes de TypeScript. Más adelante se redujo cuando esos llamadores pasaron a Rust y dejaron de necesitar el puente.

Ese crecimiento y posterior reducción es importante. La interoperabilidad permanente puede convertirse en una arquitectura propia, con costes de serialización, tipos duplicados y complejas reglas de propiedad. GitHub trató el puente como andamiaje, no como destino.

La migración también avanzó desde bases más pequeñas hacia componentes de orquestación y sesión más amplios. Ese orden proporcionó a agentes e ingenieros interfaces de Rust establecidas antes de abordar código con un alcance conductual más amplio.

Mientras tanto, el equipo lanzó 135 versiones públicas de la CLI durante el período de migración. Esa cifra superó los 128 pull requests de migración, lo que demuestra que la entrega habitual del producto continuó junto a la reescritura.

El resultado cambia cómo puede verse una reescritura viable. En lugar de financiar un equipo paralelo para un reemplazo prolongado, una organización puede utilizar agentes para acelerar unidades de migración acotadas.

Sin embargo, esa posibilidad depende de pruebas, interfaces estables y revisores que comprendan el comportamiento original. Sin esos controles, una traducción rápida puede simplemente producir software incorrecto con mayor rapidez.

Por qué los agentes hicieron asequible una reescritura de 800.000 líneas

El cambio económico procedió de la implementación paralela y el contexto persistente, no de que un agente decidiera de forma independiente cómo debía funcionar el runtime.

Las reescrituras tradicionales se enfrentan a una dura curva de costes. Los ingenieros deben leer el código existente, reconstruir contratos no documentados, diseñar interfaces de reemplazo, implementarlas y comparar el resultado con el comportamiento en producción.

Cada etapa compite con el desarrollo de funcionalidades y la respuesta a incidentes. Cuanto más dura la reescritura, más cambia el producto original, creando un objetivo móvil para el equipo de reemplazo.

Los agentes de programación reducen parte de esa carga de lectura e implementación. Pueden rastrear referencias, redactar módulos equivalentes, generar pruebas, ejecutar comandos de compilación y revisar código tras fallos.

El trabajo de GitHub muestra cómo esta ayuda escala más allá del autocompletado. Los agentes operaron mediante sesiones de larga duración y delegaron subtareas a agentes secundarios, creando flujos de trabajo paralelos en torno a un objetivo compartido de migración.

Una sesión que migró session.ts se prolongó durante 25 horas. Utilizó cinco subagentes y creó 15 sesiones secundarias a lo largo de siete oleadas de trabajo.

Otra sesión se centró en la orquestación de modelos durante 42 horas e involucró a 126 subagentes. La cronología de GitHub indica que la mayor parte del código apareció durante las primeras 12 horas, seguidas de una amplia validación y revisión.

Este patrón revela un mecanismo central. Los agentes pueden producir rápidamente una primera implementación, pero la confianza se acumula mucho más despacio mediante compilación, pruebas, comparación e inspección humana.

Una migración independiente del runtime de extensiones duró 88 horas. La lectura, escritura, compilación y revisión permanecieron entrelazadas durante gran parte de esa sesión, en lugar de formar fases secuenciales claramente delimitadas.

La diferencia importa porque no todos los componentes admiten el mismo flujo de trabajo. Un módulo relativamente autocontenido puede pasar de la generación a la validación. Un runtime con muchos límites requiere ciclos repetidos a medida que nuevas interacciones se hacen visibles.

El almacenamiento en caché de prompts también dio forma a la economía. En todas las sesiones de migración, el 96,22 por ciento de la entrada de prompts procedía de lecturas de caché. Las escrituras de caché representaron el 3,07 por ciento, mientras que la entrada nueva supuso el 0,71 por ciento.

Una caché de prompts reutiliza contexto de modelo procesado previamente, reduciendo la necesidad de recalcular instrucciones repetidas y material del repositorio. Puede hacer que las sesiones largas sean más económicas y rápidas cuando gran parte de su contexto permanece estable.

Estos porcentajes no establecen el coste financiero total del proyecto. GitHub no publicó una comparación convencional de trabajo entre una migración asistida por agentes y una reescritura completamente manual.

Sí muestran que el flujo de trabajo dependía de la reutilización de contexto. Alimentar repetidamente un gran repositorio, instrucciones de diseño y hallazgos acumulados como entrada nueva crearía un perfil de costes diferente.

Aquí es donde la migración del runtime de GitHub Copilot a Rust se convierte en algo más que una historia de lenguajes. El proyecto puso a prueba si los agentes pueden seguir trabajando a través de un grafo de dependencias sin perder las decisiones establecidas por tareas anteriores.

Ese requisito se parece a la gestión del conocimiento dentro de cualquier gran organización de ingeniería. Las restricciones importantes se distribuyen entre código, pruebas, conversaciones sobre incidencias, notas de arquitectura y comentarios de revisores.

Los equipos que intenten proyectos similares necesitan una base de conocimiento de ingeniería fiable. Los agentes no pueden aplicar un contrato que no pueden recuperar, y las suposiciones no documentadas siguen siendo peligrosas independientemente de la calidad del modelo.

Por tanto, la migración modifica la ecuación de asequibilidad sin hacer que las reescrituras sean baratas por defecto. Los agentes reducen el coste marginal de leer y redactar, mientras las organizaciones siguen financiando la validación, la coordinación y el riesgo operativo.

La verdadera competencia es entre la velocidad de generación y la capacidad de revisión

Los propios datos de interacción de GitHub muestran que la atención humana se desplazó hacia comprobar, cuestionar y completar el trabajo de los agentes.

GitHub analizó 2.639 mensajes escritos por humanos durante la migración. De esos mensajes, el 31 por ciento se refería a revisión, pruebas o integración continua.

Otro 17,4 por ciento cuestionaba decisiones técnicas o de diseño. Un 15 por ciento adicional impulsaba al agente hacia la completitud, identificando a menudo trabajo que una primera pasada había pasado por alto.

En conjunto, estas categorías describen un cambio de rol. Los ingenieros dedicaron menos tiempo a escribir cada línea de implementación y más a especificar estándares, inspeccionar resultados y dirigir la recuperación.

Eso no significa que la contribución humana se hiciera menor. El trabajo de revisión puede exigir una concentración más profunda que escribir un módulo conocido, porque los revisores deben detectar diferencias conductuales sutiles en código generado que no les resulta familiar.

Las cinco categorías de regresiones identificadas por GitHub ilustran esa carga. Incluían migración incompleta, errores de estado y ciclo de vida, discrepancias en contratos de comportamiento, problemas en los límites del host y oráculos de prueba incorrectos.

La migración incompleta se produce cuando la nueva implementación omite una ruta, opción o efecto secundario presente en la original. Un agente puede producir código que compila mientras deja atrás un comportamiento poco utilizado.

Los fallos de estado y ciclo de vida son especialmente relevantes en Rust. Rust codifica reglas de propiedad y préstamo en tiempo de compilación, pero un programa aún puede modelar incorrectamente el estado de la aplicación.

Un compilador puede rechazar accesos inseguros a memoria sin saber que una sesión debería seguir disponible después de un evento concreto. La seguridad de tipos y la corrección del producto se solapan, pero no son idénticas.

Las discrepancias en los contratos de comportamiento surgen cuando dos implementaciones aceptan las mismas entradas pero difieren en tiempos, orden, texto de errores, reintentos o limpieza. El software posterior puede depender de esos detalles incluso cuando ninguna especificación formal los registra.

Los límites del host añaden otra capa. El runtime debe comportarse correctamente cuando está integrado en distintas aplicaciones o se ejecuta como un proceso independiente. La gestión del entorno, la cancelación, el acceso a archivos y la terminación de procesos pueden diferir entre hosts.

Los oráculos de prueba incorrectos generan el fallo más engañoso. Un oráculo de prueba define el resultado esperado utilizado para evaluar una implementación. Si un agente genera tanto el código como una expectativa equivocada, todas las pruebas pueden aprobarse mientras se preserva el comportamiento incorrecto.

Por eso las pruebas generadas a partir de la misma interpretación no pueden ofrecer una confirmación independiente. Los equipos necesitan trazas de producción, fixtures existentes, invariantes especificadas manualmente y comparaciones con la implementación anterior.

El código Rust de GitHub contenía 158 bloques unsafe. En Rust, unsafe permite operaciones específicas que el compilador no puede verificar por completo, como llamar a funciones externas o desreferenciar punteros sin procesar.

GitHub afirma que los 158 bloques aparecían en límites externos. Estos incluían interfaces de C, APIs de Windows, llamadas a POSIX y libc, SQLite, carga dinámica de bibliotecas y modificación del entorno de procesos.

Esa concentración encaja con el modelo de seguridad previsto por Rust. El lenguaje anima a los desarrolladores a aislar operaciones no verificables detrás de interfaces pequeñas, mientras mantiene el programa más amplio dentro de reglas comprobadas por el compilador.

La guía pertinente sobre unsafe Rust también establece una distinción crítica. unsafe flexibiliza determinadas comprobaciones del compilador, pero no suspende la responsabilidad del programador de cumplir los requisitos de seguridad.

Para los revisores, eso significa que el código inseguro merece una inspección específica. Los agentes pueden generar enlaces y wrappers, pero un wrapper aparentemente plausible aún puede usar un tiempo de vida, longitud de búfer, convención de llamada o regla de sincronización incorrectos.

El cuello de botella de la revisión también afecta a la planificación organizativa. Añadir más agentes aumenta rápidamente la capacidad de producción de código. No crea automáticamente más ingenieros que comprendan lo bastante bien el entorno de ejecución como para aprobar cambios.

Ese desequilibrio puede inundar a un equipo con trabajo aparentemente terminado. Las pull requests esperan más tiempo, los revisores cambian de contexto con mayor frecuencia y se acumulan inconsistencias sutiles entre ramas paralelas.

GitHub parece haber gestionado esa presión mediante componentes acotados, compilaciones repetidas, especialización de subagentes e integración continua. Los mensajes humanos muestran intervención activa, en lugar de una aceptación pasiva.

Por tanto, el principal adversario no es otro asistente de programación. Es la antigua suposición de que el rendimiento de implementación determina la velocidad del proyecto.

En las migraciones lideradas por agentes, la capacidad de revisión fiable se convierte en el recurso limitante. Los equipos que ignoren este cambio corren el riesgo de medir el código generado mientras pasan por alto la producción más lenta de confianza justificada.

Las mejoras de rendimiento no resuelven la cuestión de la corrección

El nuevo runtime se volvió drásticamente más rápido en las pruebas de GitHub, pero el rendimiento no puede demostrar la equivalencia de comportamiento ni generalizar el flujo de trabajo a todas las bases de código.

Del 12 de mayo al 21 de agosto, el ciclo de vida medido del cliente y la sesión cambió sustancialmente. Crear un cliente, iniciar una sesión, completar un turno y desmontarlo todo pasó de 5,25 segundos a 55,3 milisegundos en proceso.

Esta comparación representa una reducción de casi 95 veces en la duración medida. El rendimiento aumentó de 7,55 a 120 sesiones por segundo, o casi 16 veces la tasa anterior.

El cambio arquitectónico explica parte de la diferencia. Un runtime en proceso evita iniciar y coordinar un proceso CLI independiente para cada interacción.

Rust también ofrece a los desarrolladores control sobre la asignación de memoria, el diseño de datos y la concurrencia sin un runtime con recolección de basura. Sin embargo, las mediciones publicadas combinan cambios de lenguaje, arquitectura, implementación y optimización acumulada.

Por tanto, sería engañoso afirmar que sustituir TypeScript por Rust, por sí solo, produjo toda la mejora. Eliminar un límite de proceso puede transformar la latencia independientemente del lenguaje de implementación.

El benchmark también refleja la carga de trabajo y el entorno elegidos por GitHub. Los lectores no deberían trasladar directamente sus proporciones a mejoras esperadas en aplicaciones no relacionadas.

Aun así, la magnitud tiene implicaciones prácticas. Una menor latencia al iniciar sesiones puede hacer que las funciones de agentes integradas se sientan ágiles en editores, terminales y automatización en segundo plano.

Un mayor rendimiento de sesiones puede admitir más tareas simultáneas por host. También puede reducir la infraestructura necesaria para cargas de trabajo que crean y destruyen repetidamente sesiones de corta duración.

Estos beneficios explican por qué la reescritura tuvo valor estratégico más allá del mantenimiento del código. GitHub no se limitaba a cambiar una preferencia de lenguaje. Estaba modificando la facilidad con la que el runtime podía integrarse en otros productos.

El escepticismo comienza con la independencia de la evidencia. Los datos de migración, la taxonomía de regresiones, el análisis de interacciones y los benchmarks proceden todos del propio relato de GitHub.

GitHub proporcionó mediciones inusualmente detalladas, pero investigadores externos no han reproducido la migración completa. El contexto del repositorio, las pruebas internas, la experiencia del personal, el acceso a modelos y las herramientas operativas condicionaron el resultado.

El proyecto también involucró al equipo responsable tanto del runtime original como de su reemplazo. Eso proporciona a los revisores conocimientos valiosos, pero hace que el ejercicio sea distinto al de un equipo externo que moderniza un sistema heredado desconocido.

Un runtime maduro puede tener una cobertura de pruebas más sólida y límites de módulos más limpios que muchas aplicaciones corporativas. Por el contrario, sus hosts multiplataforma y el comportamiento de los agentes pueden hacerlo más complejo en otros sentidos.

Las 469.000 líneas de pruebas unitarias son, por tanto, alentadoras pero no concluyentes. La cantidad de pruebas no puede demostrar que comportamientos importantes de producción sigan sin probarse.

Las cinco clases de regresiones conocidas demuestran que el éxito de la compilación no era suficiente. Ni siquiera las garantías de memoria de Rust podían identificar comportamiento ausente, expectativas equivocadas o contratos de producto incorrectos.

Los modelos de agentes también cambian rápidamente. GitHub utilizó una combinación de modelos en las sesiones principales y los subagentes, incluidos distintos sistemas de alta capacidad y menor latencia.

Esa diversidad hace que el flujo de trabajo sea resistente a los límites de un único modelo, pero complica la reproducción. Un equipo futuro puede recibir resultados diferentes incluso con prompts y estado del repositorio similares.

La seguridad merece igual cautela. El código generado puede reproducir patrones vulnerables del código circundante o introducir supuestos inseguros en los puntos de integración.

Rust reduce varios riesgos de seguridad de memoria, pero no puede validar la lógica de autorización, la gestión de secretos, la construcción de comandos ni la fiabilidad de las entradas externas. Los revisores deben examinar directamente esas propiedades.

Los agentes de larga duración generan otra preocupación operativa. Una sesión que dura 25, 42 u 88 horas necesita límites de recursos, registros observables, puntos de control recuperables y límites claros de autoridad.

Sin esos controles, un agente puede consumir una cantidad considerable de cómputo, repetir enfoques fallidos o ampliar una tarea más allá de su alcance previsto. Los subagentes paralelos multiplican tanto el trabajo útil como el riesgo de coordinación.

El resultado de GitHub respalda una conclusión prudente. Las grandes reescrituras asistidas por agentes han pasado de demostraciones especulativas a ingeniería de producción creíble.

No respalda la afirmación de que cualquier organización pueda entregar un sistema heredado a un agente y recibir un reemplazo Rust fiable. El ingrediente que falta no es otro prompt. Es un sistema de evidencia para validar el comportamiento.

Lo que la reescritura en Rust de GitHub Copilot pone bajo presión

La migración presiona a los equipos de software para rediseñar el desarrollo en torno a la evidencia de revisión, en lugar de tratar a los agentes como programadores individuales más rápidos.

La primera presión recae sobre los responsables de ingeniería que planifican trabajos de modernización. Los proyectos antes descartados por ser demasiado caros ahora merecen una nueva estimación, especialmente cuando pueden dividirse en componentes verificables.

Eso no significa que toda reescritura deba seguir adelante. El mantenimiento incremental puede seguir siendo más seguro cuando el comportamiento se entiende mal, las dependencias son inestables o el reemplazo no ofrece una ganancia operativa medible.

La diferencia es que el coste de implementación ya no domina la estimación de la misma manera. Los responsables deben modelar la calidad de las pruebas, la disponibilidad de revisores, los límites de la migración, las opciones de reversión y la comparación en producción.

La segunda presión recae sobre los proveedores de asistentes de programación. Generar una función o explicar un archivo ya no es el benchmark más exigente.

Los clientes de producción preguntarán cada vez más si los agentes pueden mantener el contexto durante semanas, coordinar tareas paralelas, preservar contratos y proporcionar evidencia para cada cambio.

También esperarán que los agentes se recuperen de fallos. Un agente de migración útil debe leer la salida de compilación, aislar regresiones, revisar su enfoque y saber cuándo se requiere una decisión humana.

La tercera presión recae sobre los equipos de lenguajes y plataformas. Rust ganó una referencia de producción destacada, pero la lección más profunda se refiere a las herramientas de migración.

Las interfaces estables de funciones externas, los enlaces automatizados, los modelos de datos compatibles y los puentes temporales permiten a los equipos avanzar por segmentos de dependencias. Sin esos mecanismos, los agentes afrontan cambios mayores y de todo o nada.

La especificación oficial de N-API ilustra por qué importa un límite nativo estable. Separa los módulos nativos de muchos cambios dentro del motor JavaScript.

Para GitHub, ese límite permitió que los componentes Rust atendieran a los llamadores TypeScript durante la transición. El enfoque redujo la necesidad de portar simultáneamente cada llamador y dependencia.

La cuarta presión recae sobre las organizaciones que cuentan producción en vez de resultados. Las líneas generadas, los prompts enviados o las horas de agentes consumidas dicen poco sobre el valor en producción.

Los indicadores más sólidos de GitHub fueron conductuales y operativos. El runtime alcanzó cero TypeScript, siguió lanzándose públicamente, redujo la latencia medida, aumentó el rendimiento y expuso patrones de regresión conocidos.

Los informes futuros deberían ir más allá. Deberían incluir defectos que llegaron a producción, frecuencia de reversión, horas de revisión, tasas de incidentes y consumo total de cómputo.

Tres señales determinarán si este proyecto se convierte en un modelo repetible.

La primera es la fiabilidad en producción tras la migración. Lanzamientos estables, bajas tasas de regresión y menos incidentes del runtime reforzarían la idea de que los ports rápidos liderados por agentes pueden preservar un comportamiento maduro.

Un patrón de correcciones de emergencia debilitaría esa idea, incluso si Rust mejorara el rendimiento. La cuestión crítica no es si las pruebas pasaron antes de integrar los cambios, sino si los usuarios experimentan un comportamiento equivalente o mejor.

La segunda señal es la reproducción por equipos ajenos a GitHub. Las organizaciones independientes deben documentar migraciones de escala comparable, cronogramas, métodos de verificación y resultados operativos.

Las historias de éxito más pequeñas ayudarán, pero una comparación convincente requiere sistemas complejos de producción. Idealmente, esos sistemas tendrán arquitecturas distintas y un acceso menos directo a los autores originales.

La tercera señal es la propia conversión del flujo de trabajo en producto por parte de GitHub. La orquestación reutilizable, la planificación de migraciones, las puertas de revisión y los resúmenes de evidencia demostrarían que el método se extiende más allá de un proyecto interno.

GitHub ya ofrece flujos de trabajo de Copilot coding agent para desarrollo delegado. El siguiente paso es demostrar que la coordinación a escala de repositorio puede ser fiable para equipos de ingeniería convencionales.

Estas señales deberían importar más a los desarrolladores que las afirmaciones sobre programación autónoma. Los datos de mensajes humanos de la migración muestran que la experiencia siguió siendo central, pero su aplicación cambió.

Los ingenieros necesitan cada vez más definir invariantes, inspeccionar límites, comparar comportamientos y organizar un contexto técnico duradero. La velocidad de escritura importa menos cuando los agentes pueden redactar miles de líneas.

Los compradores empresariales deberían plantear preguntas igualmente concretas. ¿Qué acciones requieren aprobación? ¿Cómo preserva el sistema el contexto? ¿Pueden los revisores rastrear los cambios generados hasta las pruebas y los requisitos establecidos?

También deberían preguntar cómo gestiona el flujo de trabajo las tareas inacabadas. Un runtime parcialmente migrado puede crear implementaciones duplicadas, puentes temporales y una propiedad confusa, a menos que el sistema rastree cuidadosamente las dependencias.

Para los trabajadores del conocimiento, el patrón más amplio va más allá del software. Los agentes abaratan la producción inicial, mientras que la verificación y el contexto se vuelven más valiosos.

Un equipo puede usar un sistema de conocimiento personal para preservar decisiones y evidencias a lo largo de proyectos extensos. Ese registro se vuelve esencial cuando las máquinas producen trabajo más rápido de lo que las personas pueden reconsiderar sus supuestos.

La migración del runtime de GitHub Copilot a Rust resulta convincente porque expone ambas mitades de la transición. Los agentes cambiaron la escala de implementación asequible, mientras que los humanos asumieron la carga del juicio.

Conviene seguir la fiabilidad de las próximas versiones de Copilot, las migraciones independientes y las herramientas de flujo de trabajo de GitHub. Si los tres elementos se sostienen, este proyecto parecerá un modelo de ingeniería en lugar de un caso interno excepcional.

La pregunta para los equipos ahora es práctica: ¿qué reescritura aplazada cuenta con suficientes pruebas, valor medible y capacidad de revisión como para justificar una prueba controlada asistida por agentes?