Cuando un agente escribe la implementación a partir de una especificación, la pregunta de qué estás versionando cambia de respuesta sin que nadie lo anuncie. Sigues abriendo pull requests y comentando líneas, pero el diff que revisas ya no es de lo que escribiste tú: es de lo que produjo el agente al leer lo que escribiste tú. La spec es lo que tocaste con las manos. El código es lo que salió de la máquina. Y esa distinción, que suena a matiz, es exactamente la misma que llevamos cuarenta años haciendo entre el código fuente y el binario.
La tesis es esa, sin rodeos: en el momento en que un agente genera el código, la spec se convierte en el código fuente y el código pasa a ser el binario. Lo que versionas, revisas y tratas como la verdad es la fuente; lo que se compila a partir de ella es un artefacto regenerable que casi nunca miras. El problema es que la industria todavía revisa el binario como si fuera la fuente, y eso tiene nombre: es abrir el desensamblador para aprobar un cambio que está escrito en una línea de C tres carpetas más arriba.
¿Por qué la metáfora del compilador y no otra?
Gregor Hohpe tiene una regla para saber si una metáfora sirve para pensar o solo para decorar, y la explica en The Mighty Metaphor: no basta con que la imagen se parezca, tienen que coincidir las dinámicas. Su método completo, el de traducir un problema a un dominio donde el lector ya sabe razonar, está en su sitio. Apliquemos su prueba, porque el compilador es una metáfora peligrosamente cómoda y conviene ver si aguanta.
En un compilador, la relación fuente-binario tiene reglas que no son opinables. Depuras y versionas la fuente, no el binario. Si editas el binario a mano para arreglar algo, no has arreglado nada: has creado una divergencia que el próximo build va a borrar, y encima ahora tu fuente miente, porque ya no reproduce lo que corre en producción. El binario es regenerable por definición; su valor es que sale de la fuente cuantas veces haga falta. Y una fuente que no puedes volver a compilar hasta obtener ese binario no es fuente: es un comentario largo.
Cambia «fuente» por «spec», «compilador» por «agente» y «binario» por «código generado», y las cuatro reglas se sostienen una por una. Depuras y versionas la spec. Parchear a mano el código que generó el agente es editar el binario: funciona hasta la próxima regeneración, y mientras tanto tu spec ya no describe lo que corre. El código generado es regenerable, ese es todo su punto. Y una spec a partir de la cual no puedes regenerar el código no es una spec, es documentación con aires de grandeza. Las dinámicas coinciden, no solo la imagen. Por eso el modelo aguanta.
Y como aguanta, puedes llevarlo más lejos de lo que voy a escribir aquí. Si el código generado es el binario, entonces revisar su diff línea por línea es hacer un diff de binarios, un ejercicio que en el mundo clásico reservábamos para la ingeniería inversa y para nada más. Si la spec es la fuente, una spec sin pruebas es fuente sin verificador de tipos: compila igual y falla igual de tarde. No he argumentado ninguna de las dos cosas y ya las estás viendo. Eso es lo que separa un modelo de un adorno.
Entonces, ¿la spec es diseño o es papeleo?
Aquí es donde conviene traer a alguien que ya ganó esta discusión hace veinticinco años, antes de que existiera un solo agente. Partiendo del argumento que Jack Reeves plantea en What Is Software Design?, el código fuente no es la construcción del software: es su diseño. Lo que de verdad fabrica el producto, sostiene Reeves, son el compilador y el enlazador, y la única documentación que satisface por completo un diseño de ingeniería son los propios listados de código. La manufactura, en software, es gratis y automática; el trabajo de ingeniería está entero en la fuente.
Ese argumento, que en su día servía para dignificar el código frente a los diagramas UML, encaja como un guante en la era del agente, solo que corrido un nivel. Si el compilador es quien manufactura, y ahora el agente ocupa el lugar del compilador, entonces la spec ocupa el lugar de la fuente: es el diseño, el sitio donde vive el trabajo de ingeniería. El código generado es la manufactura, y la manufactura volvió a ser gratis y automática, que es justo lo que la vuelve inventario en lugar de activo, como ya argumenté en El código es inventario, no un activo.
Lo que Reeves no podía prever, y donde hay que aportar algo propio en vez de traducirlo, es la consecuencia arquitectónica. Si la spec es el diseño, entonces el esfuerzo de revisión y la gobernanza tienen que mudarse a la spec, porque revisar el binario nunca fue el trabajo. Durante décadas revisamos el código fuente y no el binario, no por costumbre, sino porque la fuente era el único sitio donde una decisión de diseño era legible. El agente no cambia esa lógica: la hace literal. El sitio donde una decisión es legible ahora es la spec.
Arriba, la revisión se posa sobre la fuente, que es donde vive el diseño. Abajo, la costumbre no se ha mudado: sigue revisando el binario.
¿Cuánto cuesta seguir revisando el binario?
Pongamos una cuenta, con los supuestos a la vista para que la rehagas con los tuyos. No es la medición de un cliente real; es aritmética de servilleta, de la que hace este blog.
Supón un agente que genera 1.500 líneas de código por cada tarea que le encargas, a partir de una spec de 150 líneas. La proporción es de diez a uno, y no es exagerada: describir el qué casi siempre ocupa menos que desplegar el cómo. Ahora súbelo a la escala de un equipo: cinco tareas a la semana son 7.500 líneas de código generado contra 750 líneas de spec.
Si revisas el código, revisas 7.500 líneas semanales que nadie escribió pensando en que un humano las leyera, porque el agente optimiza para que compilen, no para que se lean. Si revisas la spec, revisas 750 líneas que sí se escribieron para leerse y que contienen las decisiones de verdad: una décima parte del volumen, en el sitio donde un error importa antes de materializarse. La cuenta no es solo «ahorro un 90% del tiempo de revisión»; es que las 750 líneas de spec deciden las 7.500 de código, y las 7.500 de código no deciden nada, solo obedecen. Revisar el efecto en lugar de la causa es trabajar diez veces más para llegar tarde.
Pero yo necesito revisar el código porque es lo que corre en producción, no la spec. El agente se equivoca, alucina, mete una dependencia rara. Si solo miro la spec, ese error se me escapa.
Es la objeción correcta, y aun así confunde dos cosas. Que el error viva en el binario no significa que se arregle en el binario. Cuando un compilador genera código malo, no parcheas el ensamblador: arreglas la fuente, o arreglas el compilador. Si el agente alucina a partir de una spec clara, el problema es el agente y va contra la capa que lo gobierna; si alucina porque la spec era ambigua, el problema es la spec y se arregla ahí. Revisar el código generado para cazar el error es útil exactamente igual que leer el desensamblado para depurar: se hace cuando sospechas del compilador, no como el sitio donde vive tu trabajo. Convertir la excepción en el método es lo que no aguanta.
Si tu forma de asegurar la calidad es leer línea por línea lo que el agente generó, no estás revisando código: estás haciendo ingeniería inversa de tu propia spec.
¿Dónde se compilan las garantías de la spec?
Una spec que solo vive en un documento es una fuente que nadie compila: expresa una intención y confía en que el agente la respete, que es tan práctico como pedirle a tus desarrolladores que escriban código libre de errores porque se lo pediste con amabilidad. Para que la spec sea fuente de verdad hace falta una capa que convierta sus límites en algo que el agente no pueda cruzar aunque quiera, igual que el sistema de tipos convierte una intención del programador en un error de compilación en vez de en una plegaria.
Esa capa existe y tiene dos caras. El flujo dirigido por especificaciones de Kiro trata la spec como el artefacto primero: la escribes, la versionas, y el código sale de ella, no al revés. Y una plataforma como Amazon Bedrock AgentCore es donde las fronteras de esa spec se compilan en garantías operativas: identidad, permisos y guardrails que definen qué puede tocar el agente antes de que actúe. Entre las dos, la spec deja de ser una carta de deseos y pasa a ser fuente ejecutable: lo que dice se hace cumplir, no se espera que ocurra. Ahí es donde el arquitecto pone su esfuerzo, porque ahí es donde una decisión tiene efecto. Es el mismo desplazamiento del control hacia el límite que ya conté en La autonomía es una firma en blanco: no vigilas cada acción, defines la frontera antes.
Mi sugerencia
El lunes, lleva una sola pregunta a tu próxima revisión de arquitectura: ¿qué estamos versionando como fuente de verdad, la spec o el código que el agente generó a partir de ella? Si la respuesta es «el código», tienes un proyecto que trata el binario como fuente, y eso se nota en que nadie sabría regenerarlo desde cero porque la spec, si existe, ya no reproduce lo que corre. Si la respuesta es «la spec», entonces la siguiente pregunta es dónde se compilan sus garantías, y quién revisa esas 750 líneas con el cuidado con el que antes revisaba las 7.500.
Y si quieres una prueba concreta, hazla esta semana: agarra una tarea que el agente ya resolvió, borra el código generado y regénéralo solo desde la spec. Si sale equivalente, tu spec es fuente y puedes confiar en ella. Si no sale, acabas de descubrir que lo que tenías por fuente era un comentario, y que la verdad estaba en el binario que ibas a borrar. Concedo que da un poco de vértigo borrar código que funciona para ver si vuelve. Pero si de verdad crees que tu spec es la fuente, regenerar el binario debería ser pan comido. ;)