Revisión de código con IA en GitHub Actions con Claude y Gemini

15 min de lectura·Matthieu·ci-cdgeminiclaudeai-code-reviewgithub-actions|

Configure Claude Code Action y Gemini para la revisión automatizada de pull requests. Workflows multi-modelo con separación de roles, quality gates que bloquean merges en hallazgos críticos y protección contra inyección de prompts.

La revisión de código con IA ha pasado del experimento al uso productivo. Claude Code Action y Gemini Code Assist pueden revisar cada pull request automáticamente, detectando errores lógicos, vulnerabilidades de seguridad y gestión de errores faltante que los linters y el análisis estático no ven.

Este tutorial configura ambos modelos en el mismo repositorio. Claude se encarga de la revisión de lógica y seguridad. Gemini se encarga del estilo y la documentación. Un quality gate analiza la severidad de ambas revisiones y bloquea merges cuando se encuentran problemas críticos.

AIOps en un VPS: gestión de servidores con IA y herramientas open source

¿Qué detecta la revisión de código con IA que los linters no encuentran?

Los linters verifican sintaxis y formato. Las herramientas de análisis estático como Semgrep detectan patrones conocidos. Los revisores de código con IA hacen algo diferente: leen el diff en contexto y razonan sobre lo que hace el código. Señalan condiciones de carrera, rutas de gestión de errores faltantes, configuraciones predeterminadas inseguras y errores de lógica de negocio que las herramientas basadas en patrones no pueden detectar.

Un estudio de Milvus probó cinco modelos de IA en la detección de bugs reales en PRs de producción. El mejor modelo individual detectó el 53 % de los bugs. Cuando varios modelos revisaron la misma PR y debatieron los hallazgos entre rondas, la detección subió al 80 %. Los bugs más difíciles, los que requieren comprensión a nivel de sistema de cadenas de llamadas y propagación de errores, alcanzaron el 100 % de detección en modo de debate multi-modelo.

Ese estudio es la razón por la que este tutorial usa dos modelos en lugar de uno.

Ejemplos concretos de lo que detecta la revisión con IA:

  • Entradas de usuario no validadas que fluyen a través de tres llamadas a funciones antes de alcanzar una consulta a la base de datos
  • Verificaciones null faltantes cuando una función devuelve Optional<T> pero el llamador asume que siempre tiene éxito
  • Secretos codificados directamente en archivos de configuración que parecen valores de ejemplo pero son credenciales reales
  • Brechas en la gestión de errores donde un try/catch captura una excepción genérica y la silencia
  • Condiciones de carrera en código concurrente donde el estado compartido se modifica sin sincronización

¿Cómo se configura Claude Code Action para la revisión de pull requests?

Claude Code Action es una GitHub Action mantenida por Anthropic que ejecuta Claude en su runner de GitHub. Lee diffs de PRs, publica comentarios en línea y también puede implementar correcciones. La configuración toma unos cinco minutos.

Instalar la aplicación GitHub de Claude

Vaya a github.com/apps/claude e instálela en su repositorio u organización. Otorgue acceso a los repositorios que desea revisar. La aplicación necesita estos permisos:

  • Contents: Read
  • Pull Requests: Read & Write
  • Issues: Read & Write (opcional, para clasificación de issues)

Agregar la clave API

En su repositorio, vaya a Settings > Secrets and variables > Actions y cree un nuevo secreto:

  • Name: ANTHROPIC_API_KEY
  • Value: Su clave API de Anthropic (comienza con sk-ant-)

Nunca haga commit de claves API en su repositorio. Si necesita acceso a nivel de organización, use secretos de entorno en lugar de secretos de repositorio.

Crear el workflow

Cree .github/workflows/claude-review.yml:

name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: write
      id-token: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Review this pull request. Focus on:
            1. Security: injection flaws, auth bypass, hardcoded secrets, insecure defaults
            2. Logic errors: off-by-one, null dereference, race conditions, resource leaks
            3. Error handling: swallowed exceptions, missing retries, unclear error messages
            4. Performance: N+1 queries, unbounded loops, unnecessary allocations

            Skip cosmetic issues (formatting, naming style). Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Use inline comments for specific code issues.
            Use a summary PR comment for overall assessment.

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

El filtro paths limita las revisiones a cambios en código fuente. Las PRs que solo tocan documentación se saltan el workflow, lo que ahorra costes API. El bloque concurrency cancela revisiones en curso cuando se hace push de un nuevo commit a la misma PR, para no pagar por revisar código obsoleto.

La restricción --allowedTools es una medida de seguridad. Limita a Claude a leer diffs y publicar comentarios. No puede modificar archivos, ejecutar comandos arbitrarios ni acceder a otros repositorios.

¿Cómo agregar la revisión de Gemini al mismo repositorio?

Dos opciones para la revisión con Gemini: la aplicación GitHub Gemini Code Assist (gestionada por Google, cero YAML) o la GitHub Action run-gemini-cli (autogestionada, control total). Este tutorial usa la GitHub Action porque da control sobre el prompt y se integra con el workflow de quality gate.

Obtener una clave API de Gemini

Cree una clave en Google AI Studio. Agréguela como secreto del repositorio:

  • Name: GEMINI_API_KEY
  • Value: Su clave API de Gemini

Para uso empresarial con autenticación de Vertex AI, consulte la documentación de run-gemini-cli para la configuración de Workload Identity Federation.

Crear el workflow de Gemini

Cree .github/workflows/gemini-review.yml:

name: Gemini Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

concurrency:
  group: gemini-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: google-github-actions/run-gemini-cli@main
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          prompt: |
            Review this pull request. Focus on:
            1. Code style: naming conventions, function length, complexity
            2. Documentation: missing docstrings, outdated comments, unclear variable names
            3. Test coverage: untested edge cases, missing assertions, test quality
            4. Maintainability: code duplication, tight coupling, violation of SOLID principles

            Skip security and logic analysis. Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Post your review as a single PR comment with structured sections.

La action run-gemini-cli está actualmente en beta, por eso el workflow apunta a @main. Para uso en producción, fije un SHA de commit específico (p. ej. @abc1234) para evitar cambios inesperados cuando se actualice la rama main.

¿Por qué dos workflows separados?

Ejecutar Claude y Gemini en archivos de workflow separados significa que se ejecutan en paralelo. Un fallo en uno no bloquea al otro. También puede desactivar temporalmente un modelo sin tocar el otro workflow.

La separación de roles es intencional. Claude tiende a seguir las cadenas de llamadas de principio a fin y es bueno detectando brechas en la gestión de errores y fallos de seguridad. Gemini es fuerte en estilo de código, completitud de documentación y patrones estructurales. El solapamiento es normal. La coincidencia entre modelos aumenta la confianza en los hallazgos.

¿Cómo funciona la revisión multi-modelo con Claude y Gemini juntos?

La configuración de dos workflows anterior ya implementa la revisión multi-modelo. Ambos modelos revisan la misma PR de forma independiente y publican comentarios separados. Es el patrón más simple y funciona bien para la mayoría de los equipos.

Para equipos que quieran una vista unificada, agregue un paso de agregación. Este tercer workflow se ejecuta después de que ambas revisiones terminen y publica un resumen combinado:

name: AI Review Summary

on:
  workflow_run:
    workflows: ["Claude Code Review", "Gemini Code Review"]
    types: [completed]

jobs:
  aggregate:
    if: github.event.workflow_run.event == 'pull_request'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    permissions:
      pull-requests: write
      actions: read

    steps:
      - name: Collect review comments
        id: collect
        uses: actions/github-script@v7
        with:
          script: |
            const pr_number = context.payload.workflow_run.pull_requests[0]?.number;
            if (!pr_number) return;

            const comments = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
            });

            const aiComments = comments.data.filter(c =>
              c.body.includes('CRITICAL') ||
              c.body.includes('HIGH') ||
              c.body.includes('MEDIUM')
            );

            const critical = aiComments.filter(c => c.body.includes('CRITICAL')).length;
            const high = aiComments.filter(c => c.body.includes('HIGH')).length;

            const summary = `## AI Review Summary\n\n` +
              `| Severity | Count |\n|----------|-------|\n` +
              `| CRITICAL | ${critical} |\n` +
              `| HIGH | ${high} |\n\n` +
              (critical > 0 ? '⛔ **Merge blocked:** Critical findings require human review.\n' :
               high > 0 ? '⚠️ High-severity findings detected. Review recommended before merge.\n' :
               '✅ No critical or high-severity findings.\n');

            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
              body: summary,
            });

            core.setOutput('critical_count', critical);

      - name: Set status check
        if: steps.collect.outputs.critical_count > 0
        run: exit 1

Esto es un punto de partida. Adapte la lógica de análisis de comentarios al formato exacto que producen sus prompts. Las palabras clave de severidad (CRITICAL, HIGH, MEDIUM) en los prompts de revisión hacen que el parsing sea directo.

¿Cómo bloquear merges cuando la revisión IA encuentra problemas críticos?

El workflow de agregación anterior establece el código de salida 1 cuando existen hallazgos críticos. Para convertirlo en un bloqueador de merge, configure la protección de rama:

  1. Vaya a Settings > Branches > Branch protection rules
  2. Seleccione o cree una regla para su rama principal
  3. Active Require status checks to pass before merging
  4. Busque y agregue "AI Review Summary" como status check requerido
Severidad Acción ¿Merge bloqueado?
CRITICAL Fallo del status check Sí
HIGH Advertencia en el resumen No (consultivo)
MEDIUM Listado en el resumen No
LOW Omitido del resumen No

Una advertencia: los revisores IA producen falsos positivos. Si hace el status check obligatorio, los desarrolladores tendrán que descartar ocasionalmente hallazgos incorrectos. Mantenga CRITICAL como la única severidad bloqueante. Si también bloquea en HIGH, espere fricción.

Para anular un merge bloqueado, un maintainer puede usar el bypass de administrador en la regla de protección de rama, o puede agregar un manejador de comentario /dismiss-ai-review que relance el workflow de resumen con un flag de aprobación forzada.

¿Cómo reducir los falsos positivos en la revisión de código con IA?

Los falsos positivos son la queja principal de los equipos que usan revisión de código con IA. Revisiones ruidosas erosionan la confianza rápidamente. Tres técnicas ayudan.

Acotar el prompt

Los prompts anteriores ya lo hacen: Claude revisa seguridad y lógica, Gemini revisa estilo y documentación. Un modelo al que se le pide "revisar todo" produce más ruido que uno con un mandato específico.

Agregue contexto específico del proyecto para reducir más los falsos positivos. Cree un archivo CLAUDE.md en la raíz de su repositorio (Claude Code Action lo lee automáticamente):

# Project Context

This is a Django REST API. Python 3.12. PostgreSQL.

## Review Guidelines
- We use `rest_framework.exceptions` for all error handling. Do not flag bare `except` blocks in middleware.
- `settings.py` contains environment variable references, not hardcoded secrets. Do not flag `os.environ.get()` calls.
- We intentionally use `Any` type hints in the serializer layer. Do not flag these.
- Test files use `pytest` fixtures. Do not flag unused function parameters in test files.

Para Gemini, cree un archivo GEMINI.md en la raíz del repositorio con contexto de proyecto equivalente.

Filtrar archivos

Los filtros paths y paths-ignore en el YAML del workflow impiden revisiones de archivos que generan ruido:

paths-ignore:
  - "**/*.md"
  - "**/*.txt"
  - "**/*.lock"
  - "**/*.generated.*"
  - "migrations/**"
  - "vendor/**"
  - "dist/**"
  - "__snapshots__/**"

Los archivos lock, el código generado, las dependencias vendored y los archivos de migración producen falsos positivos porque son generados por máquinas o siguen patrones que el modelo no entiende en contexto.

Establecer un umbral de severidad

Si solo muestra los hallazgos CRITICAL y HIGH en el resumen, el ruido MEDIUM y LOW nunca llega al desarrollador. Es un mejor valor predeterminado que mostrar todo y pedir a los desarrolladores que ignoren el ruido.

¿Cuáles son los riesgos de seguridad de la revisión de código IA en pull requests?

Los revisores de código IA procesan entradas no confiables. El diff de la PR, los mensajes de commit, los títulos de issues y el contenido de los archivos son controlados por el atacante en repositorios de código abierto o al aceptar contribuciones externas. Esto crea riesgo de inyección de prompts (prompt injection).

El ataque Clinejection

En febrero de 2026, un atacante explotó el bot de clasificación de issues Cline mediante inyección indirecta de prompts. El ataque fue sencillo: un título de issue malicioso en GitHub contenía instrucciones disfrazadas de mensaje de error. El workflow del agente IA interpolaba el título del issue directamente en el prompt. El agente siguió las instrucciones inyectadas, ejecutó npm install de un paquete malicioso y exfiltró la clave ANTHROPIC_API_KEY del entorno CI.

El ataque comprometió aproximadamente 4.000 máquinas de desarrolladores antes de que se retirara el paquete malicioso.

Proteger sus workflows

Restringir los permisos de herramientas. El flag --allowedTools en el workflow de Claude anterior limita lo que Claude puede hacer. Puede leer diffs y publicar comentarios. No puede ejecutar comandos de shell arbitrarios, escribir archivos ni acceder a secretos. Es la medida de mitigación más efectiva.

claude_args: |
  --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Sin esta restricción, un diff de PR manipulado podría instruir a Claude para ejecutar comandos en el runner.

Nunca interpole entradas no confiables en los prompts. No use ${{ github.event.issue.title }} ni ${{ github.event.pull_request.body }} dentro del campo prompt. Pase el repositorio y el número de PR, y deje que la action obtenga el contenido mediante la API de GitHub.

Gestione las PRs de forks con cuidado. Las PRs de forks se ejecutan con permisos GITHUB_TOKEN reducidos por defecto, pero sus secretos siguen disponibles para el workflow si se activa con pull_request_target. Use pull_request (no pull_request_target) para workflows de revisión IA. Así las PRs de forks no pueden acceder a sus claves API y la revisión no se ejecutará, que es el comportamiento seguro por defecto.

on:
  pull_request:        # Safe: fork PRs cannot access secrets
    types: [opened, synchronize]
  # pull_request_target:  # Dangerous: fork PRs CAN access secrets

Rote sus claves API. Si una clave se expone a través de un log de CI o un runner comprometido, el radio de impacto se limita al tiempo entre rotaciones. Rote como mínimo cada trimestre.

Audite las ejecuciones de workflows. Revise la pestaña Actions periódicamente en busca de tiempos de ejecución inusuales o invocaciones de herramientas inesperadas. Una revisión que tarda 45 minutos en lugar de los 3 habituales puede indicar que el modelo está siendo manipulado.

¿Cuánto cuesta la revisión de código IA por pull request?

El coste escala con el tamaño de la PR. Tanto Claude como Gemini cobran por token procesado. Los tokens de entrada incluyen el diff de la PR, el contexto de archivos y su prompt. Los tokens de salida son los comentarios de revisión.

Tamaño de PR Diff típico (líneas) Tokens de entrada estimados
Pequeña 50-100 2.000-5.000
Mediana 200-500 8.000-20.000
Grande 500-1.500 20.000-60.000

La cantidad de tokens varía según el lenguaje. Un diff Python de 200 líneas consume menos tokens que un diff Java de 200 líneas porque Java es más verboso.

Usar dos modelos duplica el coste en tokens pero no el coste en euros, porque la tarificación difiere entre proveedores. Consulte las tarifas actuales por token en la página de precios de Anthropic y la página de precios de Google AI. Ambos usan tarificación por token con tarifas diferentes para tokens de entrada y salida.

Para estimar su presupuesto mensual: multiplique el tamaño promedio de sus PRs (en tokens) por el número de PRs al mes, luego multiplique por la tarifa por token de cada modelo. Un equipo que hace merge de 50 PRs por semana con diffs de tamaño medio puede calcular:

weekly_cost = 50 * avg_tokens_per_pr * (claude_input_rate + gemini_input_rate)
              + 50 * avg_output_tokens * (claude_output_rate + gemini_output_rate)

Reducir costes

  • Los filtros de rutas impiden revisiones de docs, archivos lock y código generado. Es el mayor ahorro.
  • La cancelación por concurrencia detiene la revisión de commits obsoletos cuando llega un nuevo push.
  • Omita las PRs en borrador no incluyendo ready_for_review en sus tipos de trigger, y añádalo solo cuando quiera revisiones en transiciones de borrador a listo.
  • Use modelos más pequeños para la revisión de estilo. Gemini Flash es más barato que Gemini Pro para verificaciones de estilo y documentación donde el razonamiento profundo no es necesario.

Comparación: herramientas de revisión de código con IA

Característica Claude Code Action Gemini Code Assist CodeRabbit GitHub Copilot
Método de configuración GitHub Action (YAML) GitHub App o Action GitHub App Integrado
Modelo de precio Por token (API) Por token o nivel gratuito Suscripción por repositorio Suscripción por puesto
Comentarios en línea Sí Sí Sí Sí
Prompts personalizados Control total Control total (Action) Archivo de config Limitado
Runner autoalojado Sí Sí (Action) No No
Soporte multi-modelo Combinable Combinable Modelo único Modelo único
Código abierto Sí (MIT) Sí (Action) No No

Claude Code Action y la action Gemini CLI son de código abierto y se ejecutan en sus propios runners. Su código nunca sale de su infraestructura excepto para la llamada API al proveedor del modelo. CodeRabbit y Copilot son servicios gestionados donde el código se procesa en su infraestructura.

¿Cuáles son las limitaciones de la revisión de código con IA?

La revisión de código con IA no reemplaza la revisión humana. Es una primera pasada que detecta problemas comunes y libera a los revisores humanos para concentrarse en arquitectura, diseño y decisiones de lógica de negocio.

Límites de la ventana de contexto. Las PRs grandes (más de 1.500 líneas modificadas) pueden exceder la ventana de contexto del modelo o producir revisiones superficiales porque el modelo no puede mantener todo el diff en contexto. Divida las PRs grandes en más pequeñas. Es una buena práctica independientemente de la revisión IA.

Sin comprensión en tiempo de ejecución. Los revisores IA ven código estático. No pueden detectar problemas que solo se manifiestan en tiempo de ejecución: fugas de memoria bajo carga, condiciones de carrera dependientes del timing o degradación de rendimiento a gran escala.

Los falsos positivos son inevitables. Incluso con prompts ajustados y archivos de contexto de proyecto, los modelos señalarán código correcto. Prevea un 10-20 % de falsos positivos en los hallazgos. Si la tasa es más alta, ajuste sus prompts y agregue más contexto a CLAUDE.md o GEMINI.md.

Sin conocimiento institucional. El modelo no conoce las convenciones no escritas de su equipo, las decisiones históricas ni los patrones específicos del dominio a menos que los documente en los archivos de contexto. Invierta tiempo en escribir buenos archivos CLAUDE.md y GEMINI.md. Esa inversión rinde en cada futura revisión.

Determinismo. La misma PR revisada dos veces puede producir hallazgos diferentes. La revisión IA es probabilística. No trate "sin hallazgos" como "sin bugs".

Solución de problemas

El workflow de revisión de Claude nunca se activa. Compruebe el filtro paths. Si su código fuente está fuera de src/, lib/ o app/, ajuste las rutas para que coincidan con la estructura de su proyecto. Verifique también que la aplicación GitHub de Claude está instalada en el repositorio.

Gemini devuelve revisiones vacías. Confirme que el secreto GEMINI_API_KEY está configurado y que la clave es válida. Pruébela localmente:

curl -s "https://generativelanguage.googleapis.com/v1beta/models?key=YOUR_KEY" | head -20

Si ve una lista de modelos, la clave funciona.

Las revisiones tardan demasiado. El ajuste timeout-minutes: 15 detiene el workflow si supera los 15 minutos. Las PRs grandes con más de 1.000 líneas pueden tardar 5-10 minutos. Si los timeouts son frecuentes, ajuste el filtro paths para reducir el tamaño del diff.

Demasiados falsos positivos. Agregue contexto de proyecto a CLAUDE.md y GEMINI.md. Sea específico sobre los patrones que el modelo debe ignorar. "No señalar X" es más efectivo que "sé indulgente".

El status check queda pendiente. El workflow de agregación se activa al completarse workflow_run. Si uno de los dos workflows de revisión se omite (porque no cambiaron archivos coincidentes), la agregación puede no activarse. Agregue un filtro paths al workflow de agregación que cubra la unión de ambos workflows de revisión, o use un status check separado que se ejecute siempre.

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.

¿Listo para probarlo?

Despliega tu propio servidor en segundos. Linux, Windows o FreeBSD.

Ver planes VPS