Programación y vibe coding
Revisar código con agentes de IA: el sistema del equipo de Claude Code
El equipo de Claude Code revisa en capas: el agente verifica antes del PR, varios agentes buscan fallos y otros votan cada hallazgo, la seguridad bloquea el merge, un clasificador decide cuántas personas aprueban y todo sale tras flags con rollback rápido. Sin prueba propia.
| Herramientas | Claude Code (principal) |
|---|---|
| Qué necesitas |
|
| Coste aprox. | Los comandos /code-review y /security-review van dentro de Claude Code. Code Review para Claude Code está en los planes Team y Enterprise. El artículo no da precios ni coste por revisión. |
| Tiempo de montaje | 120 min (primera vez) |
| Nivel | Avanzada |
| Plan gratis | Suele requerir plan de pago |
Prompt listo para usar
Revisa el diff de la rama [RAMA] contra [RAMA BASE] con contexto limpio, como si no hubieras escrito este código. 1. Antes de opinar, ejecuta [COMANDO DE VERIFICACIÓN] y pega la salida. Si falla, para ahí. 2. Lee REVIEW.md si existe y aplica sus reglas. En este repo un fallo grave es: [QUÉ ES UN FALLO GRAVE]. 3. Etiqueta cada hallazgo como Importante, Detalle o Previo (si el fallo ya estaba antes de este cambio). Indica archivo y línea como prueba. 4. Descarta lo que sea solo estilo. No repitas hallazgos de rondas anteriores. 5. Empieza el resumen con el número de hallazgos importantes. Si no hay nada que corregir, dilo claro. 6. Di qué nivel de riesgo tiene el cambio (bajo, medio o alto) y por qué. Esta es la ronda [NÚMERO DE RONDA]. Si es la tercera o más, no sigas revisando: propón replantear el enfoque.
| Variable | Qué poner | Ejemplo |
|---|---|---|
[RAMA] | La rama con el cambio que quieres revisar | fix/descuentos-carrito |
[RAMA BASE] | La rama contra la que se compara | main |
[COMANDO DE VERIFICACIÓN] | Lo que el agente puede ejecutar para demostrar que funciona | npm test && npm run build |
[QUÉ ES UN FALLO GRAVE] | Cómo falla de verdad tu proyecto, en una frase | cobrar mal un pedido o romper el inicio de sesión |
[NÚMERO DE RONDA] | Cuántas veces se ha revisado ya este cambio | 1 |
Pégalo en: Claude Code
Prompt propio inspirado en el proceso que describe el artículo. No es el prompt interno de Anthropic y no se ha ejecutado aquí.
Cómo funciona
- Haz que el agente demuestre su trabajo. Antes del PR, dale algo que pueda ejecutar: tests, un build o una captura que comparar con el diseño. Pídele que enseñe la salida en vez de decir que ha terminado y que un subagente con contexto limpio revise el diff.
- Escribe CLAUDE.md y REVIEW.md cortos. CLAUDE.md explica el proyecto: stack, convenciones y lo que no es objetivo. REVIEW.md lo escriben los responsables del código y dice qué es un fallo en esa parte, qué rutas saltar y que cada hallazgo lleve archivo y línea.
- Revisión con IA en cada pull request. Un revisor lee el diff contra todo el repositorio y la intención del PR. Varios agentes buscan fallos a la vez, otro grupo vota cada hallazgo y solo se publica si suficientes coinciden. Cada comentario se corrige o se cierra con un motivo.
- Seguridad aparte y CI que bloquea. La revisión de seguridad automática corre por separado y un hallazgo abierto impide el merge. Encima van lint, tipos, tests en todas las plataformas y build. La plantilla del PR pregunta cómo se probó y cómo deshacerlo.
- Aprobación humana según el riesgo. Un clasificador asigna el nivel: bajo (docs, cambios tras un flag) sin aprobación humana con todo en verde, medio con una persona y alto con dos. La aprobación de un agente nunca cuenta como la de una persona y cada aprobación vale para un commit concreto.
- Merge queue, flags y vuelta atrás rápida. La cola de merge vuelve a pasar los checks contra main con el cambio aplicado. Lo nuevo sale tras un flag, primero a empleados y luego por canales. Los flags se apagan sin desplegar y hay guardia semanal.
- Limita las rondas de revisión. Tras tres rondas, el revisor pide al autor que replantee el enfoque. Después de las primeras pasadas solo se revisa el diff nuevo, se señala la clase de fallo entera y no se repiten hallazgos ya publicados.
Qué resultado esperar
Un proceso en el que casi todo el código lo leen máquinas antes que una persona y la atención humana se reserva para dirección, código de riesgo y arquitectura. Según el artículo, de junio a septiembre los PRs fusionados se duplicaron con creces y la proporción revertida bajó más de un 40 %.
- Qué se hizo
- El equipo de Claude Code explicó cómo revisa el código cuando Claude escribe alrededor del 90 % del código de su propio producto.
- Cómo fue
- No quitaron la revisión: la movieron casi entera a máquinas, en capas que van desde la verificación antes del PR hasta el rollback, y guardaron la atención humana para donde hay riesgo.
- A tener en cuenta
- Es el proceso de un equipo grande con mucha infraestructura propia. Las piezas sueltas sí se pueden copiar en un repo pequeño. Sin prueba propia todavía.
Límites y precauciones
- Las cifras son internas del equipo de Claude Code y las publica Anthropic. No hay datos de otros equipos.
- Code Review para Claude Code solo está en los planes Team y Enterprise; /code-review en local es una versión más ligera.
- El propio equipo dice que aún no tiene cortacircuitos que endurezcan la aprobación cuando suben las reversiones.
- Sin prueba propia todavía.
- No quites la revisión humana de golpe. El artículo recomienda empezar estricto y aflojar solo con datos.
- Pagos, autenticación, CI e instaladores deberían pedir siempre una persona, con CODEOWNERS y protección de rama.
- Agente autor y agente revisor pueden entrar en bucle: un PR suyo pasó más de cincuenta rondas en una noche. Pon tope de rondas.
Variantes
- claude-code: Para seguridad hay una GitHub Action de código abierto y el comando /security-review, según el artículo.
Fuente: el artículo del blog de claude.dev firmado por Addy Osmani, Morgan Westlee Lunt y Qing Wang el 15 oct 2026, que el equipo difundió en X. Sin prueba propia todavía.
Claude escribe alrededor del 90 % del código de Claude Code. Con ese volumen, leer cada diff línea a línea ya no es posible, así que el equipo cambió la pregunta. En vez de «¿lo ha leído una persona?», se preguntan qué puede salir mal con un cambio y qué control, automático o humano, es el adecuado para cazarlo. Según el artículo, de junio a septiembre los PRs fusionados se duplicaron con creces y la proporción que hubo que revertir bajó más de un 40 %.
El sistema funciona en capas. Primero, el agente verifica su trabajo antes de abrir el PR y enseña la salida. Después, un revisor con IA lee cada PR; varios agentes buscan fallos y otro grupo vota cada hallazgo, que solo se publica si suficientes coinciden. La seguridad tiene su propia revisión y puede bloquear el merge. Luego vienen la CI, la aprobación humana según el riesgo y, al final, la cola de merge, los flags y una vuelta atrás rápida.
Lo más útil para cualquier equipo es la lección sobre las rondas. Un agente que escribe y otro que revisa se pueden tener ocupados sin fin: un PR suyo pasó más de cincuenta rondas en una noche. Ahora, tras tres rondas, el revisor pide replantear el enfoque.
Las personas no desaparecen. Deciden si algo se debe construir, revisan el código de riesgo y la arquitectura, leen las pruebas y responden del resultado.
Si quieres auditar la seguridad de un repositorio con agentes, tienes el skill abierto de Cloudflare. Para repartir trabajo entre varios agentes, mira varios agentes de código sin que se pisen, y si empiezas de cero, programar con un agente de código. Más sobre la herramienta en la ficha de Claude Code.
Preguntas frecuentes
¿Lo habéis probado?
No. Sin prueba propia todavía. La ficha resume el artículo del blog de claude.dev. El prompt es propio y no se ha ejecutado aquí.
¿Ya no revisa nadie el código a mano?
Sí revisan, pero menos líneas. Los cambios de bajo riesgo pueden entrar sin aprobación humana si todo está en verde. Los de riesgo medio piden una persona y los de alto, dos.
¿Qué es REVIEW.md?
Un archivo que escriben los responsables de cada parte del código para decirle al revisor qué importa allí: qué es un fallo grave, qué rutas saltar y que cada hallazgo lleve archivo y línea.
¿Por qué limitar las rondas de revisión?
Porque un agente que escribe y otro que revisa pueden seguir sin fin. Al mirar lo señalado, cerca del 59 % era código que ya estaba desde la primera pasada, no fallos nuevos.
¿Puedo hacerlo en un proyecto pequeño?
Las piezas básicas sí: CI obligatoria, /code-review y /security-review en local, un REVIEW.md corto, tope de rondas y CODEOWNERS en las rutas sensibles.
Telegram. Suscríbete al canal de Telegram para no perderte nada y estar al loro de todo lo nuevo en automatización y agentes de IA.Unirme al canal