Automatiza tu CI/CD con GitHub Actions e IA

El PR que cuesta 250 dólares

Un pull request normal. Diez commits, cada uno con su push. Si tienes la revisión de IA «en cada push» y el precio es por revisión, la aritmética es cruel: entre 15 y 25 dólares por review, multiplicado por diez, son entre 150 y 250 dólares por un solo PR. Nadie abre un PR pensando en eso, y casi nadie lo descubre hasta que llega la factura.

Ese es el problema real de la IA en CI/CD en 2026: no faltan herramientas, es que no sabes cuánto cuestan hasta que es tarde. Este artículo va de las tres decisiones que nadie documenta: dónde corre el modelo, quién paga cada revisión y qué puede hacer el agente con tu GITHUB_TOKEN.

Copilot code review es GA, y se activa con un ruleset

Empecemos desmontando la expectativa más extendida: no hay un YAML que active Copilot code review. No existe un uses: que lo encienda. Si has visto un workflow que promete activarlo, no hace lo que dice.

Copilot code review está GA en GitHub.com, GitHub CLI, GitHub Mobile, VS Code, Visual Studio, Xcode y JetBrains. En Azure DevOps sigue en public preview.

La activación es configuración, no código, y tiene tres niveles.

Nivel usuario. Con planes Pro, Pro+ o Max (también con licencia Business o Enterprise, pero no en cuentas gestionadas), vas a tu avatar, entras en Copilot settings y pones Automatic Copilot code review en Enabled.

Nivel repositorio. Repo, Settings, Code and automation, Rules, Rulesets, New branch ruleset. Eliges las ramas objetivo con Add target (por ejemplo, Include default branch), marcas Automatically request Copilot code review y dejas el Enforcement status en Active. Ahí hay dos casillas que cambian el comportamiento: Review new pushes, sin la cual Copilot revisa el PR una sola vez y los commits posteriores pasan sin revisar; y Review draft pull requests, desactivada por defecto.

Nivel organización. El mismo flujo en Organization, Settings, Rulesets, con filtro por patrón de repositorio (por ejemplo *cat*, excluyendo not-a-cat).

El detalle que rompe el modelo mental

Los tres niveles no son jerárquicos. La documentación lo dice de forma explícita: la configuración de usuario y la del ruleset no se heredan ni se sobrescriben. El PR se revisa automáticamente si al menos una está activa, y aun así Copilot publica una sola review.

Dos consecuencias. La tranquilizadora: no duplicas costes por tenerlo activo en dos sitios. La desesperante: cuando algo «no revisa», tienes tres sitios donde mirar y ninguno manda.

Un apunte que sorprende: una organización puede habilitar Copilot code review para miembros sin licencia de Copilot. El revisor no necesita licencia, y el consumo se imputa al autor del PR si es automática, o a quien la pide si es manual.

La doble factura: créditos más minutos

El error de presupuesto más común es fácil de explicar: Copilot code review se cobra dos veces.

Tokens en GitHub AI Credits, donde 1 crédito equivale a 0,01 dólares.
Minutos de GitHub Actions. La infraestructura agéntica que ejecuta la revisión consume minutos del repositorio.

Los precios de plan, para contexto: Pro cuesta 10 dólares al mes con 1.000 créditos base; Pro+ 39 con 3.900; Max 100 con 10.000. En empresa, Business son 19 dólares por asiento y mes con 1.900 créditos por usuario, y Enterprise 39 con 3.900.

Y ahora el problema de verdad: en code review el modelo se elige automáticamente y no se divulga. En el resto de funciones de Copilot ves qué modelo se ha usado; aquí no. No puedes estimar el coste de una revisión con la tabla de precios por modelo, porque no sabes qué modelo trabaja. Esa opacidad es una decisión de producto, no un descuido.

Un alivio parcial: las code completions no se facturan en créditos. Siguen siendo ilimitadas en los planes de pago: el consumo de IA en tu editor no es el mismo cajón que el de tu pipeline.

La palanca más barata que casi nadie usa

Si tu workflow de review se dispara con synchronize, cada push lanza una revisión. La mitigación cuesta cuatro líneas:

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

Eso cancela la revisión del commit anterior cuando llega uno nuevo. Es la optimización con mejor relación esfuerzo-ahorro del artículo. Si además filtras drafts y PRs de bots, mejor: no gastes IA en código que no está listo.

Las alternativas, con su estado real

CodeRabbit: precio predecible

Está GA y es agente-agnóstico: GitHub, GitLab, Bitbucket y Azure DevOps, incluidos GitHub Enterprise Server y GitLab self-managed.

Sus precios, en anual: Pro 24 dólares por usuario y mes (unos 30 en mensual) y Pro Plus 48 (unos 60). Enterprise es a medida, con self-hosted desde 500 asientos. Los repos públicos son gratis para siempre y el trial son 14 días sin tarjeta.

Lo importante es la unidad de facturación: por desarrollador que abre pull requests, no por asiento. Un equipo de veinte donde solo cinco abren PRs paga cinco. Es la diferencia real frente a los planes Business y Enterprise de Copilot.

Los límites de reviews por developer son 5 en Pro, 10 en Pro Plus y 12 en Enterprise. Incluye autofix, linters y SAST, y desde el 27 de mayo de 2026 está en el Claude Marketplace. Su ventaja es clara: es predecible. Sabes cuánto pagarás a fin de mes sin abrir un panel de consumo.

Claude Code: tres productos que se confunden constantemente

Hay un lío de nombres que genera errores de presupuesto caros, porque son tres cosas distintas:

Claude Code GitHub Action. Corre en tus runners de GitHub y llama a la API de Claude (o a Bedrock, Google Cloud Agent Platform o Microsoft Foundry). El coste son minutos de Actions más tokens, o tu suscripción de Claude con token OAuth.
El code review gestionado de Anthropic. Corre en infraestructura de Anthropic, está en research preview para planes Team y Enterprise, se factura por revisión desde usage credits y tiene un promedio publicado de 15 a 25 dólares por review.
/code-review en terminal. Es uso normal de Claude Code. El modo «ultra» da tres ejecuciones gratis en Pro y Max, una por cuenta, y después suele moverse también entre 5 y 25 dólares por revisión.

El multiplicador oculto está en el segundo: si lo configuras «after every push», multiplicas el coste por cada push. Volvemos al PR del principio: diez pushes, 150 a 250 dólares. Es el gotcha económico número uno y merece estar en la checklist de cualquier equipo. Soporta GitHub y GitHub Enterprise Server; para GitLab hay una integración en beta mantenida por GitLab.

OpenCode: la opción que corre en tu runner

OpenCode publica una GitHub Action que ejecuta el agente en el runner al comentar /opencode en un issue o un PR. No voy a publicar su YAML: los inputs han cambiado entre versiones y no tengo verificada la sintaxis actual. Cópialo de su README y comprueba que la acción sigue manteniéndose.

Lo estructuralmente cierto es su ventaja: corre en tu runner, con tu token, y el diff no sale hacia un SaaS de review de terceros, solo hacia el proveedor de modelo que configures. Frente a Copilot o CodeRabbit, ese es el argumento fuerte, y también su trampa: el coste son tus credenciales más minutos de Actions, sin precio por revisión del producto.

Dependabot: agrupar sí, pero con criterio

Cambiamos de tercio. Dependabot no es IA, pero es donde la automatización ahorra horas y donde se cometen los errores más silenciosos. La herramienta útil son los grupos: un solo PR para varios updates.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: 'npm'
    directory: '/'
    schedule:
      interval: 'weekly'
    groups:
      # Todo lo que NO sea major, en un único PR
      minor-and-patch:
        applies-to: version-updates
        update-types:
          - 'minor'
          - 'patch'
      # Los major van por separado, uno a uno, para revisarlos a mano
      majors:
        applies-to: version-updates
        update-types:
          - 'major'
    open-pull-requests-limit: 5

  - package-ecosystem: 'github-actions'
    directory: '/'
    schedule:
      interval: 'weekly'
    groups:
      actions:
        patterns:
          - '*'

Dos avisos. applies-to: version-updates y el bloque groups son sintaxis actual, pero groups llegó a GHES en versiones recientes: comprueba que tu versión lo soporta. Y con grupos, open-pull-requests-limit se cuenta por grupo: un límite alto es la vía rápida a cuarenta PRs abiertos un lunes.

El auto-merge seguro, línea por línea

El patrón oficial es metadata, condición y gh pr merge --auto. Por qué es seguro: el auto-merge solo se completa cuando pasan los checks y las aprobaciones que exige la protección de rama. No salta la CI: programa el merge, no lo ejecuta a ciegas.

name: Dependabot auto-merge
on: pull_request_target

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: '${{ secrets.GITHUB_TOKEN }}'

      # Solo patch de producción: el caso seguro por defecto
      - name: Enable auto-merge for patch updates
        if: |
          steps.metadata.outputs.update-type == 'version-update:semver-patch' &&
          steps.metadata.outputs.dependency-type == 'direct:production'
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Las salidas de dependabot/fetch-metadata que te interesan son dependency-names, dependency-type y update-type, con valores como version-update:semver-patch, version-update:semver-minor o version-update:semver-major. Los permisos necesarios son contents: write y pull-requests: write, solo en este job.

Tres reglas de oro, derivadas de la documentación:

Auto-merge solo para semver-patch y direct:production. Los major, nunca.
pull_request_target tiene acceso a secrets aunque el PR venga de un fork. Filtra siempre por github.event.pull_request.user.login == 'dependabot[bot]' y por repositorio, y no hagas checkout del código del PR.
Un cooldown de unos días antes de proponer versiones recién publicadas es la mitigación directa contra ataques de supply chain tipo typosquatting o account takeover: un paquete malicioso suele detectarse en las primeras 48 a 72 horas. Comprueba que cooldown está en tu plan.

Lo que Dependabot no hace: leer breaking changes

Dependabot no analiza breaking changes. Pone el changelog y las release notes en el cuerpo del PR y etiqueta el update como semver-major. Nada más.

La revisión de breaking changes es trabajo humano o de IA, y ninguna de las dos garantiza corrección. El patrón que defiendo: los major van en PR separado, con label breaking, revisión obligatoria de Copilot o CodeRabbit y una persona que decide. La IA aquí aporta dos cosas concretas: resume el changelog y localiza los usos afectados en tu repositorio. No certifica que el bump sea correcto.

Y ojo con la frase de que «Copilot revisa los breaking changes de Dependabot automáticamente». No existe tal integración documentada. Lo que puedes montar es un workflow propio que pase el changelog al modelo, y eso lo mantienes tú.

Los cuatro riesgos que sí importan

Prompt injection desde el diff

El diff, los nombres de rama, los mensajes de commit y los comentarios son entrada no confiable dentro del prompt de un agente. Un PR desde un fork puede contener texto que instruya al modelo a exfiltrar secretos. La mitigación no es un filtro mágico: no des al agente contents: write ni secretos de producción, ejecuta con pull_request (que no expone secrets) y aprueba a mano los PRs de forks.

Acciones sin pinnear

Una acción de terceros es código que corre con tus credenciales. Pinnear a un SHA de 40 caracteres es lo mínimo, y Dependabot mantiene los pins al día con package-ecosystem: github-actions.

Permisos y credenciales

permissions: contents: read a nivel de workflow, y elevar solo en el job que lo necesite. En el job de review, persist-credentials: false en el checkout evita que el GITHUB_TOKEN quede en la configuración de git y el agente pueda leerlo. Si el agente toca AWS, GCP o Azure, usa OIDC con id-token: write en lugar de secretos de larga duración.

El coste como superficie de ataque

Un atacante no necesita tu token si puede hacerte gastar. Un PR con pushes frecuentes y review automática es un vector de agotamiento de créditos trivial. concurrency con cancel-in-progress, filtro de drafts y bots, y un timeout-minutes cierran casi toda la puerta.

Cierre: la IA revisa, tú decides

La IA en CI/CD ya no es una feature que añadir, sino una partida de gasto que gestionar. Copilot code review está GA y se activa con cuatro clics en un ruleset, no con un YAML: cualquiera de tu equipo puede encenderla un martes y cambiar la factura del mes. CodeRabbit te da previsibilidad por desarrollador. Las acciones propias te dan control sobre dónde va el código, a cambio de pagar los tokens y mantener el workflow.

Y con el auto-merge de patches, la decisión humana no desaparece: se muda al dependabot.yml.