Los agentes pueden iniciar trabajo y abrir PRs, pero la autoridad de merge no deberia diluirse. La productividad aparece cuando automatizas trabajo, no responsabilidad.
Los agentes de codigo ya no solo sugieren lineas dentro del editor. Pueden crear ramas, modificar varios archivos, ejecutar tests, abrir PRs y responder comentarios. Eso cambia el ciclo de desarrollo, pero no elimina la necesidad de gobernanza.
El cambio real. La investigacion reciente sobre PRs de agentes muestra una separacion importante: la iniciativa operativa puede pasar al agente, mientras la autoridad final de merge sigue siendo humana. Ese desacoplamiento es sano si el equipo lo diseña conscientemente.
Roles claros. Un PR de agente deberia declarar quien pidio el cambio, que objetivo tenia, que archivos toca, que pruebas corrio y que zonas quedan sin verificar. Si esa informacion no esta, el reviewer humano empieza en deuda. El agente puede ser autor operativo, pero el humano sigue siendo responsable de aceptar el cambio. La revision no debe convertirse en un sello rapido porque el diff "lo hizo la IA".
Politica de aprobacion. No todos los PRs necesitan la misma rigidez. Documentacion, tests aislados o refactors mecanicos pueden tener una ruta ligera. Cambios de permisos, pagos, autenticacion, datos o migraciones necesitan revision fuerte y, a menudo, owner humano explicito. Una politica util separa PRs por riesgo: bajo, medio y alto. El agente puede abrir todos, pero no todos deberian poder fusionarse con el mismo numero de checks.
