La Fábrica de Soluciones

Volver a los casos

Caso FIT · PAT-09

Desarrollo con agentes bajo controles que bloquean (DEV agéntico)

Caso de éxitoEmpresa de servicios digitales, anonimizada

Ejecutado con un cliente; los detalles se comparten en la sesión de diagnóstico.

Contexto

Ocurre en equipos que adoptan agentes de código en varios repositorios a la vez. Con el contexto lleno, el agente olvida correr pruebas o seguir convenciones, y un control que revisa un texto escrito por el propio agente no prueba nada. Sin una regla común, cada repositorio termina con su propia versión del proceso.

El reto

El equipo quería que los agentes de código aceleraran el trabajo sin saltarse pruebas ni convenciones y sin que cada repositorio terminara con reglas distintas.

Cómo se resolvió

Cada repositorio tiene un arnés con un motor determinista. El motor lleva el estado de la especificación del ticket y exige evidencia de prueba fallida antes de implementar y aprobada después. Los controles corren en tres capas: antes de cada acción del agente, en cada commit (lo haga quien lo haga) y en la integración continua. Lo que cambia entre repositorios vive en un perfil por repositorio, no en el arnés.

Roles

  • Desarrollador que trabaja el ticket
  • Revisor que aprueba la integración
  • Responsable técnico de las reglas del repositorio

Antes y después

Antes

Cada desarrollador aplica las reglas según su criterio

Con IA

El arnés bloquea cualquier cambio que no cumpla las reglas

Capas de control

Capas de control: Desarrollo con agentes bajo controles que bloquean (DEV agéntico)Capas de control en orden. Entrada. 1. Antes de cada acción del agente: Que el agente no cambie a mano el estado de la especificación. 2. En cada commit: Lint, tipos, pruebas y evidencia de prueba fallida y luego aprobada. 3. En la integración continua: Especificación aprobada, evidencia del motor y reglas que bloquean. 4. Perfil leído desde la rama base: Que un cambio no pueda reescribir sus propias reglas. Si no cumple una capa, se detiene ahí. Sale solo lo que cumplió todas las capas.EntradaSi no cumpleAntes de cada acción del agenteQue el agente no cambie a mano el estado de la especificaciónSe detieneEn cada commitLint, tipos, pruebas y evidencia de prueba fallida y luegoaprobadaSe detieneEn la integración continuaEspecificación aprobada, evidencia del motor y reglas que bloqueanSe detienePerfil leído desde la rama baseQue un cambio no pueda reescribir sus propias reglasSe detieneSale solo lo que cumplió todas las capas
Capas de control: Desarrollo con agentes bajo controles que bloquean (DEV agéntico)Capas de control en orden. Entrada. 1. Antes de cada acción del agente: Que el agente no cambie a mano el estado de la especificación. 2. En cada commit: Lint, tipos, pruebas y evidencia de prueba fallida y luego aprobada. 3. En la integración continua: Especificación aprobada, evidencia del motor y reglas que bloquean. 4. Perfil leído desde la rama base: Que un cambio no pueda reescribir sus propias reglas. Si no cumple una capa, se detiene ahí. Sale solo lo que cumplió todas las capas.EntradaSi no cumple, se detieneAntes de cada acción delagenteQue el agente no cambie a mano elestado de la especificaciónEn cada commitLint, tipos, pruebas y evidenciade prueba fallida y luegoaprobadaEn la integración continuaEspecificación aprobada,evidencia del motor y reglas quebloqueanPerfil leído desde la ramabaseQue un cambio no pueda reescribirsus propias reglasSale solo lo que cumplió todas lascapas

Cómo funciona

  1. La especificación del ticket avanza por estados fijos, de bloqueado a aprobado, y solo el motor puede cambiarlos.
  2. Por cada criterio, el motor exige ver la prueba fallar antes de implementar y pasar después, y guarda una foto del código en cada momento.
  3. Antes de cada acción del agente, un hook impide cambiar a mano el estado de la especificación.
  4. En cada commit, lo haga una persona o un agente, corren lint, tipos, pruebas y reglas sobre las líneas nuevas.
  5. La integración continua repite los controles y rechaza especificaciones sin aprobar o sin evidencia del motor.
  6. Lo que cambia entre repositorios vive en un perfil, y las reglas se leen siempre desde la rama base.

Sistemas

  • Repositorio de código
  • Hooks de commit
  • Integración continua
  • Herramienta de gestión de tickets

Capacidades

  • Generación y ejecución de pruebas de software
  • Orquestación de agentes en tareas de varios pasos
  • Automatización con aprobación humana

Quién hace qué

Flujo de trabajo: Desarrollo con agentes bajo controles que bloquean (DEV agéntico)Flujo en 6 pasos, en carriles de personas, agentes de IA y sistemas. 1. Personas: Toma el ticket listo 2. Agentes de IA: Escribe prueba que falla 3. Agentes de IA: Implementa hasta que pasa 4. Sistemas: Hooks y commit validan reglas 5. Sistemas: Integración continua repite controles 6. Personas: Aprueba la integraciónPersonasAgentesde IASistemasToma elticketlistoEscribeprueba quefallaImplementahasta quepasaHooks ycommitvalidanreglasIntegracióncontinuarepitecontrolesAprueba laintegración
Flujo de trabajo: Desarrollo con agentes bajo controles que bloquean (DEV agéntico)Flujo en 6 pasos, en carriles de personas, agentes de IA y sistemas. 1. Personas: Toma el ticket listo 2. Agentes de IA: Escribe prueba que falla 3. Agentes de IA: Implementa hasta que pasa 4. Sistemas: Hooks y commit validan reglas 5. Sistemas: Integración continua repite controles 6. Personas: Aprueba la integraciónPersonaToma el ticket listoAgente de IAEscribe prueba que fallaAgente de IAImplementa hasta que pasaSistemaHooks y commit validan reglasSistemaIntegración continua repite controlesPersonaAprueba la integración

Criterios de éxito

IndicadorCómo se mideResultado
Crecimiento de las pruebas automatizadas del repositorioCómo se mideNúmero de pruebas automatizadas en la rama base al integrar el arnés y después.Resultado medidoLas pruebas automatizadas pasaron de 1 archivo de pruebas a 1.729 pruebas.
Commits rechazados por los controles antes de llegar a revisiónCómo se mideConteo de bloqueos registrados por los hooks de commit y la integración continua, por semana.ResultadoSe mide en el piloto.
Criterios con evidencia de prueba fallida y luego aprobadaCómo se mideCriterios con marca de rojo y de verde del motor sobre el total de criterios del ticket.ResultadoSe mide en el piloto.
Cambios integrados que saltaron algún controlCómo se mideCommits en la rama base sin evidencia del motor o con verificación omitida, según auditoría mensual.ResultadoSe mide en el piloto.

Lecciones

  1. Pedirle al agente que corra las pruebas no basta: con el contexto lleno, las instrucciones se pierden, y solo un control que bloquea se cumple siempre.
  2. Las reglas se leen desde la rama base, nunca desde la rama del cambio; si no, un cambio puede fijar sus propias reglas.
  3. Un control que siempre está en rojo entrena al equipo a ignorarlo; antes de volverlo bloqueante hay que dejar en cero lo que ya existe.

Controles clave

Gestión de cambios de prompts, herramientas y modelos · Secretos y credenciales fuera del prompt · Cadena de suministro de modelos, librerías y conectores · Aprobación humana antes de acciones con efecto externo o irreversible

Implementación de referencia: Implementado con Claude Code, husky y GitHub Actions.

Quiero revisar esto con FIT: Felipe Arentsen · felipe.arentsen@factorit.com

FIT Labs · La Fábrica de Soluciones