La mayoría de las empresas piensan que están construyendo una fábrica de software. En realidad, solo están enviando errores más rápido.

Las fábricas industrializadas cambiaron cómo el mundo producía bienes físicos: más producción, costos más bajos, más rápido que cualquier cosa anterior. Ahora, un cambio similar está ocurriendo con el software. Los LLM han reducido la barrera para escribir código, aumentado la producción individual y empujado a las organizaciones a pensar en el desarrollo de software como un sistema de producción. El ciclo de vida estándar del desarrollo de software y las prácticas de CI/CD que han perdurado durante décadas no podrán sostenerse bajo esa presión. Ahí es donde entra la fábrica de software — y, al igual que las fábricas físicas, necesita más que velocidad para funcionar realmente. La idea de una “fábrica de software” comenzó a solidificarse en el último año. "La Era de la Fábrica de Software" de Luca Rossi expuso claramente el argumento: la IA no solo está cambiando la rapidez con la que las personas escriben código, sino que está alterando todo el sistema de producción de software. El concepto puede significar diferentes cosas: una colección de agentes de codificación y archivos de habilidades; CI/CD más rápido; mejores sistemas de revisión; o más automatización en torno a la entrega de software. Un marco mejor es pensar en ello menos como una categoría de herramientas y más como un conjunto de principios. Una fábrica de software no puede ser solo una colección dispersa de prompts, agentes y plugins. Necesita una plataforma que defina cómo se mueve el trabajo a través del sistema y cómo se genera, revisa, prueba, rastrea, despliega y mejora el código cuando algo sale mal. De lo contrario, solo estás poniendo otra máquina única en una habitación vacía y llamándola fábrica. ¿Por qué está sucediendo esto ahora? Hay algunas fuerzas que están golpeando al mismo tiempo. Las empresas siempre han querido más software del que los ingenieros pueden producir. Esa es la razón por la que existen herramientas como Excel: a menudo llenan el vacío para mucho del software que muchas empresas desearían poder hacer. La IA también ha bajado la barrera de entrada para crear código, y esta es la parte en la que todos se enfocan. La creación de código es ahora más fácil, aunque no siempre más barata o mejor, como lo evidencian muchas empresas de alto perfil preocupándose por sus altos gastos en IA. La barrera para escribir código funcional ha caído efectivamente. Más importante aún, un solo ingeniero puede generar más código del que podría hace pocos años. Eso cambia el cuello de botella: ya no es “¿Qué tan rápido puede alguien escribir esto?” o incluso, en algunos casos, “¿Puede alguien entender cómo codificar?” En su lugar, se convierte en “¿Debería escribirse esto?” Más importante aún, ¿podemos realmente crear productos finales que sean duraderos y fiables y que no solo generen deuda técnica? ¿O solo estamos sacando más desechos de IA más rápido que nunca? Ahí es donde radica el peligro. Los peligros de la fábrica de software moderna Todo esto suena genial. Las fábricas, después de todo, hicieron la producción más rápida y consistente. Hicieron posible construir más automóviles y productos, menos costosos, lo que llevó a que más personas pudieran permitirse automóviles y productos. Dejando de lado los impactos ambientales, podrías argumentar que esto fue positivo. Pero, como muchas cosas en ingeniería, siempre hay compromisos, y en este caso, hay nuevos riesgos. Cuando aumentas la producción de una persona con maquinaria, digital o de otro tipo, también aumentas los errores que puede cometer el individuo o la maquinaria. La velocidad a la que ahora se puede producir código es a una escala industrial. Incluso las organizaciones más pequeñas pueden tener de repente bases de código que crecen hasta el tamaño de las bases de código de las empresas tecnológicas de hace una década. Los datos ya están mostrando problemas. Faros AI encontró que, aunque el rendimiento por desarrollador ha aumentado un 33.7% y la tasa de fusión de PR ha aumentado un 16.2%, la proporción de incidentes por PR ha aumentado un 242.7% y los errores por desarrollador han aumentado un 54%. La investigación DORA de Google encontró que una mayor adopción de IA se asociaba en realidad con una peor estabilidad en la entrega. Como líder de datos fraccionado, me han traído para resolver estos problemas exactos. En el último año, he trabajado en dos proyectos donde la infraestructura de datos generada por IA comenzó a transformarse lentamente con el tiempo. Entre múltiples ingenieros tratando de moverse rápidamente y una falta de estándares, estos proyectos se volvieron caóticos. Las bases de código tienden a pasar por algún nivel de evolución, pero a medida que se combinan diferentes estilos, los LLM, a su vez, comienzan a crear sus propias mutaciones. Las bases de código desarrollaron de cinco a seis estilos diferentes en meses — un proceso que antes tomaba años. Capa por capa, los ingenieros dejaron de entender exactamente lo que estaba sucediendo. El patrón ecoa lo que sucedió hace una década con las herramientas de autoservicio: las primeras ganancias de productividad ocultaban la complejidad posterior. Y es por eso que la fábrica de software no puede ser solo sobre velocidad. Lo que hace que una fábrica de software funcione Hay varios principios clave a considerar al construir una fábrica de software. Plataforma sobre herramientas: Muchos equipos están implementando lentamente IA en sus flujos de trabajo de codificación en los bordes — añadiendo un agente de revisión de PR o un archivo de habilidades en sus repos. Pero construir una fábrica de software real requiere una plataforma, no una colección de herramientas en los bordes. Una plataforma proporciona una base unificada donde las herramientas no están dispersas en rincones separados. En su lugar, comparten activamente datos, se comunican entre sí y funcionan como un único sistema cohesivo — estándares, procesos y el trabajo en sí están todos conectados. Reejecutabilidad y trazabilidad: Una verdadera plataforma requiere la capacidad de volver a cualquier ejecución, identificar qué salió mal y volver a ejecutarla — razón por la cual los agentes únicos no constituyen una fábrica. El sistema necesita soportar la toma de un ID serial, buscarlo y rastrear exactamente cómo llegó a la salida que produjo. Por esto es que las máquinas de estado tienen más sentido que los bucles para los flujos de trabajo de IA: facilitan volver a ejecutar un proceso y entender qué sucedió en cada paso. Seguridad y barandillas: Las fábricas no son lugares seguros. Tampoco lo es una fábrica de software. A medida que más personas desarrollan en estas plataformas, se necesitan construir mejores barandillas y medidas de seguridad. Las pruebas y el control de calidad deben ser empujados a la parte frontal del proceso — detectar errores en la etapa más baja reduce el costo de arreglarlos y limita el radio de impacto. Estandarización: A nivel empresarial, cada base de código tiene su propio sabor. Superponer un asistente de código sin estándares produce una amalgama de estilos. La estandarización debe estar integrada en el proceso desde el principio. Control de calidad: En los modelos de manufactura anteriores, el control de calidad ocurría al final de la línea. El producto se construía, se inspeccionaba, se encontraban defectos y se corregían más tarde. El enfoque de Toyota era diferente. La calidad se integraba en el propio proceso — se esperaba que los trabajadores detuvieran la línea cuando algo estaba mal. El objetivo no era capturar defectos al final; era prevenir que fluyeran hacia abajo en primer lugar. Lo mismo es cierto para la fábrica de software. El control de calidad debe estar incorporado en todo el proceso, comenzando con la forma en que se escribe la especificación. Eso significa integrar análisis estático de código que detecte errores obvios y proporcionar plantillas a los LLM para que sepan la estructura que el código debe seguir. Sin eso, el cuello de botella se convierte en la revisión final — o los equipos simplemente sacan más desechos de IA. La velocidad sin calidad no es productividad Mejorar la velocidad de tu producción de código no es productividad real si no se manejan los problemas posteriores. Una empresa no es más productiva porque produzca millones de automóviles, solo para ver cómo todos se desmoronan dentro de 100 millas. También no es más productiva si solo produce un flujo interminable de pruebas de concepto que nunca entran en producción. La productividad real es cuando la fábrica de software toma tokens efímeros y los convierte en resultados duraderos. Es fácil hablar sobre líneas de código y cuán más rápido se mueve tu equipo. La fábrica de software que gana no es la que genera más código. Es la que genera menos defectos en el flujo posterior.