Cómo gestionar PRs generadas por agentes en la revisión de código

Code review en equipos con agentes — qué cambia cuando el 60% del código no lo escribió un humano

Tiempo estimado de lectura: 4 min

• La revisión pasa de comprobación sintáctica a auditoría semántica y arquitectónica.
• El volumen y la fatiga de revisión aumentan; los humanos agregan criterio, no velocidad pura.
• Reglas operativas: prompts en PR, PRs pequeñas, tests deterministas y gates automáticos.
• Responsabilidad y formación deben definirse: ownership legal y mentoría combinada hombre-máquina.

Code review en equipos con agentes — qué cambia cuando el 60% del código no lo escribió un humano: esa frase ya debería sonar como una alarma. Si tu repositorio empieza a parecer una fábrica de PRs escritas por LLMs, no estás ante una mejora de productividad: estás ante un cambio de paradigma en la gobernanza del código.

El problema no es que el código generado sea malo. Es que es convincente. Y lo convincente pasa sin pedir permiso por la puerta de revisión.

Resumen rápido (lectores con prisa)

Qué es: Código producido por agentes (LLMs/agentes automatizados) que entra al repositorio vía PR.

Cuándo usarlo: Cuando buscas acelerar tareas repetibles, con controles automáticos y ownership claro.

Por qué importa: Cambia la revisión de sintaxis a auditoría de dominio, coherencia y riesgos.

Cómo funciona: Implementa gates automáticos, exige prompts en PRs, fragmenta PRs grandes y usa agentes como primer filtro.

Cuando la mayoría del código viene de agentes

Cuando la mayoría del código viene de agentes, la revisión deja de ser corrección ortográfica. Pasa a ser auditoría semántica, arquitectónica y de riesgos. La prioridad deja de ser “¿compile?” y pasa a ser “¿esto respeta nuestro dominio, nuestras abstracciones y nuestras reglas de operación?”.

A partir de ahí, todo cambia: volumen de PRs, tipos de errores dominantes, responsabilidad técnica y los criterios mínimos para aceptar cambios.

Los cuatro efectos inmediatos que verás

1. Fatiga de revisión a escala

Un agente puede abrir varias PRs en minutos. Leer código cuesta. El riesgo real es aprobar por inercia. No es moral; es una falla de proceso.

2. Ruido ejecutivo: syntactic correctness ≠ business correctness

Linters y tipado son una alfombra. Bajo ella puede haber duplicaciones, incompatibilidades con contratos internos o decisiones de diseño rotas.

3. Pérdida de contexto global

Los agentes funcionan bien en ámbitos locales. Fallan cuando hay decisiones históricas, utilidades compartidas o patrones no escritos. El repo se fragmenta si nadie vigila la coherencia.

4. Reasignación del valor humano

El humano deja de competir en velocidad y pasa a proporcionar criterio: editor, arquitecto y protector de deuda técnica.

Reglas prácticas para revisar PRs generadas por IA

Obligatoriedad del prompt en la PR

Cada PR que provenga de un agente debe incluir: el prompt completo, parámetros del agente (temperature, model, herramientas usadas) y, si aplica, los snippets intermedios que el agente evaluó. Sin esto, rechaza la PR.

PRs pequeñas y cambiables

Límite duro: <400 líneas por PR. Si un agente genera más, fracciona. Revisa unidades pequeñas y reusables, no borradores monolíticos.

Pipeline que no negocia: tests + validadores automáticos

Nada pasa si no hay tests deterministas. Añade validadores automatizados (SAST, DAST, complejidad ciclomática) y gates en CI que bloqueen merges hasta cumplir umbrales.

Agentes revisando a agentes (primer filtro)

Usa workflows (p. ej. n8n) para que un agente verificador haga la primera pasada: seguridad, duplicados, dependencias nuevas. Solo PRs filtradas llegan a humanos.

Código como contrato: exige integraciones con Code Owners

Que las áreas propietarias (backend, auth, shared-utils) deban aprobar cambios automáticos en su zona. No delegues ownership a un bot.

Criterios claros para aprobar o rechazar (chequeo rápido)

Aprueba manualmente si:

• Prompt incluido y comprensible.
• PR ≤ 400 líneas.
• Tests cubren casos límite relevantes.
• No introduce dependencias externas sin aprobación.
• Integra con abstractions/shared modules existentes.

Rechaza o solicita rework si:

• No hay prompt o está incompleto.
• Replica utilidades existentes.
• Falla validadores automáticos de seguridad o complejidad.
• No hay evidencia de decisión humana sobre trade-offs.

Riesgos no técnicos que debes tener en cuenta

Responsabilidad y ownership: una vulnerabilidad surgida de un output de IA que fue aprobada por cansancio recae en personas y procesos. Define legalmente quién firma cambios críticos.

Formación del equipo: si los juniors solo “pegotean” código generado, la curva de aprendizaje se aplana. Plan de mentoría obligatorio: revisiones combinadas hombre-máquina para formación.

Conclusión: el criterio gana peso

Si 60% del código viene de agentes, tu ventaja competitiva no estará en cuánto puedes generar, sino en cuánto puedes coordinar, auditar y dar criterio sobre ese output. El trabajo humano deja de ser teclear y pasa a ser decidir.

¿Quieres dejar de sufrir LGTM y convertir a tus agentes en productores útiles en lugar de ruido? Empieza por exigir prompts en cada PR, probar todo y automatizar el primer filtro con agentes. Si lo haces, ganarás velocidad sin perder control.

Apúntate a la newsletter de Dominicode para recibir plantillas de prompts, ejemplos de pipelines en n8n y una checklist lista para aplicar mañana.

Dominicode Labs

Si trabajas con automatización, IA aplicada, n8n, agentes o workflows, puedes encontrar recursos y ejemplos prácticos en Dominicode Labs. Es una continuación lógica para plantillas de prompts y pipelines aplicables de inmediato.

FAQ

• ¿Qué debe incluir el prompt en la PR?
• ¿Qué hacer con PRs grandes generadas por agentes?
• ¿Qué gates automáticos son necesarios?
• ¿Cómo se implementan agentes revisando a agentes?
• ¿Quién es legalmente responsable de cambios críticos?
• ¿Cómo formar a los juniors en equipos que usan IA?