Lo que aprendí construyendo una aplicación Angular sin escribir una sola línea de código

Cuando empecé a usar agentes de IA para programar, la idea que tenía en la cabeza era la que se ve en todos los vídeos: la software factory. Uno describe los requisitos de la aplicación, los agentes se reparten el trabajo, y al cabo de unas horas aparece el producto terminado. El programador pasa a ser un cliente de su propia fábrica. Describes, esperas, recoges.

Me parecía plausible. Los modelos ya escriben código mejor que la mayoría de nosotros en tareas acotadas. Si pueden escribir una función, pueden escribir un componente. Si pueden escribir un componente, pueden escribir una pantalla. Y si pueden escribir una pantalla, ¿por qué no una aplicación entera? La escala parecía la única diferencia.

Así que me puse a montar la fábrica. No a hacer la aplicación: a hacer la fábrica que haría la aplicación, tal como la había visto montar a otros.

Empecé por donde empiezan los vídeos: agentes especializados. Un arquitecto, un programador de Angular, un experto en Material, un revisor. Cada uno con su prompt, sus referencias y su papel. La idea era que yo hablara con el arquitecto, el arquitecto repartiera y los demás ejecutaran. Le dediqué mucho esfuerzo, bastante más del que me habría costado programar las primeras pantallas a mano.

El resultado fueron cosas que no terminaban de funcionar. No fallaban del todo, que habría sido más fácil de aceptar. Producían código que compilaba, que hacía más o menos lo pedido, y que yo no habría escrito jamás. Componentes con una granularidad que no era la mía, servicios que mezclaban responsabilidades, nombres que iban y venían entre el inglés y el castellano según el agente que hubiera tocado el fichero. Y lo peor: cuando corregía algo, la corrección no se propagaba. La siguiente pantalla volvía a tener el mismo problema.

Pensé que el fallo estaba en la especificación. Si los agentes hacían cosas raras era porque no les había dicho bien qué quería. Así que pasé al desarrollo dirigido por especificaciones, lo que llaman SDD. Documentos de requisitos, documentos de arquitectura, decisiones registradas una a una. Antes de tocar código, todo por escrito. Mejoró, es verdad. Pero mejoró en la dirección equivocada: cada vez dedicaba más tiempo a escribir documentos para que los agentes hicieran algo que yo seguía teniendo que revisar entero, y cada vez tenía menos sensación de que la aplicación avanzaba.

El siguiente paso lógico era mejorar los agentes. Más contexto, mejores referencias, más reglas. Y aquí es donde algo no me convenció. Cada regla que añadía era una decisión mía que estaba intentando colar por detrás, a través de un prompt, para que el agente la aplicara sin que yo interviniera. Estaba programando a los programadores en lugar de programar. Y el bucle de ver qué hacía mal, deducir qué regla faltaba, escribirla y probar otra vez era lento y poco fiable, porque los agentes seguían teniendo margen para interpretarla a su manera.

Al final hice lo que probablemente debería haber hecho desde el principio. Dejé de intentar que la IA se organizara sola y me puse a pedirle las cosas en modo plan: le digo lo que quiero, me propone cómo hacerlo, lo ajusto y lo ejecuta. Es decir, me puse a programar como he programado siempre, pensando qué pieza va ahora y cómo tiene que ser. La única diferencia es que el que teclea es la IA.

Y en ese punto, paradójicamente, es cuando empezó a ocurrir lo interesante.

Lo primero que noté al trabajar así es que ya no estaba usando agentes. Estaba usando un teclado muy listo. La IA hacía exactamente lo que yo le pedía, y lo hacía bien, pero yo 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 esto para que el componente de tabla reciba las columnas como configuración. Paso a paso, con la precisión de quien tiene el diseño en la cabeza y solo necesita que alguien lo escriba.

No piqué ni una línea. Eso es literal. Pero tampoco delegué nada. La diferencia entre lo que hacía y lo que me habían vendido era enorme, y me producía una sensación incómoda: me estaba ahorrando mucho tiempo, pero iba lento. Las dos cosas a la vez.

La tentación en ese momento era pensar que había dado un paso atrás. Que me había rendido con la fábrica y había vuelto a lo de siempre con una herramienta mejor. Pero ya sabía lo que pasaba al soltar la correa: código coherente, razonable y genérico. Funcionaba. Y no se parecía en nada a lo que yo quería.

Ahí empecé a entender dónde estaba el problema, y no era de capacidad. Era de información.

La arquitectura que yo quería no estaba escrita en ningún sitio. No estaba en los requisitos de la aplicación, que hablan de qué tiene que hacer y no de cómo. No estaba en la documentación de Angular, que describe el framework y no mis convenciones. No estaba en el código del backend, aunque algo se podía inferir de él. Estaba en mi cabeza, formada por años de proyectos anteriores, de cosas que me habían dolido y de cosas que me habían funcionado.

Que cada controller del backend tenga su carpeta en el cliente con un servicio y una interfaz por vista. Que los componentes compartidos tengan exactamente esa granularidad y no otra. Que los nombres vayan en castellano. Que el framework CSS sea propio en lugar de usar uno de los habituales. Ninguna de esas decisiones se deduce de los requisitos. Son decisiones de gusto con consecuencias, y la única fuente del gusto era yo.

Pedirle a la IA que acertara la arquitectura de detalle era como pedirle a un arquitecto junior excelente que adivinara cómo quiero mi casa sin haber hablado conmigo. Puede proponer una casa estupenda. No puede proponer la mía.

Seguí trabajando paso a paso, resignado a que así era como funcionaba esto. Y entonces apareció un fenómeno que no había previsto: cada vez iba más rápido.

No porque la IA aprendiera, sino porque había más piezas hechas. Cuando ya existía el componente de tabla, el de ficha, el de mensajes, el de tarjeta resumen y el layout de página, una pantalla nueva dejó de ser un proyecto para convertirse en una combinación. La carpeta del API, la carpeta de la feature con sus cuatro ficheros, la ruta, la entrada en el menú lateral. Todo predecible. Todo igual que la anterior.

Empecé a pedir pantallas enteras. Y la IA las hacía bien a la primera, sin que yo interviniera, porque ya no tenía que decidir nada. Solo tenía que instanciar un patrón que existía. Y para asegurarme de que el patrón se respetaba, fui escribiendo lo que había decidido en ficheros que la IA lee antes de trabajar: un documento con el contexto del proyecto, decisiones de arquitectura, y skills con el procedimiento exacto para crear una pantalla nueva o refactorizar el diseño gráfico.

Cada vez que tenía que intervenir en una pantalla, anotaba qué había tenido que decir y lo añadía a la skill. Unas pantallas después, dejé de intervenir.

Fue en ese punto cuando el pensamiento se me dio la vuelta. Durante semanas había sentido que estaba lejos de la software factory porque tenía que guiar la arquitectura a mano. Y de repente vi que no estaba lejos. Estaba dentro. Lo que había estado haciendo todo ese tiempo no era construir la aplicación. Era construir la fábrica.

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

Las demos de agentes autónomos que había visto funcionaban por una razón que entonces no supe ver: la arquitectura ya venía decidida. Proyectos nuevos, stack estándar, convenciones del framework por defecto, cero legado. Ahí la IA no decide nada, solo instancia los patrones de Angular tal como vienen. La fábrica la había construido otro, el que diseñó el framework. En mi caso, con un backend propio, un CSS propio y una forma concreta de hacer las cosas, la fábrica la tenía que construir yo.

La pregunta natural es si ese trabajo también se puede automatizar. Si la IA puede, a partir de los requisitos, crear no solo la aplicación sino la arquitectura de detalle que la sostiene.

Mi respuesta, después de vivirlo, es que puede proponerla pero no puede acertarla. Y la distancia entre proponer y acertar es exactamente el trabajo que hice yo. Hay tres razones.

La primera es que la arquitectura de detalle es la parte sin plantilla. Una pantalla nueva es una instancia de un patrón que ya existe. La arquitectura es decidir qué patrón existe. La IA es muy buena instanciando y bastante mediocre decidiendo, porque decidir bien requiere conocer un contexto que no está en ningún dataset.

La segunda es que las decisiones malas de arquitectura se pagan multiplicadas. Si una pantalla sale regular, se arregla. Si el componente de tabla sale regular, se paga en cada pantalla que lo use. Que fuera despacio en esa fase es la razón de que ahora vaya rápido en las pantallas. No es un fallo del método. Es el método.

La tercera es que las buenas abstracciones salen de casos reales, no de descripciones. El componente de tabla tiene la forma que tiene porque lo usé en tres pantallas y vi qué necesitaba. Eso no se deduce de los requisitos. Se descubre construyendo.

Alguien me sugirió que en vez de dictar la arquitectura paso a paso podría pedir a la IA que la propusiera y limitarme a criticarla. Lo pensé y no lo compro. Criticar es más rápido que dictar solo cuando no sabes qué quieres y necesitas ver opciones. Yo, en cada paso, sabía lo que quería. En ese caso, dictar es más rápido. El coste real no estaba en pensar ni en revisar. Estaba en transmitir, en contarle a la IA un diseño que yo ya tenía.

Si el coste es la transmisión, entonces lo que se puede optimizar es el canal. Yo transmití en el más caro: conversación, turno a turno, mientras la IA construía. Pero hay un canal más barato, y ya lo estoy usando sin haberlo planeado.

Es transmitir una sola vez y reutilizar. Cada decisión que tomé quedó escrita en el documento de contexto del proyecto y en las skills. Para 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 puede sacar 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.

Si tuviera que resumir todo esto en una frase, sería la siguiente:

La software factory la pueden usar los agentes, pero la factoría la crea uno mismo.

Lo que nos venden es la primera mitad. Agentes que producen software a toda velocidad. Es cierto, y lo he visto funcionar en mis propias pantallas. Lo que se omite es la segunda mitad: esa velocidad solo existe cuando alguien ha construido antes la fábrica que la hace posible. Los componentes de alto nivel, las convenciones, las skills, el criterio escrito. Y 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. Lo que la IA automatiza es 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.

Cuando alguien afirme que su herramienta saca de los requisitos una arquitectura de detalle como la mía, en realidad está vendiendo una de dos cosas: o una arquitectura genérica que no es la mía, o una herramienta en la que otra persona ya escribió su criterio y yo lo heredo. Ninguna de las dos es lo que quería. Lo que 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.

Podría cerrar diciendo que, si volviera a empezar, escribiría toda la arquitectura en un documento el primer día y me ahorraría las semanas de dictado. Pero no sería verdad. No tenía toda la arquitectura en la cabeza desde el primer momento. Tenía criterio, y el criterio no es lo mismo que el diseño.

El componente de tabla no nació con la forma que tiene ahora. Nació como una tabla para una pantalla concreta. Cuando apareció la segunda pantalla con tabla, vi qué era común y qué no. Cuando apareció la tercera, vi que la configuración de columnas tenía que ser un objeto y no una lista de atributos sueltos. Cada pantalla construida me enseñaba algo sobre la pieza que la sostenía, y refactorizaba la pieza. Sin escribir código, pero decidiendo cada cambio.

Eso es, creo, lo que siempre hemos llamado metodología ágil, aunque aquí no haya sprints ni tableros. Construir algo pequeño que funcione, mirarlo, ver dónde se puede mejorar y mejorarlo. La arquitectura no se diseña entera por adelantado; emerge de los casos de uso ya construidos. La diferencia respecto a antes es que el ciclo de construir, mirar y refactorizar ahora 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. La diferencia es que ahora sé que 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.

Lorenzo González

Artículo redactado con IA a partir de mis propias experiencias.