Una agentic factory es una fábrica de software donde agentes de inteligencia artificial analizan, construyen, prueban y entregan trabajo real, dentro de un entorno con contexto, herramientas, controles y aprobaciones humanas. En ConnectIA 2026, Diego de Fuentes, CTO de GeneXus Consulting, contó cómo construimos la nuestra durante este año: qué decidimos, qué probamos y qué tuvimos que corregir en el camino.
TL;DR: la fábrica que se viene en 5 ideas
- Un buen modelo no alcanza: hacen falta herramientas, contexto y un harness para operar de verdad.
- Un desarrollo nuevo, una migración y un bug necesitan recorridos distintos sobre una base común.
- Los agentes ya trabajan desatendidos, con objetivos completos y monitoreo externo.
- Las personas aprueban la especificación, el plan y el merge: el agente propone, una persona decide.
- Las evaluaciones mejoran el propio proceso, con cambios revisados por un AI Engineer.
La charla se llamó «La fábrica que se viene: de la Software Factory a la Agentic Factory» y se presentó el 31 de octubre de 2026 en ConnectIA, en el LATU (Montevideo), un evento del que GeneXus Consulting fue sponsor principal. No fue una clase sobre agentes ni un ranking de modelos, sino la historia reciente de cómo cambiamos nuestra manera de construir software para clientes. Este artículo recorre esa historia, mes a mes, y los dos ejemplos que se mostraron en vivo.
¿Qué cambió en enero de 2026?
Al volver de las fiestas, el 6 de enero, las herramientas que ya conocíamos resolvían actividades completas con una calidad muy distinta. Los anuncios habían llegado antes: Claude Opus 4.5 el 24 de noviembre de 2025 y GPT-5.2-Codex el 18 de diciembre, con más alcance en refactors, migraciones y tareas largas.
“La carrera de modelos era relevante, pero para nosotros lo importante era otra cosa: qué trabajo podíamos confiarles.”
— Diego de Fuentes, CTO de GeneXus Consulting
La pregunta fue práctica: ¿estaba nuestro proceso preparado para trabajar con agentes que resolvían tareas completas? No arrancábamos de cero. Teníamos herramientas propias para que la IA consultara una Knowledge Base de GeneXus, leyera objetos y entendiera dependencias. Lo que todavía costaba era generar y modificar objetos con la precisión que exige un proyecto real.
Con ese diagnóstico, el plan del primer trimestre tuvo dos líneas que avanzaron juntas:
- Capacidad técnica: mejorar el tooling para leer, editar y generar objetos GeneXus de forma confiable.
- Forma de trabajar: construir nuestro propio AI-DLC, un ciclo de desarrollo pensado para agentes, con etapas, criterios de salida, validación y entregables.
El AI-DLC ordenó el trabajo en seis pasos: entender el pedido, analizar y especificar, diseñar la solución, construir, probar y verificar, y entregar evidencia. Todo sobre un contexto compartido, con criterios de calidad y aprobaciones humanas. La idea no era producir una montaña de documentos, sino un proceso que otra persona o agente pudiera retomar y verificar.
“Podíamos tener el modelo más potente del mercado y, aun así, si le faltaban contexto, un proceso de trabajo y una manera de validar, no íbamos a obtener una operación repetible.”
— Diego de Fuentes, CTO de GeneXus Consulting
¿Qué mostró el primer piloto con proyectos reales?
Mientras diseñábamos el proceso, los modelos seguían avanzando: entre febrero y abril llegaron sesiones paralelas, más capacidad de código y herramientas, y rutinas que se ejecutan por agenda o evento. Algunas ayudas manuales que armábamos quedaban cortas a las pocas semanas.
En mayo llevamos el AI-DLC a un equipo que trabajaba en varios proyectos de verdad, con incidentes, código existente y compromisos con clientes. El resultado más interesante no fue una cifra de productividad. Le dimos un problema al agente y volvió con una solución: analizaba, cambiaba el código, ejecutaba y verificaba dentro de la misma tarea. Si algo fallaba, ajustaba y volvía a verificar, sin que una persona dirigiera cada paso.
El piloto también dejó una limitación a la vista: no todos los proyectos pueden seguir un único flujo rígido.
| Tipo de proyecto | Recorrido |
|---|---|
| Desarrollo nuevo | Necesidad, diseño, construcción y pruebas. |
| Migración | Inventario, conversión, paridad y aceptación. |
| Mantenimiento | Reproducir, diagnosticar, corregir y probar la regresión. |
Por eso compartimos capacidades, herramientas y controles, pero el grafo de trabajo (el mapa de qué agente o persona hace cada paso, en qué orden y por dónde vuelve si algo falla) cambia según el proyecto.
¿Qué es el harness y por qué importa más que el modelo?
El harness es el entorno que hace posible que un agente trabaje sin pedir ayuda todo el tiempo: contexto, herramientas, estado persistente, permisos, un entorno de ejecución y formas de verificar sus resultados. El concepto ya existía en la industria. Lo que cambió en julio fue nuestro foco: empezamos a mirar todas esas piezas como un sistema integrado.
Con más adopción apareció otra necesidad: entender cómo se usaba la IA. Al principio liberamos licencias a demanda. Después desarrollamos una aplicación interna que muestra planes, consumo de tokens o créditos, uso por chat o CLI, agentes utilizados, patrones de prompts y actividad diaria. La conclusión fue clara: consumir más no equivale a entregar más valor. El paso siguiente es cruzar uso con calidad y resultados del delivery.
Cuanto más trabajo se delega, más importa saber bajo qué condiciones ocurre. El gobierno de los agentes responde cuatro preguntas:
- Acceso: ¿qué información y herramientas puede utilizar?
- Límites: ¿qué puede hacer solo y qué requiere aprobación?
- Costo: ¿cuánto consume una ejecución?
- Evidencia: ¿qué cambió, qué probó y qué quedó registrado?
¿Cómo trabajan los agentes desatendidos?
En septiembre dimos otro salto: pasar de tareas cortas a objetivos completos. Un agente desatendido recibe un goal, organiza su ejecución, continúa durante mucho más tiempo y se detiene cuando termina o cuando aparece un bloqueo. Ahí entraron con fuerza los workflows, los grafos y los DevAgents.
El monitoreo es externo al agente. No hace falta mirar su pantalla, pero sí saber qué está haciendo, qué logró y cuándo necesita a una persona. Ese mismo mes, el mercado empezó a ofrecer estas capacidades como parte de sus plataformas: sesiones en la nube, agentes de larga duración y secuencias de agentes con pasos revisables.
¿Qué hace hoy nuestra fábrica de software con agentes?
En octubre, los agentes participan en muchas actividades del proceso, y varias ya se ejecutan sin intervención continua:
- Desarrollo.
- Migraciones.
- Análisis de bugs.
- Reverse spec: reconstruir la especificación de un sistema existente.
- Testing y revisión.
- Wikis y documentación.
- Informes y avances.
- Presentaciones.
Lo importante no es el catálogo de agentes, sino cuánto trabajo puede delegarse, cómo se verifica y cómo se integra en procesos con responsables claros. Todos los recorridos comparten el mismo harness, con evidencia, evals y controles humanos para decidir y mitigar riesgos. No es una fábrica terminada de punta a punta: es una fábrica que sigue madurando, y hoy ya está detrás de nuestros proyectos de desarrollo de software a medida.
Ejemplo 1: ¿cómo resuelve un incidente la red de agentes?
Un solo pedido puede involucrar varios agentes y tres decisiones humanas. Así se recorre un incidente que entra en Mantis o Redmine:
- Análisis: el agente analizador consulta el ticket y su historial mediante MCP, y revisa el código y sus dependencias.
- Solución: el agente de solución recupera especificaciones anteriores de Git y de la KB GeneXus, y redacta la spec con su plan de pruebas.
- Primera aprobación humana: una persona valida el alcance y el plan de pruebas.
- Planificación: un agente divide el cambio en units y otro arma el plan con orden, dependencias y criterios de éxito.
- Segunda aprobación humana: una persona da el OK al plan de ejecución.
- Ejecución desatendida: el DevAgent trabaja con tres generadores de código y tres testers en ramas paralelas. Si una prueba falla, solo esa rama corrige.
- Tercera aprobación humana: una persona revisa el merge request y aprueba el merge consolidado.
- Entrega: el agente DevOps ejecuta controles de seguridad, paquetes y calidad, y el pipeline despliega la solución en un ambiente de test.
Cada agente registra evidencia y evals, y el ticket queda actualizado con la trazabilidad de la entrega. El nivel de control puede variar con el riesgo: no hace falta tratar igual un texto de pantalla que un cambio en autenticación o en datos sensibles.
“No buscamos una automatización sin dueño; buscamos trabajo delegado con contexto y controles claros.”
— Diego de Fuentes, CTO de GeneXus Consulting
Ejemplo 2: ¿cómo se migra un sistema legacy con un DevAgent desatendido?
El segundo grafo mostró una migración de sistemas legacy con IA. Antes de firmar, los agentes preparan los insumos del cliente, miden la complejidad y arman una propuesta con tres destinos posibles. Ya en el proyecto, preparan el origen, acuerdan una estrategia y reconstruyen la especificación de cada entrega. Hay tres decisiones humanas: el destino, la estrategia y la spec.
Lo que cambia después de aprobar la spec es el objetivo. El DevAgent recibe un goal completo, terminar todas las especificaciones aprobadas de esa entrega, y no pide permiso por cada unidad de trabajo. Planifica units y bolts, construye, prueba, evalúa y repite hasta cumplir el alcance, o se detiene y escala si encuentra un bloqueo que no puede resolver. Un monitor externo observa el progreso, los reintentos y las alertas.
Un build en verde no equivale a una migración funcionalmente correcta. Por eso distinguimos verificación estructural, paridad y aceptación.
¿Cómo mejora el proceso entre una ejecución y otra?
Hay dos ciclos de mejora. Dentro de una ejecución, el loop es corto: ejecutar, evaluar con tests y criterios, y corregir con otro intento o una ruta nueva. Entre ejecuciones, un agente de mejora usa las trazas, los tests y los evals para detectar fallas recurrentes y proponer cambios a las skills, las instrucciones, las herramientas o los workflows.
Esas propuestas las revisa un AI Engineer, que decide qué incorporar según el riesgo. Así, la próxima ejecución aprovecha una mejora del harness y no solo un arreglo puntual. Es mejora continua asistida por agentes y gobernada por personas: el sistema no se cambia solo.
¿Qué aprendimos al construir una agentic factory?
Son aprendizajes de trabajo real, no una metodología universal:
- Probar con proyectos reales. La demo alcanza para entusiasmarse; el caso real muestra lo que falta.
- Preparar las herramientas. Un buen modelo necesita contexto, accesos, tooling y harness.
- Validar el comportamiento. Compilar no garantiza que el sistema haga lo esperado.
- Gobernar e incorporar un ciclo de mejora. Evaluaciones, monitoreo, revisiones humanas y mejoras reutilizables del harness.
Y el proceso que diseñamos este año seguramente no sea el del próximo.
¿Qué viene después para la fábrica de software?
Las tendencias más recientes amplían el foco: menos detalle prescrito y más resultados verificables. Cuatro líneas marcan lo que viene:
- Goal-driven workflows: el agente recibe un resultado a lograr y organiza las acciones necesarias.
- Grafos y trabajos largos: especialistas coordinados, con estado, reintentos y continuidad.
- Verificación y gates por riesgo: la evidencia y el riesgo determinan dónde verificar y pedir aprobación.
- Harness con ciclos de automejora: un agente propone cambios a skills y workflows, y un AI Engineer los revisa e incorpora.
Las especificaciones siguen siendo útiles, pero su profundidad depende del trabajo y del riesgo.
“La pregunta con la que me gustaría cerrar es qué partes del proceso tenemos que seguir prescribiendo y cuáles podemos confiar al agente, siempre que pueda demostrar que cumplió el objetivo.”
— Diego de Fuentes, CTO de GeneXus Consulting
La charla cerró con tres decisiones para avanzar con personas y agentes:
- Empezar ahora, aprender y mejorar: elegir un caso acotado, con supervisión y límites claros, y convertir cada experiencia en una mejora del método compartido.
- Gestionar personas y agentes: definir objetivos, decidir qué delegar y evaluar los resultados con evidencia. Seguimos siendo responsables.
- Adaptarnos y evolucionar: la forma de trabajar en IT está cambiando, y hay que revisar cómo trabajamos e incorporar lo que aprendemos.
Preguntas frecuentes
1. ¿Qué diferencia hay entre una fábrica de software tradicional y una agentic factory?
En una fábrica de software tradicional, las personas ejecutan cada etapa del desarrollo. En una agentic factory, los agentes de inteligencia artificial analizan, construyen, prueban y entregan dentro de un harness común, y las personas definen objetivos, aprueban los puntos de riesgo y evalúan los resultados con evidencia.
2. ¿Qué es un harness para agentes de inteligencia artificial?
Es el entorno que permite a un agente trabajar de forma verificable: contexto, herramientas, estado persistente, permisos, un entorno de ejecución y formas de comprobar sus resultados.
3. ¿Dónde intervienen las personas si los agentes trabajan desatendidos?
En las decisiones: aprueban la especificación y el plan de pruebas, el plan de ejecución y el merge request. También supervisan con monitoreo externo y revisan las mejoras que propone el agente de mejora antes de incorporarlas.
Si estás evaluando por dónde empezar, te puede servir nuestra guía para priorizar casos de uso de inteligencia artificial y nuestras Soluciones de Inteligencia Artificial para Empresas.
Próximo paso
Si quieres llevar agentes de inteligencia artificial al desarrollo y mantenimiento de tus sistemas, conversa con nuestro equipo.
-
Siguiente
¿Cómo priorizar ...
