Specification-first convergence with an AI coding agent: a case study of dismantling a core architectural invariant across 189 files in a 717k-line codebase with no test oracle and no human code review

En el mundo del software, los programas se construyen como ciudades vastas e intrincadas. Consisten en millones de líneas de instrucciones que le dicen a una computadora cómo comportarse, cómo recordar cosas y cómo reaccionar cuando un usuario hace clic en un botón. Durante décadas, la forma estándar de cambiar estas ciudades ha sido enviar a un arquitecto humano para inspeccionar cada nuevo ladrillo que una inteligencia artificial pudiera colocar. Esta revisión humana se considera esencial porque las conexiones entre las diferentes partes de un programa son tan profundas y enredadas que un pequeño error en un rincón puede causar un colapso en otro. Cuando un cambio es lo suficientemente grande como para tocar cientos de archivos a la vez, la tarea de revisar el trabajo se convierte en un cuello de botella; ningún humano puede sostener todo el mapa de los cambios en su mente al mismo tiempo. Esta limitación ha llevado a muchos a creer que, para los cambios arquitectónicos más complejos, el único camino seguro es demoler la vieja estructura y construir una nueva desde cero, un proceso que es lento, costoso y arriesgado.

Un estudio de caso reciente desafía la idea de que la revisión humana es la única forma de garantizar la seguridad en cambios tan masivos. Explora un método donde el enfoque cambia de revisar el producto terminado a perfeccionar el plano antes de que se coloque el primer ladrillo. En lugar de pedirle a una inteligencia artificial que escriba código y luego esperar que un humano encuentre los errores, este enfoque le pide a la máquina que primero escriba una descripción formal y detallada de exactamente lo que pretende hacer. Esta descripción es luego revisada rigurosamente contra el código existente, no para ver si el código funciona, sino para ver si el plan en sí tiene sentido. El plan se refina, se corrige y se congela hasta que deja de producir hallazgos. Solo entonces la máquina comienza a construir, e incluso entonces, es auditada constantemente contra ese plan congelado. El resultado es una demostración de que un cambio arquitectónico masivo y complejo puede completarse sin que un solo humano haya leído jamás el código generado, siempre que el proceso de definir y verificar la intención sea lo suficientemente robusto.

El experimento tuvo lugar dentro de una aplicación de software propietaria de gran tamaño utilizada para la asistencia de codificación mediante inteligencia artificial. El sistema, escrito en un lenguaje llamado TypeScript, contenía más de 717,000 líneas de código distribuidas en casi 3,650 archivos. Era una pieza de software viva y dinámica utilizada diariamente, no un modelo teórico. La tarea asignada al agente de inteligencia artificial fue desmantelar una regla central que había gobernado el sistema desde su creación. Esta regla, conocida como un invariante, garantizaba que cada vez que un usuario iniciara una conversación con la IA, la ventana que mostraba esa conversación permanecería abierta durante toda la duración de la solicitud. Si el usuario cerraba la ventana, la conversación moría. El objetivo era romper esta regla: el usuario debería poder cerrar la ventana, y la conversación continuaría ejecutándose en segundo plano, lista para ser reabierta y reanudada exactamente donde se dejó, sin perder ningún dato ni repetir ninguna palabra.

Este cambio específico se consideró casi imposible de lograr mediante una refactorización estándar. En la evaluación del autor, la interdependencia del código era tan estrecha que modificar el ciclo de vida de una conversación sin romper todo el sistema requeriría normalmente una reescritura completa de los componentes afectados. La tarea implicaba gestionar problemas de temporización complejos, como qué sucede cuando una ventana se cierra mientras todavía está entrando datos, y cómo reatachar a un usuario a una transmisión en vivo que ha estado funcionando sin él. Para resolver esto, el autor empleó un protocolo de cinco fases diseñado para mantener a la inteligencia artificial en un camino estricto. El proceso comenzó con el agente analizando la solicitud y produciendo una especificación formal, un documento detallado que describía exactamente cómo debería funcionar el cambio.

La parte más crítica del proceso fue la fase de refinamiento. Se le pidió al agente que tomara su propia especificación y la cotejara contra el código fuente real, buscando cualquier contradicción o detalle faltante. Esta no fue una verificación de un solo paso. El agente realizó catorce ciclos de esta auditoría. En cada ciclo, encontraba errores en su propio plan —tal vez un archivo que había olvidado actualizar, o una dependencia que había malinterpretado— y reescribía la especificación para corregirlos. A lo largo de estos catorce ciclos, el plan fue corregido aproximadamente ochenta y cinco veces, expandiendo el alcance del cambio de 110 archivos a 160 archivos a medida que se descubrían conexiones ocultas. Al final del decimocuarto ciclo, la especificación fue congelada. Era un plano fijo que había sido auditado contra la realidad de la base de código hasta que el último ciclo no devolvió hallazgos, momento en el cual se bloqueó como la referencia para todas las fases posteriores.

Con el plan bloqueado en su lugar, el agente pasó a la fase de implementación. Se le instruyó para generar los cambios de código necesarios para coincidir con la especificación congelada. El agente se negó a realizar cambios parciales, identificando correctamente que una migración a medio terminar rompería el sistema. En su lugar, ejecutó el trabajo en tres pasos distintos y confirmados. Una vez escrito el código, comenzó la fase de verificación. Así como el plan había sido revisado contra el código, el nuevo código era ahora revisado contra el plan congelado. El agente realizó diecisiete ciclos de esta auditoría, comparando el código real en pantalla con las reglas escritas en la especificación. En cada ciclo, encontraba y corregía desviaciones, solucionando fallos arquitectónicos sutiles que un humano podría haber pasado por alto. A través de estas diecisiete rondas, el agente corrigió 116 defectos en el propio código. El proceso se detuvo solo cuando dos auditorías consecutivas devolvieron cero errores, confirmando que el código coincidía con el plan dentro del criterio de convergencia definido.

Toda la operación afectó a 189 archivos, con un total de 288 archivos modificados al incluir la extracción del código antiguo. Los cambios involucraron más de 34,000 líneas de código nuevas y la eliminación de más de 16,000 líneas. Sorprendentemente, esta masiva reestructuración se completó en tres días. El costo del procesamiento de inteligencia artificial requerido para la tarea fue de 2,430 dólares estadounidenses. Durante todo el periodo de tres días, el programa no fue ejecutado ni una sola vez por un humano. La primera vez que el software se ejecutó realmente fue después del decimoséptimo ciclo de verificación, cuando el autor finalmente probó el nuevo comportamiento.

El resultado fue un éxito. Cuando se lanzó el programa, el nuevo comportamiento funcionó exactamente como describía la especificación. Un usuario podía iniciar una conversación, cerrar la ventana, y la conversación continuaría ejecutándose en segundo plano. Cuando el usuario reabría la ventana, la conversación se reanudaba instantáneamente, sin pérdida de datos ni duplicación de texto. Un nuevo botón de parada apareció en la barra lateral, permitiendo al usuario matar el proceso en segundo plano si fuera necesario. Las pruebas automatizadas existentes, que habían estado corriendo en el software durante años, no mostraron fallos, indicando que el nuevo sistema no rompió ninguna de las funcionalidades antiguas. El software se lanzó al público como la versión 2.3.0, y en las aproximadamente treinta sesiones de uso que siguieron al lanzamiento, no se observaron errores.

Este estudio de caso no afirma que la inteligencia artificial pueda ahora reemplazar a los ingenieros humanos en todos los escenarios, ni sugiere que este método funcione para todo tipo de problemas. El autor es cuidadoso al señalar que este fue un caso específico y particular en una base de código única, y que los resultados no pueden asumirse automáticamente como aplicables a otros sistemas o tareas. El estudio descarta explícitamente la idea de que un conjunto preexistente de pruebas pudiera haber resuelto este problema, debido a que el comportamiento deseado no existía antes del cambio. No había una respuesta "correcta" contra la cual contrastar en el código antiguo; la corrección tenía que definirse desde cero. El estudio también reconoce que el proceso dependió de un modelo de inteligencia artificial específico y potente, y que los resultados podrían diferir con modelos más débiles.

La importancia del trabajo radica en su demostración de una nueva forma de gestionar la complejidad. Al desplazar la carga del control de calidad de la inspección del producto final hacia la definición y verificación rigurosa del plan, los investigadores demostraron que una máquina podía navegar por un campo de minas de código interdependiente sin intervención humana. La clave no fue que la máquina fuera infalible, sino que el proceso le permitió detectar sus propios errores repetidamente antes de que se volvieran permanentes. La especificación fue desafiada catorce veces, y el código fue revisado diecisiete veces, creando un bucle de autocorrección que impulsó el sistema hacia una coincidencia entre la intención y la realidad basada en una regla de parada empírica. Los registros de todo este proceso, que abarcan más de 1,500 páginas, se han publicado para que cualquiera pueda inspeccionarlos, ofreciendo una mirada transparente a cómo una máquina puede desmantelar una regla arquitectónica central y reconstruirla, ladrillo a ladrillo, sin necesidad de que un humano vigile sobre su hombro.