A principios de este año, nuestro equipo en 8090 desarmó el motor de facturación de una entidad grande. Tenía 18 millones de líneas de COBOL y Assembly que se habían acumulado desde antes de que algunos de nuestros ingenieros nacieran. Ya nadie lo entendía por completo, pero usando nuestra Software Factory, lo reingenierizamos en más de 100,000 reglas en inglés sencillo en 40 días. Al terminar ese trabajo, me di cuenta de por qué la frase "software factory" de repente la usaban todos los demás también.
El concepto se está apropiando porque implica un cierto nivel de confiabilidad industrial que las empresas quieren pero no están obteniendo. Las fábricas de software tienen cincuenta años de historia detrás, y su característica definitoria única es algo que las empresas necesitan más que nunca: un sistema de producción que garantice resultados. Esto contrasta con una creciente frustración por un conjunto de herramientas que empoderan a individuos pero están haciendo que los sistemas completos sean más caóticos.
El término es más antiguo de lo que la mayoría cree
Hitachi abrió "Software Works" en 1969 como una fábrica literal: un edificio donde el software se producía bajo control estadístico de calidad, con tasas de defectos medidas por cada mil líneas de código, procesos estandarizados y un equipo de gestión responsable de la calidad del resultado. Toshiba, NEC y Fujitsu siguieron el ejemplo, y durante las décadas de 1970 y 1980, estas fábricas de software japonesas produjeron algunos de los códigos más confiables jamás escritos. Los sistemas que producían operaron la banca, el ferrocarril y la infraestructura eléctrica durante décadas.
En 2004, dos arquitectos de Microsoft publicaron un libro llamado "Software Factories" argumentando que el software debería construirse como se construyen los autos: a partir de componentes probados, en líneas de producción repetibles, con variación controlada por un diseño inicial en lugar de corregirse con heroicidades posteriores. La Fuerza Aérea de EE. UU. opera fábricas de software hoy en día. Kessel Run construye y opera software de misión para el Departamento de Defensa, y cuando ese software falla, ellos lo asumen.
A lo largo de sesenta años, una cosa se mantuvo constante hasta esta ola de IA. Una fábrica nunca fue una herramienta o un truco de productividad, por bueno que fuera. Una fábrica era un sistema de producción que tomaba insumos, producía productos terminados y respondía por la calidad de esos productos. Dicho de otra manera, Ford nunca te vendió una llave, algunas piezas y te deseó buena suerte. Ford te vendió un auto, y si el auto fallaba, Ford lo retiraba, porque era su fábrica la que lo había producido.
Ese es el estándar, y yo diría que las fábricas de software modernas también deben cumplirlo.
Las cinco pruebas
Una fábrica de software debería pasar cinco pruebas. Si falla en alguna, tienes otra cosa. Esa otra cosa es probablemente una herramienta de desarrollador, que puede ser útil, pero es un producto diferente con una obligación diferente.
Prueba uno: una fábrica comienza con la intención del negocio. El insumo de una fábrica es lo que el negocio necesita, expresado en el lenguaje del negocio: requisitos, reglas, restricciones regulatorias, resultados deseados. Si el insumo, en cambio, es un ticket de Jira escrito por un ingeniero para otro ingeniero, estás viendo una herramienta eléctrica acoplada a un proceso existente. El objetivo de una fábrica es que el cliente describa el producto y la fábrica descubra la producción.
Prueba dos: una fábrica mantiene la coherencia bajo cambios continuos. Esta es la prueba más difícil, y es la que casi nadie en el mercado de herramientas de IA menciona, porque sus productos la empeoran.
Escribir código nuevo nunca fue el cuello de botella en el software empresarial. El cuello de botella es que un sistema real se modifica cada semana por docenas de personas. Cada cambio es una oportunidad para que el sistema se desmorone. Los requisitos se desvían de la documentación. La documentación se desvía del código. El código se desvía de las pruebas. Deja que esa desviación se acumule durante veinte años y obtienes el motor de facturación que describí al principio: 18 millones de líneas que nadie entiende en su totalidad, un contrato de mantenimiento con proveedores que aumenta entre un 5 y un 8% anual, y una organización que ya no puede cambiar su propio software sin miedo.
La realidad es que la generación de código acelera la desviación. Si tus agentes producen diez veces más código contra especificaciones que no se mantienen sincronizadas, estás induciendo desviación a una velocidad sin precedentes. El problema de los 18 millones de líneas tardó cuatro décadas en construirse a mano, pero las flotas de agentes sin gobernanza lo construirán en unos pocos años.
Una fábrica de software que funciona mantiene la intención, la especificación, el código, las pruebas y el comportamiento de producción sincronizados como un único objeto gobernado. Cambia el requisito y el código cambia. Corrige el código en caliente y el requisito se actualiza. Pídele a un proveedor que te muestre este bucle cerrado, en vivo, en un sistema real. Si no pueden, están vendiendo generación de código. Y aunque útil, es algo diferente.
Prueba tres: una fábrica opera independientemente de cualquier persona específica. Una herramienta solo es tan buena como la persona que la maneja. Dale el mismo agente de codificación a dos ingenieros y obtendrás resultados radicalmente diferentes dependiendo de quién escriba los prompts, quién revise los cambios y quién detecte los errores. Esa variación es aceptable en una herramienta. Es descalificante en un sistema de producción. Una fábrica debe producir a una velocidad y calidad predecibles independientemente de quién esté en el turno, que es exactamente para lo que fueron diseñados los controles estadísticos de Hitachi: la calidad como propiedad de la línea, no del operador.
La forma en que una fábrica logra esto es que el conocimiento se acumula en el sistema en lugar de en los individuos. Cuando una persona se une, la fábrica le entrega todo lo que ya ha aprendido. Cuando una persona se va, nada sale por la puerta. La mayoría del software empresarial falla esta prueba de manera catastrófica. La razón por la que un motor de facturación se vuelve ilegible no es el mal código. Es que el entendimiento del código vive en las personas, y con los años las personas cambian. Si su conocimiento nunca es capturado por un sistema, el sistema se convertirá lentamente en una caja negra.
Para ser claros, esto no significa que las personas no importen o que una fábrica no exija responsabilidad. Una fábrica siempre tiene a alguien específico que responde por el resultado. Simplemente nunca depende de que ninguno de ellos sea irremplazable. Un sistema que necesita un héroe para funcionar no tiene ni responsabilidad ni fábrica. Tiene un héroe, y los héroes eventualmente encuentran nuevas aventuras.
Prueba cuatro: cada unidad de resultado es trazable. En una fábrica real, cada pieza tiene un "número de lote". Cuando algo falla, lo rastreas a través de la línea de producción hasta el lote, la máquina y el turno. Las industrias reguladas exigen exactamente esto del software, y es por eso que han sido las más lentas en adoptar herramientas de codificación con IA. "El modelo lo escribió" no es una respuesta que un auditor acepte. Una fábrica de software produce la pista de auditoría como subproducto de la producción misma: esta regla existe por este requisito, aprobado por esta persona, implementado en este cambio, verificado por esta prueba, desplegado en este momento. La procedencia tiene que estar integrada en la línea de producción, lo que significa que la documentación escrita después del hecho no cuenta.
Prueba cinco: alguien es responsable del producto terminado. Esta es la prueba que separa una fábrica de software de una herramienta de desarrollador, porque es la que la mayoría de los vendedores de herramientas no están dispuestos a cumplir.
Una fábrica envía un producto del que responde. Cuando el motor de facturación calcula mal un reclamo, cuando el sistema de trading produce un número equivocado, cuando la validación de fabricación aprueba una pieza defectuosa, alguien específico responde por ello, lo corrige y asume el costo. Ahora he leído muchos contratos de herramientas de IA y las secciones de propiedad intelectual ocupan páginas, pero la sección de responsabilidad suele ser una sola oración, y esa oración dice que el resultado se proporciona tal cual y la verificación es tu problema. Esto es completamente descalificante para una fábrica.
Uno de nuestros clientes, una aseguradora de salud que cotiza en bolsa, convirtió sus reglas de reclamos por pagar en un prefiltro determinista y redujo los reclamos enviados a un proveedor de pago por captura en más del 80%, evitando más de $20 millones en cuatro años. Números así solo suceden cuando la parte que realiza el trabajo es responsable del resultado.
Lo que no es una fábrica
Aplica las pruebas y muchos que se llaman a sí mismos fábrica son, en cambio, otra cosa.
Los agentes de codificación, por muy buenos que sean, son herramientas. Toman tareas de ingeniería como entrada, producen código como salida, y transfieren toda la verificación y responsabilidad a los ingenieros del cliente. Llamar a una flota de ellos una fábrica no cambia esto.
Los paneles de orquestación de agentes son herramientas de supervisión. Facilitan ver cómo trabajan los agentes.
Los benchmarks son herramientas de medición para herramientas. Una puntuación alta te dice que una herramienta es buena en tareas evaluadas. No puede decirte si tu sistema se mantiene coherente después de dos años de cambios continuos por equipos mixtos de humanos y agentes.
Por qué la definición importa ahora mismo
El costo de producir software se está desplomando. Y cuando los costos de producción se desploman, el valor migrará hacia quien pueda garantizar el resultado. Esto ha sucedido en cada proceso de industrialización anterior y volverá a suceder ahora con la IA.
Las startups que se aferran a la palabra "fábrica" entienden esto instintivamente. Pero muchas están buscando la credibilidad de la producción industrial sin aceptar la obligación que creó esa credibilidad en primer lugar.
Así que ignora las demostraciones y los benchmarks, y hazle una pregunta a cada fábrica de software: cuando el sistema falla en producción, ¿quién recibe la llamada?
En el caso de una fábrica de software, la respuesta debe ser "nosotros".
