Las fábricas industrializadas cambiaron la forma en que el mundo producía bienes físicos: mayor producción, menores costos y más rápido que cualquier cosa anterior. Ahora se está produciendo un cambio similar con el software.
Los LLM han reducido la barrera para escribir código, han aumentado la producción individual y han impulsado a las organizaciones a pensar en el desarrollo de software como un sistema de producción. El ciclo de vida de desarrollo de software estándar y las prácticas de CI/CD que se han mantenido durante décadas no resistirán esa presión. Ahí es donde entra en juego la fábrica de software y, al igual que las fábricas físicas, necesita algo más que velocidad para funcionar.
La idea de una “fábrica de software” comenzó a solidificarse durante el año pasado. «La era de la fábrica de software» de Luca Rossi Lo planteó claramente: la IA no sólo está cambiando la rapidez con la que las personas escriben código, sino que está cambiando todo el sistema de producción en torno al 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 mejor marco 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 simplemente una colección suelta de mensajes, agentes y complementos. Necesita una plataforma que defina cómo se mueve el trabajo a través del sistema y cómo se genera, revisa, prueba, rastrea, implementa y mejora el código cuando algo sale mal.
De lo contrario, lo único que estaría haciendo sería colocar otra máquina única en una habitación vacía y llamarla fábrica.
¿Por qué sucede esto ahora?
Hay algunas fuerzas que chocan todas al mismo tiempo.
Las empresas siempre han querido más software del que los ingenieros pueden producir. Por eso existen herramientas como Excel: a menudo llenan el vacío de gran parte del software que muchas empresas desearían poder fabricar.
La IA también ha reducido la barrera de entrada a la creación de código, y esta es la parte en la que todos se centran. La creación de código ahora es más fácil, aunque no siempre más barata o mejor, como lo demuestran muchas empresas de alto perfil. Preocupados por sus elevadas facturas de IA.. La barrera para escribir código funcional efectivamente se ha derrumbado.
Más importante aún, un solo ingeniero puede generar más código que hace unos años. Eso cambia el cuello de botella: ya no se trata de «¿Qué tan rápido puede alguien escribir esto?» o incluso, en algunos casos, «¿Alguien puede entender cómo codificar?» En cambio, se convierte en: «¿Debería escribirse esto?»
Más importante aún, ¿podemos realmente crear productos finales que sean duraderos y confiables y que no generen simplemente deuda tecnológica? ¿O simplemente estamos lanzando más desechos de IA más rápido que nunca? Ahí es donde reside el peligro.
Los peligros de la fábrica de software moderna
Todo esto suena genial. Después de todo, las fábricas hicieron que la producción fuera más rápida y consistente.
Hicieron posible fabricar más automóviles y productos a menor costo, lo que llevó a que más personas pudieran permitirse automóviles y productos. Dejando de lado los impactos ambientales, se podría argumentar que esto fue positivo.
Pero como ocurre con muchas cosas en ingeniería, siempre hay compensaciones y, en este caso, nuevos riesgos.
Cuando aumenta la producción de una persona con maquinaria, digital o de otro tipo, también aumenta los errores que puede cometer el individuo o la maquinaria. La velocidad a la que ahora se puede publicar código es a escala industrial. Incluso las organizaciones más pequeñas pueden tener repentinamente bases de códigos que alcanzan el tamaño de las bases de códigos de las empresas de tecnología hace una década.
Los datos ya muestran problemas. Faros AI descubrió que, si bien el rendimiento de las tareas por desarrollador aumentó un 33,7% y la tasa de fusión de relaciones públicas aumentó un 16,2%, el La relación incidentes-PR ha aumentado un 242,7 %. y los errores por desarrollador aumentaron un 54%. La investigación DORA de Google encontró que en realidad se necesitaba una mayor adopción de la IA. asociado con una peor estabilidad del parto.
Como jefe de datos fraccional, me contrataron para solucionar exactamente estos problemas. Solo el año pasado, trabajé en dos proyectos en los que la infraestructura de datos generada por IA comenzó a transformarse lentamente con el tiempo.
Entre varios ingenieros que intentaban avanzar rápidamente y la falta de estándares, estos proyectos se volvieron rebeldes. Las bases de código tienden a pasar por cierto nivel de evolución, pero a medida que se combinan diferentes estilos, los LLM, a su vez, comienzan a crear sus propias mutaciones. Codebases desarrolló de cinco a seis estilos diferentes en unos meses, un proceso que anteriormente llevaba años. Capa por capalos ingenieros poco a poco dejarían de entender exactamente lo que estaba pasando.
El patrón se hace eco de lo que ocurrió hace una década con las herramientas de autoservicio: ganancias tempranas de productividad que enmascararon la complejidad posterior.
Y es por eso que la fábrica de software no puede centrarse sólo en la velocidad.
¿Qué 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 la IA en sus flujos de trabajo de codificación en los bordes, agregando un agente de revisión de relaciones públicas o un archivo de habilidades a sus repositorios. Pero construir una fábrica de software real requiere una plataforma, no una colección de herramientas en los extremos. Una plataforma proporciona una base unificada donde las herramientas no están dispersas en rincones separados. En cambio, comparten datos activamente, hablan entre sí y trabajan como un único sistema cohesivo: estándares, procesos y el trabajo en sí, todos conectados.
Rerunabilidad y trazabilidad: Una plataforma real 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 crean una fábrica. El sistema debe permitir tomar una identificación de serie, buscarla y rastrear exactamente cómo llegó al resultado que produjo. Es por eso que las máquinas de estado tienen más sentido que los bucles para los flujos de trabajo de IA: hacen que sea mucho más fácil volver a ejecutar un proceso y comprender 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 se desarrollen en estas plataformas, mejores barandillas y se deben incorporar medidas de seguridad. Las pruebas y el control de calidad deben pasar al frente del proceso: detectar errores en la etapa más baja posible reduce el costo de corregirlos y limita el radio de explosión.
Normalización: A nivel empresarial, cada código base tiene su propio estilo. Colocar un asistente de código encima sin estándares produce una amalgama de estilos. La estandarización debe incorporarse al proceso desde el principio.
Control de calidad: En los modelos de fabricación más antiguos, el control de calidad se realizaba al final de la línea. El producto fue construido, inspeccionado, encontrado defectos y reparado posteriormente. El enfoque de Toyota fue diferente. La calidad se introdujo en el proceso mismo: se esperaba que los trabajadores detuvieran la línea cuando algo andaba mal. El objetivo no era detectar defectos al final; En primer lugar, fue para evitar que fluyeran río abajo.
Lo mismo ocurre con la fábrica de software. El control de calidad debe integrarse en todo el proceso, empezando por cómo se escriben las especificaciones. Eso significa integrar un análisis de código estático que detecte errores obvios y proporcionar plantillas a los LLM para que sepan la estructura que debe seguir el código. Sin eso, el cuello de botella se convierte en la revisión final, o los equipos simplemente eliminan más desechos de IA.
Velocidad sin calidad no es productividad
Mejorar la velocidad de salida de su código no es productividad real si no se gestionan los problemas posteriores. Una empresa no es más productiva porque produce millones de automóviles y los ve todos desmoronarse en un radio de 160 kilómetros. Tampoco es más productivo si todo lo que hace es producir un flujo interminable de pruebas de concepto que nunca entran en producción.
La productividad real se produce cuando la fábrica de software toma tokens efímeros y los convierte en resultados duraderos. Es fácil hablar de líneas de código y de qué tan rápido se mueve su equipo.
La fábrica de software que gana no es la que genera más código. Es el que genera menos defectos aguas abajo.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
