Durante décadas, el principal recurso escaso en la industria del software fue el talento humano capaz de escribir código. Procesos como los sprints, las revisiones manuales de código o los ciclos de publicación se diseñaron bajo la premisa de que los humanos ejecutarían cada tarea.
Esa realidad está cambiando radicalmente. En septiembre de 2026, más del 40% de las pull requests en GitHub se iniciaron con un borrador generado por un agente automatizado, un dato que casi duplica el 17% registrado apenas en marzo del mismo año. La producción de software está migrando hacia las máquinas, pero los procesos que lo soportan no han evolucionado en la misma medida.
Los agentes automatizados han hecho que generar código sea rápido y económico, aunque su impacto en la entrega continua y la integración sigue madurando. Datos recientes de CircleCI indican un crecimiento del 59% en la ejecución diaria promedio de flujos de trabajo entre 2025 y 2026, con un aumento del 97% en los equipos más productivos y ausencia de incremento notable en el 25% inferior. Un análisis de una empresa que duplicó la producción de pull requests reveló que la carga por revisor se duplicó y que la revisión automática superó pronto a la humana en cobertura. 
«Cuando el trabajo se automatiza en cualquier industria, las personas no desaparecen. Dejan de realizar las tareas manualmente para comenzar a diseñar los sistemas que gestionan ese trabajo.»
Este fenómeno en la industria del software implica que los ingenieros dejan atrás la codificación manual para convertirse en ingenieros de procesos, arquitectos de fábricas de software que coordinan cómo se construye el código.
Lecciones de la manufactura aplicadas a la automatización
El desarrollo de software no es una línea de producción convencional: cada entrega es única y no se repite. Sin embargo, tres enseñanzas clave de la fabricación industrial resultan aplicables al trabajo con agentes automatizados.
Primero, el foco está en diseñar el sistema, no en mejorar individualmente cada paso. Por ejemplo, Ford redujo el tiempo de montaje del Modelo T de 12,5 horas a solo 93 minutos para 1914 no porque los operarios fueran más rápidos, sino por el rediseño de la línea de producción.
Segundo, la calidad debe incorporarse en cada etapa del proceso. Sakichi Toyoda inventó un telar que se detenía automáticamente ante una ruptura de hilo, permitiendo que un operador gestionara varias máquinas simultáneamente. Toyota adoptó este concepto, que fue promovido por W. Edwards Deming para eliminar la dependencia exclusiva de inspecciones finales.
Tercero, la velocidad del paso más lento marca el ritmo de todo el sistema, algo fundamental en la teoría de restricciones de Eliyahu Goldratt. Los agentes aceleran la programación, pero ahora la acumulación de trabajo sucede en revisión y verificación.
La fábrica de software como red interconectada de agentes
En una fábrica de software, múltiples agentes especializados cumplen tareas concretas y transfieren resultados entre sí a lo largo del ciclo de vida del desarrollo. Un agente investiga y traduce comentarios de usuarios y datos de uso en un resumen, que otro convierte en requisitos con criterios de aceptación claros. Un tercero genera el cambio en código, un agente revisor evalúa la implementación y un agente de pruebas valida las modificaciones. Finalmente, un agente de despliegue libera las nuevas funcionalidades controladas por «feature flags» y otro encargado de la confiabilidad gestiona incidentes en producción y genera nuevos trabajos para el ciclo.
Los traspasos entre agentes difieren de los humanos. Entre personas, una comunicación puede ser informal, por ejemplo, un hilo de Slack con contexto compartido. Pero entre agentes, el intercambio debe estar regido por contratos precisos que definan qué se transfiere, en qué formato y con qué evidencias. Por ejemplo, un requisito sin criterios de aceptación claros depriva al agente de codificación de un objetivo concreto, y un cambio sin pruebas no da certeza al agente de liberación.
«Un requisito sin criterios de aceptación no le da meta al agente de código, y un cambio sin pruebas no genera confianza en el agente de despliegue.»
El trabajo entre agentes también introduce nuevos fallos acumulativos: errores que se multiplican porque cada agente construye sobre la salida del anterior. Existe el riesgo de que los agentes acepten cambios defectuosos con demasiada facilidad o entren en ciclos repetitivos de corrección. Por ello, una red de agentes requiere puntos de control y un responsable que defina dónde estos deben ubicarse.
El ingeniero de software se convierte en ingeniero de procesos
Este responsable es el propio ingeniero de software, cuyo rol muta de crear código a diseñar el sistema que lo genera, prueba y despliega. Esta labor se vuelve incluso más técnica, porque implica la coordinación integral del desarrollo.
Sus cuatro funciones principales son:
- Diseñar el flujo de trabajo: determinar qué agentes existen, qué funciones desempeñan, qué actividades se ejecutan en paralelo y qué debe incluir cada traspaso.
- Definir estándares de calidad claros: especificaciones, criterios de aceptación, contratos de API y métricas que las máquinas puedan validar automáticamente.
- Mejorar continuamente la línea: cuando aparece un error en producción, el foco no está en quién lo causó sino en qué fallo del proceso permitió que llegara allí.
- Establecer puntos de supervisión humana: las máquinas controlan pasos rutinarios; los humanos intervienen en decisiones que implican juicio o riesgos importantes.
Por ejemplo, un agente puede ejecutar migraciones de base de datos que son complejas y caras de corregir manualmente, pero fáciles de validar mecánicamente, por lo que se someten a estrictas verificaciones automáticas. En cambio, textos de interfaz de usuario, que admiten interpretaciones y son baratos de cambiar, pasan por revisiones humanas posteriores al despliegue. Además, solo las decisiones sobre qué construir o dónde colocar límites de seguridad exigen validación humana.
La calidad se integra en cada cambio, no se inspecciona al final
La mayoría de los equipos aún mantiene modelos tradicionales de aseguramiento de calidad, en los que las modificaciones se apilan y se inspeccionan al final, en un entorno compartido de preproducción con revisión humana. Este método funciona como un cuello de botella, tal y como explicó Goldratt en «La Meta».
Siguiendo la inspiración del telar de Toyoda, la calidad debe incorporarse al proceso en tiempo real. En una fábrica de software eficiente, el agente de pruebas verifica cada cambio conforme se crea; si falla, el agente de codificación corrige y nada avanza hasta que pase el chequeo.
Estas comprobaciones solo tienen valor si se ejecutan en un entorno que simula fielmente producción, con servicios, bases de datos y APIs reales, no con simulacros simplificados que solo funcionan en mundos hipotéticos. Por ello, cada cambio dispone de un entorno propio que se levanta en segundos, implementa únicamente lo modificado y comparte otros elementos para verificar la alteración integral antes del despliegue final.
Las barreras de seguridad se integran en la línea, no solo en instrucciones
La verificación detecta errores, pero se requieren mecanismos que los prevengan antes de que sucedan. Asumiendo que los agentes automatizados actuarán según lo permitido por el sistema, es imprescindible diseñar el flujo para que solo se permita el trabajo seguro.
En manufactura, este concepto se llama error-proofing: en lugar de un cartel que instruye cómo montar una pieza, se usan pesos o fijaciones que solo permiten una configuración correcta. En agentes software, una instrucción en un «prompt» equivale a ese cartel; en cambio, la definición de límites de permisos es la fijación.
Por ello, cada agente dispone solo del acceso necesario para su etapa y nunca, por ejemplo, de credenciales de producción. Las ejecuciones se aíslan para evitar que pruebas defectuosas impacten otras tareas, se aplican verificaciones obligatorias y siempre que algo falle, el proceso se detiene. Además, la confianza no se transmite en cadena entre agentes: un agente revisor no puede ampliar los permisos del agente encargado del despliegue.
El juicio humano permanece y se convierte en el núcleo del trabajo
Las fábricas no eliminaron a sus ingenieros: crearon la ingeniería industrial. No es posible diseñar una línea de producción eficiente sin entender profundamente qué significa un producto de calidad, buenas pruebas y un despliegue seguro. Lo mismo ocurre hoy para las fábricas de software.
Algunos trabajos, como la primera versión de una función novedosa o la resolución de bugs poco comunes en producción, permanecen manuales hasta que sean definidos y estandarizados. También ciertas decisiones estratégicas, como qué desarrollar, interpretaciones de requerimientos ambiguos, balance entre velocidad y riesgos, y responsabilidad sobre lanzamientos, son exclusivamente humanas.
El proceso óptimo marca la diferencia, no solo el modelo de agente
La irrupción de agentes generadores de código ha nivelado el acceso a modelos avanzados para las organizaciones, pero los equipos que marcan ventaja son los que diseñan las mejores líneas de producción alrededor de ellos, con contratos entre agentes, controles humanos donde se necesita criterio y validación automática en cada cambio.
Esta transformación abre un nuevo capítulo para los ingenieros de software, ahora más orientados a la ingeniería de procesos. Herramientas como Signadot permiten dar a cada cambio su propia estación de pruebas, facilitando la construcción de estas nuevas fábricas de software modernas.
