Agentes de IA
AI Factory: cómo funciona una factoría de software con agentes
Qué es una AI Factory de software, cómo combina agentes, pruebas y controles, y cuándo compensa. Un ejemplo de reservas explica sus ventajas y límites.
Del encargo al cambio publicado
Una AI Factory de software organiza el trabajo de los agentes dentro de un proceso que puede recibir tareas, implementar cambios, comprobarlos y publicarlos con controles definidos. El objetivo es reducir la intervención continua sin perder de vista qué se está construyendo y cómo saber si funciona.
El nombre software factory pone el foco en ese recorrido completo, incluida la observación de lo que ocurre después del despliegue. No designa un framework ni exige una plantilla fija de agentes.
Un ejemplo con una web de reservas
Imagina una web que permite pedir una estancia cuya salida es anterior a la entrada. La tarea empieza definiendo la regla: la salida debe ser posterior y la reserva debe incluir al menos una noche.
Un agente consulta el código y las decisiones del proyecto, prepara el cambio en un entorno aislado y añade pruebas. Entrar un viernes y salir el jueves anterior debe rechazarse. Salir el sábado debe aceptarse. Entrar y salir el mismo viernes tampoco cumple la regla.
La comprobación tiene que cubrir el calendario y el servidor. Corregir solo la pantalla dejaría la validación incompleta. Después vendrían la revisión del cambio, la aprobación que corresponda y una comprobación tras publicar. Este recorrido es una propuesta de diseño, no una prueba de un sistema concreto.
Las piezas que hacen posible delegar
Necesitas contexto accesible: arquitectura, reglas de negocio y decisiones vigentes. Una memoria útil permite encontrar esa información sin cargar todo el histórico en cada petición. Guardar una decisión equivocada también puede propagar el error, así que esa documentación necesita mantenimiento.
Conviene reservar código convencional para los pasos conocidos, como ejecutar pruebas o comprobar permisos, y usar agentes donde haya que interpretar información o decidir cómo implementar. Los blueprints de Stripe combinan ambos tipos de ejecución dentro del mismo flujo.
Cada tarea debería conservar su entrada, versión del código, resultados y estado. También necesita un límite de tiempo e intentos y una salida cuando no pueda continuar. Repetir indefinidamente hasta que un modelo diga que todo está bien no ofrece una garantía de corrección.
Qué ganas y qué te cuesta
La ventaja más clara es poder delegar recorridos completos y concentrar la atención en requisitos, decisiones y excepciones. Las tareas independientes pueden avanzar en paralelo, siempre que sus entornos y su integración estén preparados para ello.
A cambio, hay más piezas que mantener. Separar cada responsabilidad en otro agente puede duplicar contexto, consumir más y perder información en los traspasos. Un revisor especializado tiene sentido si aporta una comprobación útil; no hace falta reunir un comité de modelos para cada cambio.
Los tests escritos por el propio agente tampoco bastan por sí solos. Conviene conservar casos de aceptación que comprueben el comportamiento esperado de forma independiente. En la reserva, importa que se rechacen las fechas inválidas, aunque el agente haya encontrado otra manera de dejar sus pruebas en verde.
¿Es ya el estándar en octubre de 2026?
Hay implementaciones públicas documentadas, pero no una receta común que permita llamar estándar universal a este enfoque. Stripe describe cambios generados por agentes y revisados por personas. StrongDM plantea desarrollo sin revisión humana del código. Ambas experiencias caben bajo la idea de factoría y mantienen decisiones distintas sobre la autonomía.
Un trabajo presentado el 28 de septiembre de 2026 informa de despliegues en decenas de repositorios de Microsoft, centrados en sistemas de datos y tareas con objetivos medibles. Es evidencia de uso en un ámbito concreto, no de que todos los equipos hayan adoptado la misma arquitectura.
Empezar con una tarea que puedas comprobar
Para empezar, elegiría una clase de cambios acotada, prepararía sus casos de aceptación y mediría cuánto trabajo humano sigue necesitando. El coste por resultado correcto y las regresiones dicen más que el número de agentes o de PR generadas.
Ampliaría la autonomía cuando esa evidencia lo justifique. Los permisos para publicar o modificar recursos deben estar impuestos por el sistema; una valoración de riesgo del modelo puede ayudar, pero no debería ser la única barrera. La factoría aporta valor cuando puedes delegar con criterios claros y recuperar el control cuando algo falla.