Le pedí a otra IA que revisara mi método de trabajo con agentes
Trabajo con agentes de código siguiendo un método que tengo escrito en un documento: primero la especificación (SDD), después los tests (TDD) y el trabajo repartido entre subagentes que coordina un orquestador. Es el mismo método que explico en iadev y que apliqué para auditar código heredado. Lo uso con Claude Code.
Esta semana quise otra mirada: un modelo que no hubiera participado en escribirlo. Le di acceso al documento a ChatGPT Astra, a través del MCP de Documentador, y le hice dos preguntas.
Primera pregunta: analiza el método
La primera respuesta fue un análisis general. Le puso un 8,5 sobre 10 y valoró, entre otras cosas, que el conocimiento viva en el repositorio y no en la memoria del agente, el rojo confirmado antes de implementar, la propiedad exclusiva de ficheros entre subagentes y la regla de parar y preguntar cuando una solución tiene riesgo de rendimiento.
Después enumeró seis debilidades:
| Problema | Riesgo que le asignó | Qué recomendaba |
|---|---|---|
| El orquestador no revisa normalmente el código generado | Alto | Revisar los diffs, sobre todo en cambios críticos |
| No se exige comprobar el rendimiento | Alto | Benchmarks y límites de latencia, memoria y tamaño de respuestas |
| No hay una validación explícita de seguridad | Alto | Tests de autorización, secretos, inyección y dependencias |
| Ejecutar toda la suite en cada fase puede ser caro | Medio | Tests locales durante el TDD y la suite completa en CI |
| No se dice qué hacer con los tests intermitentes | Medio | Aislamiento, repetibilidad y una política para los tests inestables |
AGENTS.md y Documentador tienen instrucciones relacionadas | Medio | Decidir cuál prevalece si se contradicen |
El punto que más le chirriaba era una frase del documento:
El orquestador no relee el código del agente salvo sospecha; confía en informe + suite + su propia verificación E2E.
Su argumento: una suite puede pasar aunque el código meta deuda técnica, consultas ineficientes o vulnerabilidades. Proponía que otro agente, distinto del que implementa, revisara el diff al menos en los cambios de riesgo alto. Y añadía un cuarto rol a los que ya tengo: un validador independiente, encargado de las pruebas de extremo a extremo, el rendimiento y los criterios de aceptación.
Segunda pregunta: qué añadirías exactamente
Después le pedí que se centrara en lo importante y que me dijera qué texto añadiría. La respuesta fue más corta: dos secciones nuevas y tres cambios en lo que ya había.
- Revisión independiente y puertas de calidad. El orquestador clasifica cada cambio por riesgo antes de delegarlo, revisa el diff de cada fase y, si el riesgo es alto, encarga la revisión a otro agente. Un cambio no está terminado mientras no pase una lista de comprobaciones.
- Requisitos no funcionales en la spec. Rendimiento, seguridad y compatibilidad, con criterios medibles cuando el cambio los toca.
- El informe del subagente pasa a ser «su resumen operativo, no una garantía de calidad».
- El encargo a cada subagente incluye el riesgo de la tarea y la obligación de avisar de cualquier riesgo de seguridad, rendimiento o compatibilidad que vea, aunque no sea parte de la tarea.
- La receta de trabajo gana cuatro pasos: revisar el diff, revisión independiente en riesgo alto, comprobaciones no funcionales y registro de evidencias.
Y cerraba así:
No añadiría más agentes ni más fases obligatorias.
Es decir, al pedirle precisión, el validador independiente de la primera respuesta desapareció, y la revisión por otro agente quedó para los cambios de riesgo alto. Le pedí que añadiera esos cambios al documento tal cual.
Lo que ha cambiado en el método
La pieza central es la clasificación del riesgo, porque decide cuánto se revisa:
| Riesgo | Por ejemplo | Qué se exige |
|---|---|---|
| Bajo | Documentación, cambios visuales menores, refactorizaciones locales que no tocan contratos | Los tests afectados y revisar el diff |
| Medio | Endpoints nuevos, cambios de lógica, consultas, integraciones | La suite completa, revisar el diff y comprobar que funciona |
| Alto | Autenticación, permisos, migraciones, operaciones destructivas, concurrencia, integraciones externas críticas, cambios que pueden afectar al rendimiento | Además, revisión por otro agente y pruebas de los riesgos detectados |
La revisión depende de lo que puede romper el cambio, no de cuántas líneas toca. El agente revisor lee el diff y las specs, no modifica nada y entrega los hallazgos ordenados por gravedad, con fichero, línea y explicación. Los corrige el implementador y se repiten las comprobaciones afectadas.
La puerta de calidad pide, para dar algo por terminado: tests que cubran los criterios de la spec, la suite completa con el linter y el formateador, el diff revisado, la verificación de extremo a extremo, los requisitos no funcionales comprobados, ningún problema crítico o alto abierto y las evidencias registradas: órdenes ejecutadas, resultados, resumen de la revisión y pendientes. Si algo no se ha podido medir, el informe lo dice en vez de darlo por comprobado.
Lo que dejé fuera
No incorporé el resto de la primera respuesta: la política de tests intermitentes, mover la suite completa a CI, la regla de precedencia entre AGENTS.md y Documentador ni el cuarto rol. Quiero preservar la sencillez del método, y tal como está me está dando buenos resultados.
Dónde está
He llevado los cambios a iadev: la plantilla que se descarga trae ahora la clasificación del riesgo, la puerta de calidad y una sección de requisitos no funcionales en la spec, y los capítulos 3, 8 y 10 lo explican.
Todavía no he aplicado el método nuevo en un cambio real. Cuando lo haga, actualizaré este post con lo que haya encontrado la revisión.