La IA en el ciclo de revisión de PR

Claude tanto da como recibe revisiones. Revisa los PR entrantes según las políticas de la organización y atiende los comentarios de revisión en sus propios PR. Esto permite que los ingenieros se concentren en el comportamiento en su revisión de PR, lo cual se reduce a juzgar la intención y el riesgo.

Qué cambia

Primeros pasos

• Requisitos previos: Un archivo CLAUDE.md actualizado de la Etapa 3: Construir, skills, si las pasadas de revisión deben hacer cumplir políticas escritas, y subagentes definidos.
• Infraestructura: Un repositorio con la integración de Claude instalada, ya sea el servicio gestionado de Code Review habilitado por un propietario de tu organización de Claude, o la claude-code-action ejecutándose en tu propio CI, con llamadas al modelo a través de Amazon Bedrock, Vertex AI de Google Cloud o Microsoft Foundry cuando sea necesario (la estrategia de CI/CD cubre las opciones de implementación). Las políticas de protección de ramas que requieren la aprobación de un propietario del código también son valiosas.

Cómo ejecutarlo

1. El servicio gestionado de Code Review es el inicio más rápido. Un propietario de tu organización de Claude lo habilita y selecciona los repositorios. Ejecuta la revisión en tu propio CI con la claude-code-action cuando necesites control del pipeline o quieras que las llamadas a la API se enruten a través de tu propio acuerdo de nube (la estrategia de CI/CD cubre esa infraestructura).
2. El líder técnico escribe la política de revisión como REVIEW.md en la raíz del repositorio, dividida en las pasadas que le importan a la organización: errores y fallos lógicos; seguridad y vulnerabilidades; cumplimiento con la especificación (spec.md de la estrategia de requisitos), el plan de implementación (plan.md de la estrategia de modo de planificación) y los principios de diseño. REVIEW.md también define qué cuenta como Importante en contraposición a un Nit, y qué omitir.
3. El líder técnico establece el umbral humano. Los hallazgos no aprueban ni bloquean un PR por sí solos, y la protección de ramas sigue requiriendo la aprobación de un propietario del código. Un ingeniero de plataforma que quiera condicionar las fusiones a los hallazgos puede leer los recuentos de gravedad que la ejecución de verificación publica como un recuento legible por máquina.
4. Cuando un revisor o el autor etiqueta a @claude en un comentario de revisión, Claude atiende el comentario y envía la corrección. El hilo del PR registra tanto la solicitud como el cambio. Este ciclo de corrección se ejecuta a través de la claude-code-action. En el servicio gestionado, comentar @claude review solicita una revisión nueva en su lugar. Para los PR que Claude abrió, ve más allá y deja que Claude cuide el PR hasta la fusión. Los equipos envuelven el ciclo en un comando de barra personalizado que recorre los comentarios de revisión sin resolver y las verificaciones fallidas en el PR, los atiende y envía las correcciones, hasta que el PR esté en verde y solo esperando la aprobación del propietario del código.
5. Los hallazgos de revisión retroalimentan CLAUDE.md. Cuando una revisión señala un error por segunda vez, la corrección se incorpora a CLAUDE.md como parte de esa revisión, y como la revisión lee CLAUDE.md, el error se detecta desde el siguiente PR en adelante. La revisión también señala cuándo un cambio ha dejado CLAUDE.md desactualizado.
6. Una vez al mes, el líder técnico ajusta la configuración calificando los hallazgos para que el revisor mejore y limitando el volumen de Nits en REVIEW.md. Las rutas generadas y todo lo que el CI ya hace cumplir quedan excluidos.

Cómo se ve

REVIEW.md:

# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.

Este ejemplo es lo que la ejecución de verificación enumera para una solicitud de extracción que agrega un panel de estado de reclamaciones al portal de clientes de una aseguradora, donde claims-core es el sistema interno más antiguo detrás del backend del portal:

El primer hallazgo existe solo porque la pasada de cumplimiento lee el plan.md confirmado, que un revisor que mire solo el diff no tendría abierto.

Consideraciones de gobernanza

La separación de funciones se preserva, porque el agente que escribió el código no tiene forma de aprobarlo. La política de revisión en REVIEW.md se aplica a todos los PR, y los hallazgos, correcciones, calificaciones y aprobaciones quedan registrados en el historial del PR, de modo que el PR es el registro de auditoría. La aprobación proviene de un humano a través de la protección de ramas, informado por los hallazgos.

Cómo medirlo

• Indicador adelantado: Tiempo hasta la primera revisión, que debería reducirse a minutos, y la proporción de comentarios de revisión resueltos sin que un humano toque la rama, con datos almacenados directamente en Git.
• Indicador rezagado: Defectos y vulnerabilidades detectados antes de la fusión, comparados con los que escapan a producción, a partir del historial del PR y el rastreador de incidentes.