Un agente te entrega un pull request de 400 líneas y anuncia que “todo funciona”. Los tests pasan, pero el cambio altera cómo se cobra a un cliente. ¿Quién revisa qué, y en qué orden, para no convertir cada PR en una tarde de lectura? El equipo de Claude Code publicó el 15 de octubre de 2026 su sistema de revisión: verificaciones antes del PR, revisión con IA, controles de seguridad, CI, aprobación humana según riesgo y un camino claro para revertir.

La lección útil para un fundador o vibecoder no es copiar la estructura de Anthropic entera. Es poner evidencia y riesgo en el centro. Anthropic explica que el porcentaje de PR revertidos bajó mientras el volumen de cambios crecía en su equipo, pero ese resultado pertenece a su contexto; no demuestra que instalar un revisor produzca lo mismo en tu repositorio. Esta guía propone una versión pequeña que puedes probar esta semana.

Empieza antes de abrir el pull request

Da al agente un criterio que pueda ejecutar: tests, build o una captura comparada con el diseño. Pide el comando exacto y su salida, no la frase “tests OK”. En un proyecto web, selecciona una tarea pequeña y reproduce el flujo: el agente modifica el código, ejecuta la prueba relevante, muestra el diff y luego un revisor con contexto nuevo busca fallos. Si la interfaz cambió, comprueba el estado normal, vacío y de error en el navegador. El objetivo es descubrir errores baratos antes de pedir tiempo a otra persona.

Anthropic usa instrucciones breves en CLAUDE.md para el contexto del proyecto y REVIEW.md para lo que debe vigilar el revisor. Un REVIEW.md inicial puede ser así; adapta las rutas y riesgos a tu producto:

# REVIEW.md

Revisa el comportamiento, no el estilo.
En este repositorio un fallo crítico es cobrar dos veces, perder datos
de un formulario o exponer una clave.

Para cada hallazgo: archivo y línea, escenario reproducible,
consecuencia y prueba que lo detectaría.
Marca como preexistente lo que el PR no introdujo.
Ignora cambios de formato sin efecto funcional.
Si no hay problemas verificables, dilo claramente.
No apruebes un cambio de pagos, autenticación, CI o despliegue
sin revisión humana.

Este archivo es una plantilla editorial de SoyJB, no un archivo oficial de Anthropic. Antes de adoptarlo, prueba el revisor en cinco PR conocidos: al menos uno con bug real, uno limpio y uno con un problema preexistente. Anota cuáles detectó, cuáles inventó y cuánto trabajo agregó. Si el revisor repite siempre un mismo comentario válido, conviértelo en test o regla de lint; así no dependes de que “lo recuerde”.

Un proceso mínimo por niveles de riesgo

Para documentación o textos detrás de una bandera, la revisión automática más CI puede ser suficiente si tu equipo lo permite. Para una función normal de producto, exige una persona que compruebe el objetivo y la evidencia. Para pagos, autenticación, migraciones de datos, workflows de CI y release, pide revisión de alguien que conozca esa área y plan de reversión. Anthropic describe Quick, Standard y Deep para su producto Code Review, pero el nombre del nivel no importa tanto como declarar qué puede fallar y quién debe decidir.

En cada PR añade tres apartados: Pruebas (comandos y resultados), Riesgo (qué usuarios o datos pueden verse afectados) y Cómo revertir (flag, commit o despliegue anterior). Un bot puede rellenar la primera versión, pero el autor responsable debe comprobarla. Protege ramas y usa CODEOWNERS para las rutas sensibles; una aprobación de un agente nunca debe ocupar el lugar de una aprobación humana exigida.

Qué herramienta está realmente disponible

Según el artículo, Code Review para Claude Code está disponible de forma general en planes Team y Enterprise; el comando local /code-review ejecuta una revisión más ligera. Anthropic menciona también la acción de GitHub y /security-review como opciones para un flujo automatizado. Comprueba la disponibilidad y el costo de tu plan antes de configurar una organización entera. Empieza con un solo repositorio y compara sus hallazgos con lo que detectaban tus revisiones anteriores.

Evita el bucle agente contra agente

Un revisor automático puede pedir arreglos, recibir un nuevo commit y encontrar algo más. Anthropic cuenta que un PR interno superó cincuenta rondas. Su respuesta fue limitar las rondas, revisar solo el diff nuevo tras las primeras pasadas y señalar la clase de bug para corregir todas sus instancias. Para tu equipo, fija un límite inicial de tres rondas automáticas. Si no converge, detén la cadena y pide a una persona que reformule el cambio. Mide no solo cuántos comentarios genera, sino cuántos eran correctos, cuántos se corrigieron y si subieron los reverts o incidentes.

La decisión final sigue siendo humana: si la función debía existir, si la arquitectura conviene y si la evidencia cubre el riesgo. Usa el revisor para quitar ruido, no para ocultar el diff. Si la revisión automática marca “sin hallazgos”, sigue leyendo el objetivo, la prueba y el plan de reversión. Esa disciplina es la que vuelve útil la velocidad del agente.

Fuente: Addy Osmani, Morgan Westlee Lunt y Qing Wang, claude.dev, 15 de octubre de 2026. La plantilla y el piloto de cinco PR son propuestas de SoyJB y no resultados de una prueba propia.