A principios de este año, nuestro equipo en 8090 desmontó el motor de facturación de una gran entidad. Eran 18 millones de líneas de COBOL y Assembly acumuladas desde antes de que algunos de nuestros ingenieros nacieran. Ya nadie lo entendía por completo, pero usando nuestra Software Factory, lo reingenierizamos inversamente 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é de repente todos los demás también estaban usando la frase "software factory".
El concepto se está apropiando porque implica un cierto nivel de confiabilidad industrial que las empresas quieren pero no están obteniendo. Las software factories tienen cincuenta años de historia detrás, y su característica definitoria 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 disperso 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 software factories japonesas produjeron algunos de los códigos más confiables jamás escritos. Los sistemas que generaron alimentaron la banca, los ferrocarriles 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 el diseño inicial en lugar de corregida con heroicidades posteriores. La Fuerza Aérea de EE. UU. opera software factories hoy en día. Kessel Run construye y opera software de misión para el Departamento de Defensa, y cuando ese software falla, ellos son responsables.
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 bienes terminados y respondía por la calidad de esos bienes. Dicho de otra manera, Ford nunca te vendió una llave inglesa, 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 software factories modernas deben cumplirlo también.
Las cinco pruebas
Una software factory debería pasar cinco pruebas. Si falla en alguna, entonces es 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, limitaciones 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 de poder acoplada a un proceso existente. El objetivo de una fábrica es que el cliente describa el producto y la fábrica descubra cómo producirlo.
Prueba dos: una fábrica mantiene la coherencia bajo cambios continuos. Esta es la prueba más difícil, y es de la que casi nadie en el mercado de herramientas de IA habla, 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 desgarre. 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 sube de 5 a 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 basado en 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 tomó cuatro décadas en construirse manualmente, pero las flotas de agentes sin gobernanza lo construirán en unos pocos años.
Una software factory funcional mantiene la intención, la especificación, el código, las pruebas y el comportamiento en producción sincronizados como un objeto gobernado único. 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 diffs y quién atrape los errores. Esa variación es aceptable en una herramienta. Es descalificante en un sistema de producción. Una fábrica debería producir a velocidad y calidad predecibles sin importar quién esté en el turno, que es exactamente lo que los controles estadísticos de Hitachi estaban diseñados para garantizar: 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 la comprensión del código vive en las personas, y a lo largo de muchos 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 insustituible. 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. "Lo escribió el modelo" no es una respuesta que un auditor acepte. Una software factory produce la pista de auditoría como subproducto de la propia producción: esta regla existe debido a este requisito, aprobado por esta persona, implementado en este cambio, verificado por esta prueba, desplegado en este momento. La procedencia debe 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 software factory de una herramienta de desarrollador, porque es la que la mayoría de los proveedores de herramientas no están dispuestos a cumplir.
Una fábrica envía un producto del cual responde. Cuando el motor de facturación calcula mal una reclamación, cuando el sistema de trading produce un número incorrecto, 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 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 reclamaciones por pagar en un prefiltro determinista y redujo las reclamaciones enviadas a un proveedor de pago por captura en más del 80%, evitando más de $20 millones en cuatro años. Números como esos solo ocurren 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 insumo, producen código como resultado 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 arneses 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á derrumbando. Y cuando los costos de producción se derrumban, el valor migrará hacia quien pueda garantizar el resultado. Esto ha sucedido en cada proceso de industrialización antes de este 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 demos y benchmarks, y hazle una pregunta a cada software factory: cuando el sistema falla en producción, ¿quién recibe la llamada?
En el caso de una software factory, la respuesta debe ser "nosotros".
