Diferencias

Muestra las diferencias entre dos versiones de la página.

--- cursos:sdd:opinion [2026/11/09 01:12] – Nueva página: mi opinión sincera sobre cómo programar con IA (a partir del artículo «La factoría la crea uno mismo») claude
+++ cursos:sdd:opinion [2026/11/09 11:39] (actual) – [La arquitectura también se descubre] Lorenzo
@@ Línea 1: / Línea 1: @@
-====== Mi opinión sincera sobre cómo programar con IA ======
+====== La factoría la crea uno mismo ======
-Lo que aprendí construyendo una aplicación Angular sin escribir una sola línea de código. Resumido en una frase:
+//Lo que aprendí construyendo una aplicación Angular sin escribir una sola línea de código//
-<note important>
+===== La promesa =====
-**La //software factory// la pueden usar los agentes, pero la factoría la crea uno mismo.**
-</note>
-===== 1. La promesa =====
+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.
-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 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.
-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.
+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.
-===== 2. Lo que intenté y no funcionó =====
+===== El intento =====
-  * **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.
+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.
-  * **[[cursos:sdd:19-spec-driven-development|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 [[cursos:sdd:03-opencode#el_modo_plan|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.**
+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.
-===== 3. Un teclado muy listo =====
+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.
-Ya no estaba usando agentes: estaba usando un teclado muy listo. Le pedía las cosas una a una:
+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.
-  * Crea este servicio.
+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.
-  * 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.
+Y en ese punto, paradójicamente, es cuando empezó a ocurrir lo interesante.
-===== 4. Lo que la IA no puede saber =====
+===== El primer choque =====
-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:
+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.
-  * Cada //controller// del backend tiene su carpeta en el cliente, con un servicio y una interfaz por vista.
+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.
-  * 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.
+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.
-===== 5. Cada vez más rápido =====
+===== Lo que la IA no podía saber =====
-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.
+Ahí empecé a entender dónde estaba el problema, y no era de capacidad. Era de información.
-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:
+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.
-  * Un documento con el contexto del proyecto: el [[cursos:sdd:07-agents-md|AGENTS.md]].
+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.
-  * Las decisiones de arquitectura: los [[cursos:sdd:07-agents-md#adrmdel_porque|ADR]].
-  * [[cursos:sdd:08-skills-agentes|Skills]] con el procedimiento exacto para crear una pantalla nueva o refactorizar el diseño gráfico.
+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.
+===== La curva que no esperaba =====
+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.
-<note tip>
 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.
-</note>
-===== 6. La fábrica la estaba construyendo yo =====
+===== El cambio de perspectiva =====
+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.
+===== ¿Se puede delegar la construcción de la fábrica? =====
+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.
-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 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 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 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.
-<note important>
+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.
-Las demos de agentes autónomos funcionan porque **la arquitectura ya viene decidida**: proyecto nuevo, //stack// estándar, convenciones del framework por defecto y cero legado. La IA no decide nada, solo instancia los patrones de Angular tal como vienen: la fábrica la construyó quien diseñó el framework. Con un backend propio, un CSS propio y una forma concreta de hacer las cosas, la fábrica te la tienes que construir tú.
-</note>
-===== 7. ¿Se puede delegar la construcción de la fábrica? =====
+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.
-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:
+===== Reducir el coste de contar =====
-  * **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//.
+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.
-  * **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.
+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.
-===== 8. Contarlo una sola vez =====
+Eso no elimina el trabajo de arquitecto. Elimina la fricción de contarlo dos veces.
-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.
+===== La idea central =====
-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:
-===== 9. La idea central =====
+> **La software factory la pueden usar los agentes, pero la factoría la crea uno mismo.**
-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.
+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. 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.
+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.
-<note warning>
+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.
-Quien diga que su herramienta saca de los requisitos una arquitectura de detalle como la tuya vende una de dos cosas: **una arquitectura genérica que no es la tuya**, o **una herramienta en la que otro ya escribió su criterio** y tú lo heredas.
-</note>
-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.
+===== La arquitectura también se descubre =====
-===== 10. La arquitectura también se descubre =====
+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 el tiempo 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.
-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.**
+Cierto componente no nació con la forma que tiene ahora. Nació como un HTML para una pantalla concreta. Cuando apareció la segunda pantalla con ese mismo HTML, vi qué era común y qué no. Cuando apareció la tercera, vi la abstracción que necesitaba y no un conjunto de etiquetas sin conexión. 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.
-La tabla no nació con la forma que tiene:
+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.
-  - Nació como la tabla de una pantalla concreta.
+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.
-  - Con la segunda pantalla con tabla, vi qué era común y qué no.
-  - 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.
+//Lorenzo González//
-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.
+//Artículo redactado con IA a partir de mis propias experiencias.//