Software factory en tiempos de IA: qué es y qué hace falta para montarla

Stripe fusiona más de 1.300 pull requests a la semana sin una sola línea escrita por un humano.

El dato circula desde febrero de 2026 y casi siempre se cuenta mal. La lectura fácil es “los agentes ya programan solos”. La lectura que importa es otra: aquello funciona porque Stripe llevaba años construyendo entornos de desarrollo desechables, CI selectivo y linters rápidos antes de que existiera ningún agente.

La fábrica no la monta el modelo. La monta el suelo que pisaba tu equipo el año pasado.

Y ahí está el problema, porque “software factory” es el término de moda de 2026 y se está usando para vender tres cosas distintas a la vez: una plataforma comercial, una transformación de consultora y una forma de organizar el trabajo. Vamos a separarlas.

En este post vas a encontrar:

• De dónde sale el término y por qué fracasó dos veces antes
• Qué dicen los datos de 2026 sobre productividad real, no la de los keynotes
• La arquitectura concreta de las fábricas que ya están en producción
• Por qué tu repositorio predice el resultado mejor que tu modelo
• Un plan de arranque para equipos que no se llaman Stripe

¿Qué es una software factory y por qué ha vuelto el término? ¶

Una software factory es un sistema que convierte señales de entrada (un bug, una petición de negocio, un ticket) en software desplegado y verificado, con un proceso repetible y medible. En su versión de 2026, los agentes de IA hacen el trabajo dentro del sistema y las personas definen la intención y revisan el resultado.

La idea no es nueva. Es de 1968.

En la conferencia de la OTAN sobre ingeniería del software, Douglas McIlroy propuso un mercado de componentes de software producidos en masa, pedidos por catálogo y ensamblados como si fueran placas de circuito. Era taylorismo puro aplicado a la programación: descomponer el trabajo, estandarizar las piezas, separar a quien planifica de quien ejecuta.

Fracasó. Dos veces.

Primero en las fábricas literales de los años 70 y 80: Hitachi, Toshiba, NEC y Fujitsu montaron procesos industriales con bibliotecas de reutilización y controles de calidad. Los componentes arrastraban supuestos ocultos y hacerlos reutilizables costaba más que reescribirlos. Después, esa herencia taylorista se coló en las metodologías por fases y las especificaciones cerradas contra las que se rebelaron los diecisiete firmantes del Manifiesto Ágil en 2001.

El diagnóstico fue el mismo las dos veces: no puedes industrializar un oficio quitándole el juicio que lo hace funcionar.

🔑 Lo que cambia ahora no es la ambición, es la mecánica. Un agente no busca un componente en una estantería: lo sintetiza a medida contra el contexto del repositorio que tiene delante. El catálogo finito y mantenido a mano desaparece.

Kotcherguine y Riedl lo argumentan con detalle en “The Factory Returns”, publicado en julio de 2026: la IA agéntica elimina el obstáculo concreto que mató a la fábrica durante medio siglo, pero hereda el pecado original en una forma nueva.

Si quieres el mapa de qué es un agente por dentro antes de seguir, lo desmenucé en arquitectura de agentes de IA.

¿Qué tiene que hacer una fábrica que un agente no hace solo? ¶

Generar código es la parte fácil. Ese es el titular incómodo de 2026.

Tereza Tizkova lo planteó así en su charla del AI Engineer World’s Fair de junio: una software factory es mucho más que un agente de código, o incluso que un enjambre de miles de agentes, porque los ingenieros pasan la mayor parte del tiempo en todo lo que rodea al código. Y ese “todo lo que rodea” es justo lo que la fábrica tiene que absorber: la especificación, el build, la validación, el despliegue y el aprendizaje que vuelve después.

Su definición operativa gira sobre tres propiedades:

1. Agnóstica: el mismo agente debería poder ejecutarse en la nube, en local, en CI y en tu editor. Sin esa portabilidad estás comprando dependencia de un proveedor disfrazada de plataforma.
2. Autónoma: capaz de sostener misiones largas sin que alguien la empuje en cada paso.
3. Que mejora con el uso: el contexto se acumula en el repositorio, no en la cabeza de quien escribió el prompt.

La analogía que usa para explicar por qué muchas empresas no ven resultados es la electrificación. Cuando las fábricas recibieron electricidad, atornillaron un motor eléctrico al esquema heredado del vapor y las ganancias fueron casi nulas. El salto llegó cuando rediseñaron la planta entera alrededor de la electricidad.

Atornillar agentes a tu proceso actual te deja con el proceso de siempre y un motor nuevo.

💡 Si tu equipo mide el impacto de la IA solo en “horas ahorradas por developer”, estás midiendo el motor y no la planta. Ese número sube mientras el tiempo hasta un resultado correcto y mantenible se mueve en dirección contraria.

Tizkova trabaja en Factory, una empresa que vende exactamente este producto. Conviene tenerlo presente al leer sus cifras. Dicho eso, los datos que expone sobre repositorios son de los más útiles que hay publicados y los vemos en un momento.

Fíjate en algo de esas tres propiedades: ninguna habla del modelo. Hablan del contrato que le das, del bucle en el que lo metes y de la memoria que deja detrás. La parte del contrato ya la cubrimos aquí con herramienta concreta en la guía de Spec Driven Development con agentes de IA, que es el sitio por donde empezar si vienes de escribir prompts largos. Si además arrastras dudas sobre cómo encaja todo esto con lo que ya hacías, la comparación está en TDD vs BDD vs SDD.

Curso gratis · paso a paso

El contrato que le das al agente, con el ciclo completo delante

Proposal, spec, diseño, tareas y archivado sobre un proyecto pequeño y en modo asistido. Es la primera pieza de la fábrica montada a escala de un repositorio, y cabe en una tarde.

Entrar en el curso gratis →

Cómo funciona la fábrica de Stripe por dentro ¶

Este es el caso mejor documentado y el que más se parece a algo que puedas copiar.

Los “Minions” de Stripe son agentes de código no atendidos. Un ingeniero escribe un mensaje en Slack (a veces basta con una reacción de emoji sobre un reporte de bug), se marcha, y vuelve a un pull request terminado que ya ha pasado los tests. Trabajan sobre una base de cientos de millones de líneas, en Ruby con tipado Sorbet, que sostiene más de un billón de dólares anuales en volumen de pagos.

Lo interesante es dónde está la palanca. Según los propios ingenieros, el agente es casi una materia prima: un fork de una herramienta de código abierto. El valor está en la envoltura.

• Puertas deterministas intercaladas. La arquitectura alterna pasos creativos del agente con checkpoints fijos que no puede saltarse: pasa el linter, pasa el test, hace el commit. No son cosas que el modelo “recuerde” hacer.
• Reglas condicionadas por ubicación. Un agente que toca el directorio de pagos hereda las restricciones de pagos.
• Contexto quirúrgico. Stripe tiene cientos de herramientas internas; el orquestador selecciona alrededor de quince por tarea. Dar las cuatrocientas provoca parálisis por opciones.
• Aislamiento total. Cada Minion arranca su propia máquina virtual desechable en unos diez segundos, la misma que usan las personas, y sin acceso a producción.
• Autoridad de envío, nunca de fusión. El sistema abre el pull request. Un humano lo revisa y lo fusiona. Siempre.

Esa última línea es la que se cae de casi todas las presentaciones comerciales.

Las reglas condicionadas por ubicación son, en la práctica, ficheros de instrucciones que viajan pegados al código. Ese formato ya tiene nombre propio y lo desmenucé en la guía completa de Agent Skills: mismo concepto, escala más pequeña, y puedes tenerlo funcionando esta tarde. Y si la pregunta que te ronda es qué te queda a ti cuando la generación se delega, esa la respondí en qué habilidades necesita un programador para trabajar con IA.

La validación tampoco es un bloque monolítico: lint local en menos de cinco segundos, CI selectivo (tienen más de tres millones de tests y ejecutarlos todos sería inviable), y revisión humana al final. Cada capa filtra un tipo de fallo distinto.

Si quieres profundizar en cuánto de eso hace falta revisar a mano, ya lo discutí en ¿necesitas revisar todo el código que genera la IA?.

¿Qué dicen los datos incómodos? ¶

Aquí es donde el relato de “3 a 5 veces más productividad” necesita contexto.

BCG Platinion publicó en 2026 que las organizaciones que operan este modelo reportan ganancias de productividad de 3 a 5 veces. Es una estimación declarada por profesionales que venden el servicio, no un benchmark independiente de la categoría. Trátala como lo que es.

Del otro lado hay tres señales que conviene mirar de frente:

GitClear analizó 211 millones de líneas modificadas entre 2020 y 2024 en repositorios de Google, Microsoft, Meta y otros. La frecuencia de bloques duplicados se multiplicó por ocho. La refactorización cayó desde alrededor de un cuarto de los cambios a menos de una décima parte. Por primera vez en la serie histórica, las líneas copiadas y pegadas superaron a las movidas.

METR ejecutó en 2025 el primer ensayo controlado aleatorizado sobre asistencia de IA: dieciséis desarrolladores experimentados, 246 tareas reales en repositorios que conocían bien. Predijeron un 24% de aceleración. El resultado medido fue un 19% más lento. Y lo más revelador: después de vivirlo, seguían estimando que la IA les había acelerado un 20%.

DORA identificó lo que llama el impuesto de verificación: el esfuerzo extra de comprobar si el código generado es fiable, seguro y coherente con la arquitectura. Su modelo de retorno de inversión de 2026 incluye una tasa de fallo en cambios que sube del 5% al 6% tras adoptar IA, con un coste asociado que aparece en negativo en la calculadora de ejemplo.

Ahora la contrarréplica honesta, porque existe y es fuerte: METR revisó el experimento con herramientas agénticas de finales de 2025 y la estimación se movió desde un 19% de ralentización hacia un 18% de aceleración, con intervalos de confianza amplios. DORA pasó de vincular la IA con caídas de throughput a asociarla con throughput más alto, aunque las dudas sobre estabilidad siguen ahí.

⚠️ Fíjate en por qué se dieron la vuelta esos números. No fue porque los modelos dejaran de generar código duplicado y ciego al contexto cuando se usan a lo loco. Fue porque maduró la disciplina alrededor: ingeniería de contexto, arneses, flujos de revisión y práctica de especificación previa.

Esa es la frase que sostiene todo el artículo. El problema no se resolvió solo. Lo resuelve la disciplina, y la disciplina se aprende.

Esa es la razón por la que la especificación previa dejó de ser una manía de puristas y se convirtió en la práctica por defecto de los equipos que consiguen números buenos.

¿Por qué tu repositorio importa más que tu modelo? ¶

Esta es, para mí, la evidencia más accionable que se publicó en el primer semestre de 2026.

Al puntuar repositorios según su preparación para el trabajo autónomo, aparece un patrón consistente. Los repositorios de nivel 1 (sin configuración de linter, sin fichero de instrucciones para agentes, sin hooks de pre-commit) sufren una degradación de calidad severa después de adoptar IA. Los de nivel 2 o superior, con estructura mínima, ven cambios manejables.

Entre tres y cuatro veces de diferencia en cada métrica. Mismo modelo, distinto suelo.

La conclusión es dura y liberadora a la vez: los resultados de un agente son un problema de entorno, no de modelo. Los equipos culpan al modelo cuando el cuello de botella real son los hooks que faltan, las variables de entorno sin documentar y los pasos de build enterrados en un hilo de Slack.

Birgitta Böckeler, de Thoughtworks, le puso nombre a la solución en abril de 2026: harness engineering, una disciplina que tiene ya cuerpo propio y que desmenucé entera en qué es el AI harness y por qué importa más que el modelo. La ecuación que usa es Agente = Modelo + Arnés, y divide el arnés en dos ejes:

• Guías (feedforward): anticipan el comportamiento no deseado y dirigen al modelo antes de que actúe. Instrucciones, plantillas, restricciones.
• Sensores (feedback): observan el código después de que el agente actúe y marcan los errores. Tests, linters, análisis estático.

Y cada uno puede ser computacional (determinista, rápido, ejecutado por CPU) o inferencial (otro modelo juzgando). La gracia está en empujar todo lo que puedas hacia lo computacional. Un linter no negocia. Un revisor LLM sí.

Las Agent Skills que mencionaba antes son una forma barata de escribir esas guías. Los hooks y el análisis estático son los sensores. No hace falta más vocabulario para empezar.

Feedforward, en la práctica

Las guías del arnés, escritas en un fichero que el agente carga solo cuando toca

Verás cómo se escribe un SKILL.md que de verdad se activa en el momento justo, con progressive disclosure para no fundirte la ventana de contexto en instrucciones que nadie va a leer.

Abrir la guía →

Guía premium · Funciona en 25+ agentes, no solo en Claude Code

Las cuatro piezas que hay que montar ¶

Si quitas el marketing, todas las fábricas que funcionan comparten cuatro elementos. Aquí van, en el orden en que merece la pena atacarlos.

1. Un contrato de validación. Qué significa “terminado”, escrito antes de que se genere una sola línea. Sin esto, el agente escribe el código y los tests que confirman su propio código.
2. Puertas deterministas que el agente no pueda saltarse. Lint, tipos, tests, análisis estático. Ejecutadas por hooks o CI, no por buena voluntad del modelo.
3. Validación separada de la generación. Quien juzga no debe haber escrito lo que juzga. En las misiones de Factory, la validación llega a ocupar el 40% del proceso completo, y lo presentan como buena señal.
4. Autoridad limitada. Envío sí, fusión no. Sandbox sí, producción no.

El punto 3 tiene truco y merece pararse. Si has trabajado con agentes habrás visto el patrón: construye la funcionalidad, escribe tests, los ve pasar y reporta la tarea completa. Esos tests salieron del mismo contexto que moldeó el código. Google documentó una versión de este problema con AlphaCode: las soluciones generadas por IA que pasaban tests generados por IA fallaban con frecuencia contra tests humanos reservados.

La autovalidación no es validación.

# Ejemplo mínimo de puertas deterministas en CI para PRs de agentes
name: agent-gate
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Nivel 1: rápido y barato, corta el 80% del ruido
      - run: npm run lint -- --max-warnings=0
      - run: npm run typecheck
      # Nivel 2: solo los tests afectados por los ficheros tocados
      - run: npm run test:affected
      # Nivel 3: el agente no puede escribir en estas rutas
      - name: Protected paths
        run: ./scripts/check-protected-paths.sh

Ese fichero no es glamuroso. Es lo que separa un repositorio de nivel 1 de uno de nivel 2.

¿Dónde está el cuello de botella ahora? ¶

En ti. En la revisión.

Simon Willison lo dijo pronto y sigue vigente: el límite natural de todo esto es la velocidad a la que puedes revisar los resultados. Fue escéptico con lanzar varios agentes en paralelo justo por eso, y acabó adoptándolo solo para tareas que no añaden carga cognitiva sobre el trabajo principal.

Addy Osmani propone tomar prestados dos conceptos de la gestión de equipos:

• Límites de trabajo en curso: pon un tope a cuántos flujos de agente tienes activos a la vez. Si abres diez, te ahogas en revisiones.
• Criterios de abandono: define antes de empezar qué te haría dejar de perseguir una funcionalidad.

Hay un segundo cuello de botella del que se habla menos y que se ha empezado a llamar deuda de comprensión. Cuando la generación adelanta al entendimiento, las únicas personas capaces de revisar la salida con criterio (los perfiles senior) se convierten en el embudo, y lo que se les escapa llega a producción.

Aquí va mi propia observación, con un equipo pequeño y meses de esto encima: las estimaciones no pueden encogerse solo porque la IA escribe más rápido que un humano. Escribir rápido no es escribir mejor. Al separarte de la escritura del código tienes que recuperar el control por otra vía, y esa vía cuesta tiempo: contexto, restricciones, funcionalidades más pequeñas, tests en varios niveles y análisis estático que destape la deuda antes de que se instale.

El valor que entregas sigue siendo alto. Puede que más que antes. Pero no está en el mismo sitio.

Cómo empezar sin montar una fábrica entera ¶

No necesitas misiones de dieciséis horas ni un panel de control en el terminal. Necesitas subir un nivel tu repositorio. Este es el orden que tiene más sentido:

1. Audita tu repo como si fueras un agente nuevo. ¿Están documentadas las variables de entorno? ¿Se levanta el proyecto con un comando? ¿Hay un fichero de instrucciones en la raíz? Si la respuesta a alguna es no, ahí está tu primer trabajo.
2. Instala hooks de pre-commit antes de tocar nada más. Lint y formato. Es la puerta determinista más barata que existe.
3. Escribe el contrato antes que el prompt. Objetivo, restricciones, criterios de aceptación. Cinco líneas bastan para empezar.
4. Separa quien valida de quien genera. Sesión distinta, contexto fresco, y a poder ser modelo distinto. No le pidas al mismo agente que se corrija.
5. Pon un límite de trabajo en curso. Empieza en dos flujos simultáneos y sube solo cuando revisar deje de doler.
6. Mide throughput e inestabilidad juntos. Un panel donde solo sube el número de pull requests es un panel que miente.

# Chequeo rápido de "agent readiness" antes de soltar nada
# Si algo de esto falla, el agente lo va a sufrir igual que una persona nueva

test -f AGENTS.md && echo "OK instrucciones" || echo "FALTA fichero de instrucciones"
test -f .pre-commit-config.yaml && echo "OK hooks" || echo "FALTA pre-commit"
test -f .env.example && echo "OK variables" || echo "FALTA .env.example"
grep -q "test" package.json && echo "OK script de tests" || echo "FALTA script de tests"

Cuatro líneas de shell te dicen si tu repositorio está en el grupo del +29% o en el del +96%.

Los riesgos que no salen en el keynote ¶

Tres, y son reales.

El primero es el teatro de métricas. Todo indicador visible (volumen de commits, número de pull requests, líneas entregadas) puede subir mientras lo que importa (tiempo hasta un resultado correcto y mantenible) va en dirección contraria. El estudio de METR es exactamente eso medido en laboratorio.

El segundo es la brecha creciente. Los datos de entrega de 2026 apuntan a que los equipos del percentil 99 alcanzan velocidades impensables hace dos años mientras el equipo mediano apenas se ha movido. En adopción de IA se tiende a acertar mucho o a fallar mucho; el término medio tranquilo se está estrechando.

El tercero es regulatorio si trabajas en un dominio sensible. El Reglamento Europeo de IA aplica sus obligaciones de alto riesgo desde diciembre de 2027 para sistemas independientes y agosto de 2028 para los integrados en productos. Pide documentación técnica anterior a la puesta en mercado, registro automático de eventos por diseño y supervisión humana efectiva. Que es, casualidad ninguna, la misma lista de la que hemos hablado: especificación versionada, trazas de la tubería y revisión humana antes de fusionar.

🛡️ La gobernanza que mantiene a raya tu deuda técnica es la misma que te mantiene dentro de la ley. No son dos proyectos, es uno.

¿Nos sustituye la fábrica? ¶

La respuesta menos cómoda es que ya pasó algo parecido.

“Computer” fue un puesto de trabajo antes que una máquina. En los años cuarenta más de ochenta mujeres calculaban trayectorias balísticas a mano, entre treinta y cuarenta horas por trayectoria, organizadas en planta como una cadena de montaje. No desaparecieron del relato: subieron una capa de abstracción cuando llegaron los compiladores y los lenguajes de alto nivel. La estructura del trabajo no cambió tanto; cambió el nivel en el que se sentaban las personas.

Kent Beck describe a los agentes como genios: te conceden el deseo, pero no hacen lo que quieres decir, tienen su propia agenda. Böckeler los llama burro terco. Martin Fowler prefiere a Uriah Heep, el sirviente obsequioso de Dickens que socava a quien dice servir. Tres metáforas distintas apuntando al mismo sitio: potencia enorme, fiabilidad discutible, supervisión obligatoria.

El riesgo real no es que te sustituyan. Es negarte a subir de capa.

Y ojo, porque subir de capa no es un ascenso automático. Es aprender a escribir especificaciones que no dejen huecos, a diseñar puertas que no se puedan saltar, a decidir qué merece construirse. El trabajo mecánico se automatiza sin pérdida. El juicio, no.

La fábrica ha vuelto. Que industrialice tu software o que lo desarme no lo decide el modelo. Lo decides tú, cada vez que eliges entre poner un hook o confiar en que el agente se acuerde.

¿Por dónde vas a empezar, por el pre-commit o por el contrato de validación?

Preguntas frecuentes ¶

¿Qué es exactamente una software factory en 2026?

Es un sistema que transforma señales de entrada (bugs, peticiones, especificaciones) en software desplegado y verificado, con entradas estandarizadas, herramientas comunes, salida medible y capacidad de reconstruir cualquier cambio a partir de sus insumos. La variante agéntica pone agentes de IA como ejecutores dentro de la tubería y deja a las personas definiendo intención y revisando resultados.

¿Es lo mismo que un enjambre de agentes de código?

No. Un enjambre genera código, que es la parte fácil. Una fábrica cubre el ciclo completo: especificación, construcción, validación, despliegue y el aprendizaje que vuelve al sistema. La diferencia práctica está en las puertas de calidad y en la trazabilidad, no en el número de agentes.

¿De verdad Stripe fusiona 1.300 pull requests semanales sin código humano?

Sí, según sus propios ingenieros. El matiz importante es que ningún cambio se fusiona sin revisión humana: el sistema tiene autoridad de envío, no de fusión. Además funciona sobre infraestructura de experiencia de desarrollo que existía desde antes de los agentes.

¿La IA me hace más productivo o menos?

Depende del entorno. El ensayo controlado de METR en 2025 midió un 19% de ralentización en desarrolladores expertos sobre repositorios que conocían bien, aunque ellos percibían un 20% de aceleración. La revisión con herramientas agénticas posteriores movió la estimación hacia un 18% de mejora. La variable que explica el cambio es la disciplina, no el modelo.

¿Qué es el harness engineering?

Es el trabajo de construir todo lo que rodea al modelo dentro de un agente. Birgitta Böckeler lo estructura en guías (controles que dirigen al modelo antes de actuar) y sensores (controles que observan el resultado después), y distingue entre controles computacionales, deterministas, y controles inferenciales, ejecutados por otro modelo.

¿Qué es la agent readiness de un repositorio?

Es una medida de cuánto soporta tu código el trabajo autónomo: configuración de estilo y validación, sistema de build, testing, documentación, entorno de desarrollo, observabilidad, seguridad y descubrimiento de tareas. Los repositorios sin esa base sufren degradaciones de calidad tres o cuatro veces mayores tras adoptar IA.

¿Por qué no debe validar el mismo agente que genera el código?

Porque los tests salen del mismo contexto que moldeó la implementación, así que confirman los supuestos del agente en lugar de cuestionarlos. La práctica recomendada es separar generación y validación en sesiones o modelos distintos, y reservar al menos un validador que no vea el código fuente.

¿Cuántos agentes debería lanzar en paralelo?

Empieza por dos y sube solo cuando revisar deje de ser doloroso. El límite real no es cuántos agentes soporta tu máquina, sino cuántos resultados puedes revisar con criterio. Poner un tope explícito de trabajo en curso evita ahogarse en pull requests pendientes.

¿Esto sirve para un equipo de tres personas?

Sí, aunque no con misiones autónomas de dieciséis horas. Lo que escala hacia abajo son las piezas baratas: hooks de pre-commit, contrato de validación escrito antes del prompt, tests en varios niveles y análisis estático. Esa base explica la mayor parte de la diferencia de resultados.

¿Qué obligaciones legales hay sobre código generado por IA en Europa?

El Reglamento Europeo de IA aplica sus obligaciones de alto riesgo desde el 2 de diciembre de 2027 para sistemas independientes y el 2 de agosto de 2028 para los integrados en productos. Exige documentación técnica previa a la comercialización, registro automático de eventos integrado en el diseño y supervisión humana capaz de interpretar, anular y detener el sistema.

Fuentes ¶

• Tereza Tizkova, “Rise of the Software Factory”
• Alexandre Kotcherguine y Kevin Riedl, “The Factory Returns: AI and the Software Factory”
• Birgitta Böckeler, “Harness engineering for coding agent users”
• Simon Willison, “Embracing the parallel coding agent lifestyle”
• Addy Osmani, “Your AI coding agents need a manager”
• Matan Grinberg y Eno Reyes, “Factory 2.0: From coding agents to software factories”
• BCG Platinion, “The Agentic Software Factory”
• InfoQ, “Stripe Engineers Deploy Minions, Autonomous Agents Producing Thousands of Pull Requests Weekly”
• ByteByteGo, “How Stripe’s Minions Ship 1,300 PRs a Week”
• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”
• GitClear, “AI Copilot Code Quality 2025”
• InfoQ, “New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment”
• Douglas McIlroy, “Mass-produced software components” (NATO, 1968)
• Martin Fowler, “Exploring Generative AI”

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter