Con agentes que escriben código, el cuello de botella ya no es teclear. Es decidir cuándo un cambio está listo. En un equipo tradicional esa decisión tiene dueño: la revisión de código, el QA, el visto bueno antes de desplegar. Cuando quien programa es un agente, esa figura no desaparece. Cambia de sitio.
Cuento cómo lo hago en GalopApp, mi side project, con una advertencia: es el sistema de un proyecto donde el riesgo lo asumo yo. No es una receta para cualquier entorno.
Yo decido al principio
Mi parte está antes. Itero varias veces con el coordinador hasta cerrar el alcance: qué se hace, qué queda fuera, qué significa «hecho» (Cerrar una buena «Definition of Done»). Con el alcance cerrado, el trabajo sigue solo hasta producción, a través de agentes y pipelines. He pulido los system prompts de todos los agentes implicados, y ahí pongo mi esfuerzo: en definir bien el encargo y las instrucciones, no en aprobar cada cambio al final.
Pero no es un agente suelto
Que yo no apruebe al final no significa que nadie lo haga. Las reglas del repositorio fijan una definición de hecho con cinco puntos: tests del backend en verde, migración de base de datos si se toca el modelo, frontend que compila y pasa el lint, y dos puertas. En la primera, un revisor independiente audita el diff desde seguridad. En la segunda, otro da la aprobación de calidad, y solo ese puede mergear. El merge a la rama principal es lo que despliega: un workflow lo lleva solo a producción. Un cambio que se modifica vuelve a pasar las dos puertas, porque código nuevo es código sin revisar.
Quien programa no se aprueba a sí mismo, y yo no estoy en el último paso. Y si un cambio no converge tras varios rechazos, el flujo para y me lo escala, en lugar de insistir.
Las reglas salen de errores
Esas reglas no nacieron de un diseño elegante. El propio repositorio guarda una lista de errores ya cometidos para no repetirlos. Uno me gusta especialmente porque desmonta una confianza ingenua en los tests: dos cambios añadieron modelos de datos sin su migración. La suite entera pasaba en verde, porque usa una base de datos distinta a la de producción, y las tablas nunca se crearon. La conclusión quedó escrita como regla: verde en tests no es lo mismo que correcto en producción.
Otro caso reciente: una política que debía vivir en un solo sitio acabó en dos listas, y cada puerta daba por buena la red de la otra. Al medirlo, once de los veinte términos bloqueados en una se escapaban por la otra. La lección es la misma que con los tests: un control que cree que otro cubre lo que no cubre es peor que no tener ninguno.
Por qué me lo puedo permitir
Es un side project. Si algo falla en producción, el coste es mío y lo arreglo yo. Esa es una decisión de riesgo consciente. Con clientes, datos sensibles o regulación, probablemente querrás más intervención humana en el punto final, y eso es razonable.
No es una recomendación general. Mi equilibrio funciona porque lo que está en juego es poco y porque las puertas están escritas y separadas de quien programa. Quitar una de las dos cosas cambiaría el cálculo. Pero a día de hoy, reviso cada vez menos código a mano, y principalmente tests.
Lo que me quedo
La respuesta a la pregunta del título no es una persona ni una herramienta. Es una Definition of Done que se escribe antes, que se comprueba por alguien distinto a quien programó, y que se corrige cada vez que falla. Yo me quedo con la parte que no se delega bien: decidir qué se quiere.