La fábrica regresa

Cómo la IA revive el sueño de la fábrica de software y si la agilidad podrá sobrevivirlo

Publicado por Polity | Julio de 2026
Autores: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

Este artículo trata sobre metodología de desarrollo de software y diseño organizativo. Se apoya en investigación original, documentos oficiales e información empresarial de primera mano revisada hasta el 2 de septiembre de 2026. Los estudios de proveedores y los benchmarks se identifican como tales. Nada de lo que contiene constituye asesoramiento profesional, jurídico o de inversión.

Resumen ejecutivo

En 1968, Douglas McIlroy propuso en la NATO Conference on Software Engineering una industria de componentes de software producidos en masa y pedidos por catálogo. Fue una influyente analogía industrial para una cadena de suministro de software repetible. En los años setenta y ochenta surgieron programas concretos de fábrica de software; el Manifiesto Ágil de 2001 se presentó después como alternativa al desarrollo pesado y guiado por documentación. Este artículo sostiene que la IA agéntica revive la visión de McIlroy de otra forma: código adaptado generado bajo demanda. La evidencia es mixta. El estudio de proveedor de GitClear de 2026 señala peores indicadores de mantenibilidad; el ensayo aleatorizado de METR de comienzos de 2025 mostró a expertos más lentos con IA pese a sentirse más rápidos; y el experimento posterior de METR no pudo ofrecer una estimación actual fiable por problemas de selección y medición. La disciplina de ingeniería sube en el stack, hacia la especificación y la validación. El relato de Stripe aporta un caso de producción: cada semana se fusionan más de mil pull requests escritos por completo por Minions, pero revisados por personas y ejecutados sobre una amplia infraestructura de herramientas y pruebas. La variable decisiva es la gobernanza, no solo el modelo.

El sueño que fracasó dos veces

Los organizadores llamaron al encuentro de 1968 NATO Software Engineering Conference, y el informe registra tanto la ambición de establecer la ingeniería de software como el desacuerdo sobre su significado (1). McIlroy propuso allí familias y catálogos de componentes estándar, comparándolos expresamente con tornillos, resistencias y subconjuntos industriales (2). La analogía recuerda la descomposición y estandarización de Taylor, aunque llamar «explícitamente taylorista» a la propuesta excedería el texto. La investigación de campo de Michael Cusumano documenta Software Works de Hitachi desde 1969 e iniciativas fabriles de NEC, Toshiba y Fujitsu desde mediados de los setenta (3).

Esos programas no establecieron una economía universal de catálogos de software. Cusumano describe combinaciones propias de herramientas, activos reutilizables, métodos estandarizados, formación y control de calidad, con resultados distintos (3). Los diecisiete firmantes del Manifiesto Ágil se reunieron en 2001 buscando una alternativa al desarrollo pesado y guiado por documentación (4). El registro histórico sostiene una analogía más estrecha que un simple doble fracaso: los enfoques industriales lograron mejoras locales, pero no eliminaron la necesidad de contexto, adaptación y criterio.

Por qué esta vez es diferente

La IA agéntica cambia la mecánica de un modo que la fábrica de software nunca pudo. Los componentes de McIlroy tenían que ser escritos, catalogados, generalizados y mantenidos por personas antes de que nadie pudiera pedirlos; la sobrecarga de la generalización fue lo que mató la reutilización. Un agente de programación colapsa esa sobrecarga. No recupera un componente prefabricado de una estantería; sintetiza uno a medida bajo demanda, a partir de una descripción de la intención y contra el contexto específico de la base de código que tiene delante. El catálogo ya no es finito ni mantenido por humanos; es, en la práctica, la capacidad latente del modelo para generar la pieza que se necesita en el momento de pedirla.

La capacidad ya no es especulativa, pero la historia del benchmark exige precisión. El paper original de SWE-bench de 2023 informó de un mejor resultado del 1,96 por ciento en su test completo. SWE-bench Verified apareció después, por lo que aquel dato no era un resultado Verified. Anthropic informó de un 80,84 por ciento en Verified para Claude Opus 4.6 en febrero de 2026, mientras los responsables oficiales del benchmark documentaron contaminación y una clasificación muy comprimida cerca del techo (5). El Economic Index de Anthropic, basado en muestras de Claude.ai y su API asignadas a tareas O*NET, indicó en marzo de 2026 que cerca del 49 por ciento de los empleos había visto a Claude usarse para al menos una cuarta parte de sus tareas. Es cobertura acumulada observada en la plataforma, no la proporción de todo el trabajo realizada por IA (6).

La vieja tensión, ahora medible

La investigación de proveedor cuantifica varias señales de alerta. El estudio de GitClear de junio de 2026 analizó 623 millones de cambios desde 2023 hasta el primer semestre de 2026. Frente a 2023, informó de un 35 por ciento menos de llamadas entre funciones de distintos archivos, un 70 por ciento menos de líneas movidas por refactoring, un 81 por ciento más de duplicación de bloques, un 41 por ciento más de copia y pegado dentro del commit y un 15 por ciento más de churn a dos semanas (7). Son correlaciones en el conjunto de GitClear, no una estimación causal controlada del efecto de la IA. En la metáfora de Ward Cunningham, entregar más rápido posponiendo la consolidación puede generar deuda técnica cuyos intereses frenan después la entrega (8).

El panorama de la productividad es igualmente de doble filo. A mediados de 2025, la organización sin ánimo de lucro METR realizó el primer ensayo controlado aleatorizado del campo sobre la asistencia de IA en programación: dieciséis desarrolladores open source experimentados, trabajando en repositorios maduros que conocían bien, completaron 246 tareas reales con el uso de IA permitido o prohibido al azar (8). Los desarrolladores pronosticaron una aceleración del 24 por ciento; economistas expertos e investigadores de machine learning pronosticaron ganancias aún mayores. El resultado medido fue el contrario: las tareas tardaron, de media, un 19 por ciento más con IA. Más llamativa que la ralentización fue la brecha de percepción: incluso después de experimentarla, los desarrolladores estimaron que la IA los había acelerado un 20 por ciento. Es la sombra de Goodhart en un escenario nuevo: todas las métricas visibles (volumen de commits, número de pull requests, líneas entregadas) pueden subir mientras lo que importa, el tiempo hasta un resultado correcto y mantenible, se mueve en dirección contraria. Una preocupación complementaria, que los profesionales han empezado a llamar deuda de comprensión, nombra el riesgo más profundo: cuando la generación supera a la comprensión, las únicas personas capaces de revisar con fiabilidad la salida de la IA (los ingenieros sénior) se convierten en el cuello de botella, y los problemas que se les escapan llegan a producción.

Una primera objeción: las señales están cambiando

El contraargumento honesto es que cada cifra anterior es una instantánea de un objetivo en rápido movimiento. Las herramientas cambiaron durante 2025 y 2026, pero medir su efecto se hizo más difícil, no más concluyente.

El experimento posterior de METR estimó un 18 por ciento de aceleración para diez participantes que regresaron y un 4 por ciento para nuevos participantes. Ambos intervalos de confianza incluían cero, y METR concluyó que la selección de personas y tareas y la medición del tiempo hacían que el experimento no fuera una señal fiable del efecto actual (10). DORA también obtuvo un cuadro cambiante: en 2024 cada 25 por ciento más de adopción se asoció con un 1,5 por ciento menos de throughput y un 7,2 por ciento menos de estabilidad; en 2025, una mayor adopción se asoció con más throughput y también más inestabilidad (11). Estos datos observacionales no prueban la causa. Las organizaciones deben medir sus propios tiempos de revisión, retrabajo, incidentes y mantenibilidad.

Adónde va el oficio: hacia arriba en el stack

La resolución de la paradoja es que la IA no elimina la disciplina de ingeniería; la reubica. Las prácticas que defendían los firmantes de Agile (desarrollo guiado por pruebas, integración continua, refactoring, mantenimiento de la salud del código) no quedan obsoletas cuando una máquina escribe las líneas. Migran de la pulsación de tecla a la especificación, del acto de teclear código al acto de definirlo, restringirlo y verificarlo. La expresión más clara de esta migración es el rápido auge, durante 2025-26, del spec-driven development. Es la práctica de escribir una especificación estructurada y versionada (objetivos, restricciones, criterios de aceptación) antes de invocar a un agente de programación. El agente dispone así de una intención explícita que implementar, en lugar de un prompt vago que interpretar.

Para la decisión concreta sobre la herramienta, nuestro análisis de GitHub Spec Kit para equipos de producción cubre comandos actuales, límites, seguridad, coste y diseño del piloto.

Andrej Karpathy acuñó “vibe coding” en febrero de 2025 para un flujo deliberadamente laxo en el que el desarrollador deja en gran medida de leer el código y acepta cambios del modelo. Su publicación original lo presentaba para proyectos desechables de fin de semana, no como método de producción (12). El desarrollo guiado por especificaciones es una familia más estructurada. Spec Kit de GitHub trata objetivos, restricciones y criterios de aceptación como entradas versionadas de las que derivan planes e implementaciones (13). Eso no vuelve correctas las especificaciones por sí solas ni hace spec-driven a todas las herramientas.

El papel humano cambia en proporción. El ingeniero de la fábrica agéntica dedica menos tiempo a escribir código fundacional y más a la arquitectura, la precisión de la especificación y la vigilancia de la calidad: propiedad de producto en el sentido más pleno. La metáfora que se repite en la literatura de los profesionales es acertada: la IA carga las piedras; el arquitecto sigue diseñando e inspeccionando la pirámide. No es una merma del criterio de ingeniería, sino una concentración de él, y por eso exactamente las organizaciones que extirpan el criterio, esperando que lo supla el modelo, encuentran la duplicación y el churn que midió GitClear. El modelo suministra código. No suministra cuidado.

Preservar la agilidad: el problema de la gobernanza

Aquí el argumento se reencuentra con el más antiguo sobre el Agile empresarial, porque los modos de fallo riman. La software factory original eliminó el criterio artesanal y llamó industrialización al resultado; el Agile empresarial eliminó las prácticas técnicas y conservó las ceremonias; la adopción descuidada de la IA elimina la comprensión y conserva el panel de velocity. En cada caso se preserva la superficie visible y auditable mientras se vacía la sustancia que soporta la carga. La fábrica agéntica no es, por tanto, automáticamente una restauración de la agilidad; es una bifurcación del camino. Por una vía, la IA se convierte en el instrumento definitivo de desingeniería: una máquina para generar código sin revisar, duplicativo y ciego al contexto a escala industrial, con todas las métricas de productividad en verde mientras la deuda técnica y la de comprensión se acumulan por debajo. Por la otra, se convierte en la primera herramienta que ofrece a la vez el rendimiento de la fábrica y la adaptabilidad del oficio.

Lo que separa los caminos es la gobernanza, y sus componentes se comprenden hoy razonablemente bien. Incluyen la disciplina de especificación como capacidad organizativa y no como hábito individual (especificaciones vivas, bajo control de versiones, que persisten más allá de cualquier sesión de agente); puertas de calidad automatizadas entre la salida del agente y la aceptación humana, de modo que un agente que produce mil pull requests a la semana con una tasa de vulnerabilidades de tan solo el uno por ciento no entregue en silencio diez nuevas debilidades; flujos de revisión readaptados a los nuevos modos de fallo, que tienen forma estructural y de seguridad, no de errata; y contexto persistente y gobernado (memoria compartida, convenciones y restricciones que viajan con la base de código, para que el agente deje de reimportar la duplicación a la que el modelo tiende por defecto). Para los dominios regulados (los servicios financieros, la sanidad y la infraestructura de finanzas on-chain en la que trabaja Polity), esta capa de gobernanza no es un pulido opcional; es la condición previa bajo la cual el rendimiento agéntico resulta siquiera admisible. El control que la fábrica original imponía desde arriba, y que el Agile empresarial imponía como ceremonia, se reimagina aquí como disciplina incrustada en el propio sustrato de desarrollo, cerca del ingeniero, expresada como especificación ejecutable y verificación automatizada, no como el libro del capataz.

Para algunos usos regulados también es una cuestión jurídica. Según el texto consolidado del Reglamento de Inteligencia Artificial de la UE, las secciones 1 a 3 del capítulo III aplican desde el 2 de diciembre de 2027 a sistemas de alto riesgo del anexo III y desde el 2 de agosto de 2028 a sistemas de alto riesgo vinculados a productos del anexo I. Los artículos 11, 12 y 14 exigen documentación técnica, registro automático de eventos y supervisión humana efectiva a los sistemas que realmente entren en esas categorías (14). Una especificación versionada, un rastro de auditoría y una puerta de aprobación pueden apoyar esos controles, pero no equivalen automáticamente al cumplimiento legal.

La fábrica hecha realidad: un caso concreto

En febrero de 2026 Stripe describió Minions, sus agentes de programación desatendidos y de una sola ejecución. Stripe afirma que cada semana se fusionan más de mil pull requests escritos por completo por Minions tras revisión humana. Su keynote de desarrollo confirmó más de mil pull requests semanales enviados a producción con revisión y aprobación humana. La carta anual de 2025 informó de 1,9 billones de dólares de volumen total, sin implicar que cada Minion trabaje en código crítico de pagos (15).

Stripe atribuye el resultado a mucho más que un modelo: entornos de desarrollo aislados, contexto del repositorio, reglas por ubicación, linting, pruebas selectivas de una suite de más de tres millones y revisión humana. Minions se basa en un fork del agente open source Goose de Block, pero la plataforma y las herramientas internas de Stripe son propias. El relato demuestra que un alto throughput puede coexistir con controles deterministas y aprobación humana; no publica una comparación controlada, una tasa de defectos ni el coste por pull request (15).

Conclusión: la fábrica con conciencia

La propuesta de McIlroy de 1968 acertó en el destino y se equivocó en la ruta. Creía que la industrialización exigía piezas estandarizadas, catalogadas por humanos, y el aparato taylorista para gestionarlas; esa ruta mató la agilidad que el software necesita y el criterio que aportan los ingenieros. La IA agéntica alcanza el destino por un camino distinto (generar componentes a medida bajo demanda en lugar de pedir componentes genéricos) y, al hacerlo, elimina el obstáculo concreto que derrotó a la fábrica durante medio siglo. Pero hereda el pecado original en una forma nueva. La tentación de tratar el modelo como sustituto de la cultura de ingeniería, en lugar de como un instrumento manejado por ella, es la misma tentación que vació la fábrica literal y después el Agile empresarial, ahora disponible a mucha mayor velocidad y escala.

La objeción más fuerte sigue siendo que, si los agentes llegan a especificar, escribir, probar y revisar, «conservar el oficio» podría describir una transición. Stripe ya demuestra que las personas no necesitan teclear cada cambio fusionado. Sin embargo, su sistema publicado sigue dependiendo de revisión humana, controles deterministas e infraestructura diseñada por ingenieros. El punto duradero no es que cada pull request deba revisarse siempre igual de forma manual, sino que una organización responsable debe definir qué se construye, qué evidencia cuenta como correcta, qué fallos son tolerables y cuándo la automatización puede aprobar un cambio.

La lección que los firmantes de Agile llevan dos décadas intentando transmitir se aplica, sin cambios, a la era agéntica: la ligereza del proceso debe ganarse con la solidez de la ingeniería que hay debajo. La IA hace la ligereza casi gratuita y la solidez casi opcional, y precisamente por eso la solidez debe ser ahora una elección deliberada, codificada en especificaciones, aplicada mediante puertas de calidad y en manos de humanos cuyo papel ha ascendido de escribir código a gobernar su creación. La fábrica ha regresado. Que industrialice el software o lo desingenierice (que preserve la agilidad o se limite a automatizar su destrucción) no lo decidirá el modelo. Lo decidirá, como siempre ha sido, que la organización elija conservar el oficio.

La historia del Agile empresarial enseñó que un método no se vuelve peligroso cuando es erróneo, sino cuando sus ceremonias sobreviven al oficio que les daba sentido. La fábrica agéntica plantea la misma prueba a mayor velocidad: recompensará a las organizaciones que suban su disciplina de ingeniería en el stack y castigará, más rápido que nunca, a las que confundan la desaparición del tecleo con la desaparición de la necesidad de ingeniería.

Acerca de Polity

Este artículo forma parte de un programa continuo de publicaciones sobre gobernanza y liderazgo intelectual desarrollado dentro del modelo de gobernanza de Polity. La tesis central de Polity es que los resultados duraderos están determinados por la arquitectura de gobernanza: las reglas, incentivos e instituciones mediante los que se forman el trabajo, el valor y la obligación. La fábrica de software agéntica es un problema de gobernanza exactamente en este sentido: la misma capacidad de generar código industrializa o desingenieriza según la disciplina que la envuelva. Polity construye infraestructura para las finanzas digitales reguladas, con marcos de gobernanza diseñados para conectar sistemas descentralizados y requisitos de cumplimiento de nivel institucional; la cuestión de cómo admitir una producción de software autónoma y de alto rendimiento en un entorno regulado sin sacrificar las garantías es una de las que aborda directamente.

Acerca de Wavect

Wavect GmbH es una agencia austriaca de ingeniería de software que construye software orientado a producto para startups, scale-ups y grandes empresas. Su trabajo abarca desarrollo full-stack, liderazgo fraccional de ingeniería y producto, aseguramiento de calidad de software y aplicaciones de inteligencia artificial, blockchain y sistemas zero-knowledge. Wavect ha prestado servicios de desarrollo de software y aseguramiento de calidad al programa Polity, y el coautor Kevin Riedl es Managing Partner de la empresa. Más información en https://wavect.io.

Aviso: Este artículo se publica únicamente con fines informativos y educativos. No constituye asesoramiento profesional, jurídico, financiero ni de gestión de ingeniería. Las cifras se comprobaron contra las fuentes citadas hasta el 2 de septiembre de 2026; varias proceden de estudios controlados con muestras limitadas o datos observacionales de proveedores y se identifican como tales. El coautor Kevin Riedl es Managing Partner de Wavect GmbH, que presta servicios al programa Polity. Las opiniones pertenecen a los autores.

Referencias y fuentes primarias

1. Naur, P. and Randell, B. (eds.) (1969). Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. Original 1968 conference report. NATO report (reviewed 2 September 2026).
2. McIlroy, M.D. (1968). “Mass Produced Software Components”. Author-hosted text (reviewed 2 September 2026).
3. Cusumano, M.A. (1989). The Software Factory: A Historical Interpretation. Field research based on company data, site visits and manager interviews. Computer History Museum archive (reviewed 2 September 2026).
4. Agile Manifesto authors (2001). Official history; official manifesto (reviewed 2 September 2026).
5. Jimenez, C.E. et al. (2023). SWE-bench; Anthropic (2026), Claude Opus 4.6 System Card; SWE-bench public experiments. Original paper; system card; experiment records (reviewed 2 September 2026).
6. Anthropic (2026). “Anthropic Economic Index report: Learning curves”. Economic Index (reviewed 2 September 2026).
7. GitClear (2026). The Maintainability Gap: AI Code Quality in 2026. Vendor observational research covering 623 million changes. GitClear report (reviewed 2 September 2026).
8. Cunningham, W. (1992). “The WyCash Portfolio Management System”; Becker, J. et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Cunningham report; METR study (reviewed 2 September 2026).
9. Becker, J. et al. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR study; paper (reviewed 2 September 2026).
10. METR (2026). “We Are Changing Our Developer Productivity Experiment Design”. METR follow-up (reviewed 2 September 2026).
11. DORA (2024; 2025). Official software-delivery research. 2024 report; 2025 report; 2025 errata (reviewed 2 September 2026).
12. Karpathy, A. (2025). Original “vibe coding” post (reviewed 2 September 2026).
13. GitHub (2026). “What is Spec-Driven Development?” Spec Kit documentation (reviewed 2 September 2026).
14. European Union (2024, consolidated 27 July 2026). Regulation (EU) 2024/1689, Articles 11, 12, 14 and 113, as amended by Regulation (EU) 2026/1744. Consolidated AI Act; amending regulation (reviewed 2 September 2026).
15. Stripe (2026). Minions engineering posts, developer keynote and 2025 annual letter. Part 1; Part 2; keynote; annual letter (reviewed 2 September 2026).