Claude para revisar código: un flujo de trabajo práctico

La mayoría de los consejos sobre revisar código con Claude están desfasados: te dicen que pegues un diff en una ventana de chat. Eso sigue funcionando, pero ahora hay tres formas distintas, y difieren en coste, profundidad y quién puede usarlas. Elegir la equivocada es la razón de que la gente concluya que la revisión con IA es magia o es inútil.

Tres formas y para quién es cada una

Empieza por el del medio si escribes código a diario. No necesita la app de GitHub, no cuesta nada más allá de tu plan actual y detecta justo el tipo de error que más te interesa cazar: el que todavía está en tu copia de trabajo.

Revisar antes de hacer push

En una sesión de Claude Code, /code-review revisa los commits de tu rama que van por delante de su upstream, más todo lo no confirmado. También puedes apuntarla a algo concreto: una ruta de archivo, un nombre de rama, un número de PR o un rango como main...my-feature.

En la práctica importan dos flags. --fix aplica los hallazgos a tu copia de trabajo tras la revisión, y --comment los publica como comentarios en línea del PR. La revisión se ejecuta en segundo plano con su propio contexto, así que no desplaza la conversación que tenías.

También puedes ajustar cuánto se esfuerza. Un nivel bajo informa solo de los hallazgos de alta confianza, lo que reduce los falsos positivos; un nivel alto amplía la cobertura e incluye cosas de las que está menos segura. Para una comprobación rápida antes del push, lo bajo suele ser el equilibrio correcto.

Revisar pull requests automáticamente

La integración gestionada con GitHub es otra cosa: varios agentes examinan el diff en paralelo con tu base de código completa, cada uno buscando un tipo distinto de problema, y después un paso de verificación contrasta los candidatos con el comportamiento real del código antes de publicar nada. Los hallazgos aparecen como comentarios en las líneas exactas.

Tres cosas que conviene saber antes de proponerlo a tu equipo. Es una vista previa de investigación limitada a los planes Team y Enterprise. Nunca bloquea un merge: la comprobación siempre termina de forma neutra, así que tu proceso de revisión actual queda intacto. Y se factura aparte de tu plan mediante créditos de uso, con una media de 15-25 $ por revisión, que escala con el tamaño del PR.

El disparador que elijas marca la factura. Revisar en cada push detecta problemas según evoluciona el PR y multiplica el coste por el número de pushes; el modo manual no cuesta nada hasta que alguien comenta @claude review en un PR.

Un cambio que conviene conocer

Antes de una actualización de julio de 2026, comentar @claude review también suscribía el PR a revisiones en cada push posterior. Ya no lo hace. Si un flujo que copiaste de un artículo antiguo depende de eso, usa @claude review always: el comando a secas ahora ejecuta una sola revisión y nada más.

Para que cualquiera de estos comandos funcione, publícalos como comentario de primer nivel en el PR y no como respuesta en una línea del diff, y coloca el comando al principio del comentario.

Enseñarle tus estándares

Por defecto, la revisión apunta a la corrección —fallos que romperían producción— y no al formato ni a los tests que faltan. Dos archivos cambian eso, y conviene entender bien la diferencia entre ellos.

Pon el contexto general del proyecto en CLAUDE.md y las reglas específicas de revisión en REVIEW.md. Lo más valioso en este último es un tope de nits («informa de cinco como máximo, menciona el resto como recuento»), reglas para saltarse archivos generados y todo lo que ya comprueba CI, y una redefinición de qué significa Important en tu repositorio: la calibración por defecto asume código de producción y será errónea en un repositorio de documentación o de prototipo.

Mantenlo corto. Un archivo de instrucciones largo diluye las reglas que más importan, igual que un bloque largo de instrucciones personalizadas.

Qué pedir en una revisión por chat

Si pegas un diff en lugar de usar las herramientas, la petición importa más que el diff. «Revisa esto» produce una lista de observaciones genéricas; una pregunta concreta produce algo con lo que puedes actuar.

• «¿Qué se rompe si esta entrada es nula o vacía?»: apunta a los casos límite que los tests suelen pasar por alto.
• «¿Cuáles de estos cambios podrían afectar al comportamiento fuera de los archivos mostrados?»: saca a la luz el riesgo que un diff oculta por definición.
• «Solo seguridad: ¿hay aquí algo que filtre datos o confíe en una entrada en la que no debería?»: una lente cada vez funciona mejor que un barrido general.
• «¿Qué pretendía probablemente el autor y dónde no hace eso el código?»: detecta errores de lógica en lugar de estilo.
• «¿Qué contexto necesitarías para revisar esto como es debido?»: sorprendentemente eficaz; la respuesta te dice qué pegar a continuación.

Dale la función o el archivo que rodea al cambio, no solo las líneas modificadas. Un diff elimina justo el contexto que necesita quien revisa, y por eso los revisores humanos también abren el archivo.

Dónde se queda realmente corto

• No conoce tu producto. Un cambio puede ser técnicamente correcto y aun así equivocado para el negocio, y ningún revisor sin ese contexto lo detectará.
• No sustituye a los tests. Una revisión razona sobre el código; solo ejecutarlo demuestra algo.
• Las revisiones se hacen en la medida de lo posible: una ejecución fallida o agotada no se reintenta sola.
• El servicio de GitHub no está disponible para organizaciones con retención cero de datos activada.
• En un chat solo ve lo que pegas, y razonará tan tranquilo sobre una función que no le has mostrado.
• Señala con seguridad. Trata los hallazgos 🔴 como algo que comprobar, no como veredictos.

Un flujo que encaja de verdad

1. Escribe el cambio.
2. Antes de hacer push, ejecuta /code-review en local con esfuerzo bajo para ir rápido.
3. Corrige lo que encontró, o pasa --fix y lee el diff que ha generado.
4. Haz push. Si tu equipo tiene la integración de GitHub, deja que se ejecute la revisión automática.
5. Envíaselo a una persona, cuyo trabajo ahora es la parte que las máquinas no pueden hacer: ¿es este el cambio correcto siquiera?

Por dónde seguir

Si revisas la misma base de código una y otra vez en chat, un proyecto mantiene el contexto cargado y dejas de repegar las convenciones cada vez: consulta cómo usar Claude Projects. Para los conceptos de fondo están el glosario de Claude y la base de conocimiento de Claude, y la página de Claude recoge planes y limitaciones.

En resumen

Claude es bueno en la parte de la revisión que no le gusta a nadie: casos límite, incoherencias, eso que dejas de ver a la cuarta lectura. No es bueno sabiendo si el cambio debería existir siquiera.

Usa /code-review antes de hacer push: es gratis con tu plan y detecta problemas mientras aún son baratos. Añade la integración de GitHub si un equipo se ahoga en PR y los 15-25 $ por revisión salen más baratos que los fallos. Y deja a una persona la pregunta de si el código resuelve el problema correcto: esa parte no se ha movido.