Cómo organizamos agentes de IA para entregar software con evidencia y control

Un equipo pide automatizar la recepción de facturas. Parece una tarea simple: leer un correo, extraer un PDF y crear un registro. En cuanto se mira el proceso real aparecen preguntas: ¿qué buzón está autorizado?, ¿cómo se reconoce un duplicado?, ¿qué ocurre si el proveedor no coincide?, ¿quién aprueba un importe dudoso?, ¿qué evidencia debe conservarse para explicar el resultado?

Un agente puede escribir código antes de que esas preguntas se respondan. Entonces la velocidad de implementación se convierte en retrabajo. En Eximus estamos organizando el uso de agentes alrededor de un flujo más explícito: primero evidencia y requisitos, luego una especificación revisable, una tarea acotada, pruebas, pull request y feedback. El objetivo es que cada cambio se pueda entender y continuar, aunque cambie la persona o el modelo que participa.

La especificación es un contrato de trabajo, no un documento ceremonial

Llamamos a este enfoque desarrollo guiado por especificaciones (Spec-Driven Development). No significa escribir un documento largo para cada ajuste. Significa que, antes de construir, el equipo aclara el comportamiento observable y la evidencia que lo justifica.

Para el ejemplo de facturas, una especificación útil diría: qué correos entran al flujo; cómo se identifica una factura ya procesada; qué campos se extraen y con qué nivel de confianza; qué datos se contrastan con el proveedor; cuándo el sistema prepara una propuesta y cuándo la persona debe decidir. Los criterios de aceptación incluyen los casos difíciles: PDF ilegible, importes discordantes, webhook repetido y fallo temporal del sistema externo.

También deja claras las no metas. «Extraer datos» no autoriza al agente a aprobar una factura, conciliar un movimiento bancario o enviar una comunicación externa. Esa frontera hace posible delegar implementación sin delegar una decisión de negocio que el proyecto no ha tomado.

El recorrido de una entrega

Recorrido conceptual: evidencia autorizada → requisitos y especificación → revisión humana → WI ejecutable con responsable → código y pruebas → gates técnicos → PR y revisión humana. Si faltan decisiones, se vuelve a la evidencia; si falla un gate, se corrige el WI; el feedback del PR puede actualizar los requisitos. Los controles concretos dependen del riesgo del cambio.

1. Evidencia. Reuniones, documentos, comportamiento existente y restricciones se registran con su origen. Una afirmación del agente no sustituye la fuente.
2. Requisitos. Se distingue hecho confirmado, interpretación propuesta y decisión pendiente. Si algo afecta alcance o responsabilidad, se resuelve antes de construir.
3. Especificación. Se define el resultado esperado, los escenarios de error, dependencias, criterios de aceptación y lo que queda fuera.
4. Build readiness. Se comprueba si existe una superficie técnica identificable, un plan de pruebas, permisos suficientes y una vía para revertir el cambio. Si la incertidumbre es alta, el siguiente paso puede ser una investigación acotada.
5. WI ejecutable. El trabajo se vincula a una Story o un Bug con responsable y estado visibles. Se crea una Task cuando separa trabajo real e independiente bajo ese WI. El agente toma una unidad asignada; una conversación sin dueño no autoriza por sí sola una modificación del repositorio.
6. Construcción y gates. Se implementa el slice, se ejecutan pruebas pertinentes y se registran resultados. Un pipeline verde demuestra que pasaron ciertos controles; no demuestra aceptación funcional por parte del negocio.
7. PR y feedback. La revisión verifica el cambio y su evidencia. Una observación vuelve a requisitos o implementación según su causa, sin perder el vínculo con la decisión original.

Claude, Codex y la fuente de verdad

Claude y Codex pueden ayudar a leer material, proponer una especificación, implementar una tarea o revisar una entrega. El rol se asigna por tarea y capacidad, no como una promesa de que un modelo concreto hace siempre una etapa. La Story, el Bug o la Task que corresponda en Azure DevOps, el repositorio, los documentos aprobados y los resultados de pruebas son los artefactos que el equipo puede inspeccionar. El chat del agente es contexto de trabajo, no el único registro del proyecto.

La coordinación entre agentes exige una regla sencilla: una unidad de trabajo tiene un propietario activo y una superficie de cambio declarada. Cuando dos tareas necesitan editar el mismo módulo o contrato de datos, se secuencian o se acuerda una integración explícita. La paralelización sin ese control suele convertir el supuesto ahorro en conflictos de merge y decisiones inconsistentes.

El checkpoint permite continuar sin repetir la conversación

Un WI ejecutable no termina con «trabajé en esto». Su checkpoint deja el identificador del requisito, las fuentes consultadas, el alcance tocado, el commit o PR, los comandos de prueba, los resultados, las decisiones pendientes y el siguiente paso. Si una prueba falla, el registro explica cómo reproducirla. Si el cambio se pausa, otro participante puede saber dónde empezar sin pedir al agente que vuelva a narrar toda la sesión.

No todo el material de trabajo debe circular sin límites. Las fuentes autorizadas, los secretos, los datos personales y los permisos deben respetar el contexto del proyecto. Una transcripción puede servir para identificar un requisito, pero no debe copiarse completa al PR si contiene información que el revisor no necesita. La trazabilidad consiste en conservar referencias y decisiones útiles, no en duplicar indiscriminadamente los datos.

Consideremos otra vez la factura: el agente implementa la lectura y la prueba de un adjunto válido. El gate detecta que el mismo mensaje, procesado dos veces, produce dos registros. El cambio vuelve al WI ejecutable con un caso reproducible. La especificación confirma que debe existir una clave de deduplicación. La nueva implementación pasa la prueba y el PR muestra tanto el caso normal como el duplicado. El sistema no ha «aprendido solo»: el equipo detectó un hueco, lo convirtió en comportamiento verificable y conservó la evidencia.

Controles proporcionados al riesgo

No todos los cambios necesitan el mismo proceso. Un texto de interfaz puede requerir una revisión visual y una prueba enfocada. Un ajuste que toca permisos, cálculos financieros o datos de clientes exige trazabilidad más completa: fuentes, reglas, pruebas negativas, responsable de aprobación y plan de reversa.

Hay tres decisiones que mantenemos separadas. El agente puede preparar una propuesta. Las pruebas y el pipeline pueden verificar condiciones técnicas. Una persona autorizada debe aceptar el comportamiento y decidir si el cambio puede avanzar o publicarse. Confundir estas tres cosas es una forma común de dar a una automatización más autoridad de la que realmente tiene.

El gate tampoco es una caja negra. Para cada tipo de cambio conviene saber qué comprobación bloquea el avance y quién puede resolverla: pruebas automatizadas para regresiones conocidas, validación visual cuando cambia una interfaz, revisión de seguridad cuando aparecen permisos o datos sensibles, y validación funcional para reglas de negocio. Si el entorno de pruebas está caído, el resultado es «no verificado», no «aprobado por defecto».

Qué ganamos y qué cuesta

El flujo añade trabajo al principio: aclarar requisitos, escribir escenarios y dejar evidencia. Compensa cuando hay varios sistemas, cambios frecuentes, operación crítica o personas que deben retomar trabajo de otros. Para una corrección pequeña y aislada, la especificación puede caber en el mismo WI. Para una integración con excepciones y decisiones de negocio, necesita más detalle.

También cambia cómo medimos el resultado. El número de líneas de código generadas dice poco. Importa el tiempo desde una solicitud clara hasta una entrega revisable, los cambios devueltos por requisitos ambiguos, la proporción de Tasks con pruebas y evidencia, los defectos posteriores y el tiempo que tarda otra persona en continuar una entrega. Todavía no presentamos cifras públicas de mejora para este flujo.

Por dónde empezar

Escoge un flujo con un problema visible y límites claros. Documenta tres o cuatro escenarios reales, define quién aprueba, delimita un WI ejecutable pequeño y mide qué dudas aparecieron antes y después del PR. Si el primer ciclo deja una especificación que alguien puede discutir, una prueba que reproduce el comportamiento y un historial que permite explicar la decisión, ya existe una base para ampliar el uso de agentes con criterio.

¿Tu equipo puede recorrer un cambio desde el pedido original hasta las pruebas y la decisión de publicarlo? Conversemos sobre un primer flujo de agentes con trazabilidad.