Lo que aprendí construyendo una aplicación Angular sin escribir una sola línea de código. Resumido en una frase:

La idea que se ve en todos los vídeos: describes los requisitos, los agentes se reparten el trabajo y a las pocas horas sale la aplicación terminada. El programador pasa a ser cliente de su propia fábrica: describes, esperas, recoges.

Me pareció plausible. Si un modelo escribe una función, escribe un componente; si escribe un componente, una pantalla; y si escribe una pantalla, ¿por qué no la aplicación entera? Así que me puse a montar la fábrica que haría la aplicación, tal como la había visto montar a otros.

• Agentes especializados: un arquitecto, un programador de Angular, un experto en Material y un revisor, cada uno con su prompt y su papel. Me costó más que programar a mano las primeras pantallas. El código compilaba y hacía más o menos lo pedido, pero yo no lo habría escrito jamás: componentes con una granularidad que no era la mía, servicios que mezclaban responsabilidades, nombres que saltaban del inglés al castellano según el agente. Y lo peor: una corrección no se propagaba; la siguiente pantalla volvía a tener el mismo fallo.
• Spec-Driven Development: requisitos, arquitectura y decisiones por escrito antes de tocar código. Mejoró, pero en la dirección equivocada: cada vez escribía más documentos para que los agentes hicieran algo que yo seguía teniendo que revisar entero.
• Más reglas a los agentes: cada regla era una decisión mía colada por detrás en un prompt. Estaba programando a los programadores en lugar de programar, en un bucle lento (ver el fallo, deducir la regla, escribirla, probar) y poco fiable, porque el agente seguía interpretándola a su manera.

Al final hice lo que debí hacer desde el principio: pedir las cosas en modo plan. Le digo lo que quiero, me propone cómo, lo ajusto y lo ejecuta. Es programar como siempre, pensando qué pieza va ahora y cómo tiene que ser. Solo que el que teclea es la IA.

Ya no estaba usando agentes: estaba usando un teclado muy listo. Le pedía las cosas una a una:

• Crea este servicio.
• Ahora una interfaz para cada vista que devuelve el API.
• Ahora un componente que pinte una ficha.
• Ahora refactoriza para que el componente de tabla reciba las columnas como configuración.

No piqué ni una línea, literal. Pero tampoco delegué nada. Me ahorraba mucho tiempo y a la vez iba lento. Y parecía un paso atrás, pero ya sabía lo que pasaba al soltar la correa: código coherente, razonable y genérico, que funcionaba y no se parecía en nada a lo que yo quería.

El problema no era de capacidad, era de información. La arquitectura que quería no estaba escrita en ningún sitio: ni en los requisitos (dicen qué, no cómo), ni en la documentación de Angular (describe el framework, no mis convenciones), ni del todo en el backend. Estaba en mi cabeza, hecha de años de proyectos, de lo que me había dolido y de lo que me había funcionado:

• Cada controller del backend tiene su carpeta en el cliente, con un servicio y una interfaz por vista.
• Los componentes compartidos tienen exactamente esa granularidad y no otra.
• Los nombres van en castellano.
• El framework CSS es propio, no uno de los habituales.

Ninguna se deduce de los requisitos: son decisiones de gusto con consecuencias, y la única fuente del gusto era yo. Es como pedirle a un arquitecto junior excelente que adivine cómo quiero mi casa sin hablar conmigo: puede proponer una casa estupenda, no la mía.

Seguí paso a paso y apareció algo que no esperaba: cada vez iba más rápido. No porque la IA aprendiera, sino porque había más piezas hechas. Con la tabla, la ficha, los mensajes, la tarjeta resumen y el layout de página ya hechos, una pantalla nueva dejó de ser un proyecto y pasó a ser una combinación: la carpeta del API, la de la feature con sus cuatro ficheros, la ruta y la entrada en el menú. Todo predecible, todo igual que la anterior.

Empecé a pedir pantallas enteras y salían bien a la primera, porque la IA ya no tenía que decidir nada: solo instanciar un patrón que existía. Para que lo respetara, fui escribiendo lo decidido en ficheros que lee antes de trabajar:

• Un documento con el contexto del proyecto: el AGENTS.md.
• Las decisiones de arquitectura: los ADR.
• Skills con el procedimiento exacto para crear una pantalla nueva o refactorizar el diseño gráfico.

Ahí se me dio la vuelta el pensamiento. Llevaba semanas sintiéndome lejos de la software factory por guiar la arquitectura a mano, y resulta que estaba dentro: no estaba construyendo la aplicación, estaba construyendo la fábrica.

La fábrica no es la IA. Es el conjunto de componentes de alto nivel, convenciones, documentos de contexto y skills que hacen que la IA saque pantallas enteras sin supervisión. Eso no viene de serie: lo construí yo, pieza a pieza, sin escribir código pero decidiendo cada cosa. Una vez hecha, los agentes la usan a la velocidad que prometían las presentaciones.

La IA puede proponer la arquitectura de detalle, pero no acertarla. Y la distancia entre proponer y acertar es justo el trabajo que hice yo. Por tres razones:

• Es la parte sin plantilla. Una pantalla es una instancia de un patrón; la arquitectura es decidir qué patrón existe. La IA instancia muy bien y decide bastante mal, porque decidir bien exige un contexto que no está en ningún dataset.
• Los errores de arquitectura se pagan multiplicados. Una pantalla regular se arregla; un componente de tabla regular se paga en cada pantalla que lo usa. Ir despacio en esa fase es lo que hace que luego vaya rápido. No es un fallo del método: es el método.
• Las buenas abstracciones salen de casos reales. La tabla tiene la forma que tiene porque la usé en tres pantallas y vi qué necesitaba. Eso no se deduce de los requisitos: se descubre construyendo.

¿Y pedirle a la IA que proponga la arquitectura y limitarme a criticarla? No lo compro. Criticar es más rápido que dictar solo cuando no sabes lo que quieres y necesitas ver opciones. Yo en cada paso lo sabía, y entonces dictar es más rápido. El coste no estaba en pensar ni en revisar: estaba en transmitir un diseño que ya tenía.

Si el coste es transmitir, lo que se optimiza es el canal. Yo usé el más caro: conversación, turno a turno, mientras la IA construía. El barato es transmitir una vez y reutilizar: cada decisión quedó escrita en el documento de contexto y en las skills. En el siguiente proyecto con el mismo stack, el coste de transmisión es casi cero porque la fábrica ya existe. Ahí sí, la IA saca la aplicación de los requisitos: no porque diseñe, sino porque instancia lo que yo diseñé la primera vez.

Eso no elimina el trabajo de arquitecto: elimina la fricción de contarlo dos veces.

Lo que nos venden es la primera mitad de la frase: agentes que producen software a toda velocidad. Es cierto, lo he visto en mis propias pantallas. Lo que se omite es la segunda: esa velocidad solo existe cuando alguien ha construido antes la fábrica (componentes de alto nivel, convenciones, skills, criterio escrito). Ese trabajo es humano, es lento la primera vez y no se puede saltar.

No es una limitación de los modelos actuales que vaya a desaparecer con el siguiente: es un problema de información. La fábrica codifica un criterio, y el criterio solo lo tiene quien lo ha formado. La IA automatiza la ejecución y la repetición; el criterio hay que transmitirlo una vez por cada idea nueva. La primera vez se paga; las siguientes son gratis.

Lo que yo quería es lo que tengo ahora: una fábrica que produce exactamente lo que yo habría programado, sin que yo programe. Y esa la tuve que construir yo.

No diré que, si volviera a empezar, escribiría toda la arquitectura en un documento el primer día. No sería verdad: no la tenía entera en la cabeza. Tenía criterio, y el criterio no es lo mismo que el diseño.

La tabla no nació con la forma que tiene:

1. Nació como la tabla de una pantalla concreta.
2. Con la segunda pantalla con tabla, vi qué era común y qué no.
3. Con la tercera, vi que la configuración de columnas tenía que ser un objeto y no una lista de atributos sueltos.

Cada pantalla me enseñaba algo sobre la pieza que la sostenía, y refactorizaba la pieza. Eso es lo que siempre hemos llamado ágil, aunque no haya sprints ni tableros: construir algo pequeño que funcione, mirarlo y mejorarlo. La arquitectura no se diseña entera por adelantado; emerge de los casos de uso ya construidos. Lo nuevo es que el ciclo de construir, mirar y refactorizar dura minutos en lugar de días, porque la ejecución es de la IA. Lo que sigue siendo mío es mirar y decidir.

Así que no haría nada distinto. Volvería a ir paso a paso, porque es el paso a paso lo que me enseña qué arquitectura necesito. Ese proceso no es un rodeo antes de llegar a la fábrica: es la fábrica construyéndose a sí misma, con un humano en el centro que decide y una IA alrededor que ejecuta. Los agentes, después, la usarán.