Revisión de código automatizada en 2026: haz que se ejecute en cada PR sin comprar un asiento

La revisión automatizada de código es un trabajo de CI que envía tu diff a un modelo de lenguaje, publica los hallazgos en las líneas afectadas y hace fallar una verificación de estado cuando encuentra algo grave. La forma de lograr que esto se ejecute en cada pull request sin una suscripción por asiento es autoalojar un sistema de código abierto: copia un flujo de trabajo de aproximadamente quince líneas en tu repositorio, añade una clave de API y paga solo por los tokens que consuma cada revisión. No hay cantidad de asientos que comprar, porque no hay asiento. La implementación de referencia que mantenemos esel repositorio Orca-Code-Review — público, con licencia MIT y, desde su creación el 25 de junio de 2026, el código detrás de la GitHub Action OrcaCode Review. La receta de enrutamiento que incluye establece por defecto el pase de revisión en DeepSeek V4 Flash y el juez de verificación independiente en GLM-5.3, y ambos puedes cambiarlos. Este artículo explica qué se ejecuta realmente en cada push, qué configuras, cuánto cuesta en tokens y los modos de fallo que encontrarás en la segunda semana.

La versión corta. Cada push recibe una revisión. Los hallazgos se publican en línea en las líneas modificadas. Los hallazgos P0 y P1 hacen fallar la verificación y bloquean la fusión; una ejecución limpia pasa. Puedes volver a revisar a pedido comentando /orcacode-review. El flujo de trabajo vive en tu repositorio; la lógica de revisión vive en la acción publicada; la elección del modelo vive en una receta de enrutamiento que puedes editar en tu propio espacio de trabajo. El revisor lee el diff y los archivos del repositorio y nunca ejecuta el código de tu PR. Y la advertencia honesta desde el principio: detecta errores reales y aun así se le escapan los que necesitan a un humano que sepa por qué el código es como es.

• Un flujo de trabajo + un secreto + una factura de tokens. Sin licencia por usuario en ningún momento.

• El harness es de código abierto. Cópialo, hazle fork, audítalo, anclalo a un SHA de commit.

• El modelo es una configuración, no un proveedor. Cambie el revisor editando una receta de enrutamiento, no reescribiendo YAML ni modificando la acción.

• Los diffs sobredimensionados no cuestan nada. La comprobación de tamaño se ejecuta antes que el modelo.

• Lee tu código, nunca lo ejecuta. Esa es la propiedad de seguridad que hace que pull_request_target sea seguro de usar.

Cómo funciona realmente la revisión de código automatizada

Todo sistema de revisión automatizado no es otra cosa que los mismos tres ingredientes con ropas diferentes: un evento, un ejecutor y un revisor.

El evento es el desencadenante. El flujo de trabajo incluido se activa en eventos de pull request — opened, synchronize (un nuevo push), ready_for_review (un borrador pasa a estar listo) — y en un comentario de PR. Debido a que se ejecuta en pull_request_target, la definición del flujo de trabajo se lee desde la rama base, por lo que el flujo de trabajo debe existir en la rama base antes de poder ejecutarse para un PR. Una revisión por push; el concurrency es un bloque que cancela la ejecución anterior, por lo que una secuencia rápida de pushes no pone en cola cinco revisiones de código obsoleto.

El ejecutor es GitHub Actions en ubuntu-latest. El trabajo necesita tres permisos: acceso de lectura a contenidos, acceso de escritura a pull requests (para publicar comentarios en línea), y acceso de escritura a issues (para publicar el resumen y limpiar comentarios obsoletos).

El revisor es un modelo de lenguaje. La acción obtiene la cabeza de la PR, ensambla el diff y el contexto del repositorio que selecciona el motor, y lo envía al modelo de revisión. El resultado es un conjunto de hallazgos, cada uno etiquetado con una gravedad y anclado a un archivo y una línea. La acción los publica como comentarios en línea de la PR y escribe un comentario resumen en una región marcada en la parte superior de la descripción de la PR, que se reemplaza en su lugar en cada push.

La compuerta es una verificación de estado. GitHub no sabe qué significa “review”; solo sabe si el review check pasa. Haces que la compuerta sea real marcando ese check como requerido en la protección de ramas. Ese es todo el mecanismo de bloqueo de merge — sin llamadas a la API de administración, sin etiquetas, solo un check requerido que falla.

Lo que no sucede: nada ejecuta el código del PR. El motor solo lee. Ese único invariante es lo que hace que el desencadenador privilegiado pull_request_target sea seguro de usar con una clave de API de pago.

El harness de código abierto es el diferenciador.

Todo lo anterior es cierto para muchas herramientas. Lo que no es cierto para la mayoría es que todo el conjunto es inspeccionable y autoalojable, que es lo que te ofrece el repositorio Orca-Code-Review. Es un repositorio público de GitHub con licencia MIT (JavaScript, creado el 25 de junio de 2026) que empaqueta la revisión como una GitHub Action compuesta reutilizable más un instalador, y es el mismo código que la aplicación alojada OrcaCode Review ejecuta.

Pasa diez minutos en el árbol y podrás nombrar cada pieza que toca tu PR:

• action.yml — la acción compuesta, con unas quince entradas documentadas. No hay nombres de modelos codificados en ninguna parte de ella.

• workflows/orca-code-review.yml — el flujo de trabajo de consumidor de ejemplo, las aproximadamente quince líneas que copias en .github/workflows/.

• recipes/ — el DSL de enrutamiento. Aquí es donde realmente se elige el modelo.

• rules/ — la rúbrica de severidad (P0–P3), el formato de salida obligatorio y una directiva de convenciones que alimenta la revisión con el documento de convenciones del propio proyecto como datos de referencia no confiables.

• scripts/ — el filtro de precisión (L1 más un juez L2), el protector de diff, la compuerta de merge, el informe de ejecución y el medidor de tokens. Cada uno es un archivo .mjs pequeño y legible con pruebas.

• skills/setup-orca-code-review — la habilidad que el instalador coloca en tu agente de codificación, y que cubre instalación, reconfiguración, solución de problemas y desinstalación.

• .claude-plugin/ — lo que permite que Claude Code instale la habilidad como un plugin que se autoactualiza.

Instalar es una línea que le enseña a tu IA qué es el producto y luego se detiene:

npx @orcarouter/code-review

La CLI detecta qué agentes de codificación usas — el catálogo abarca 36 plataformas, desde Claude Code, Cursor, Codex, OpenCode y Windsurf hasta GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode y otros — instala la habilidad y se retira. Luego le preguntas a tu agente en lenguaje natural:“configura OrcaCode Review en este repositorio,” “bloquea solo P0,” “¿por qué no se ejecutó la revisión?” La habilidad se encarga del ciclo de vida: escribe el flujo de trabajo, te guía a través de la clave API, establece el gate y solo plantea las preguntas que realmente te pertenecen.

Claude Code puede instalar la habilidad como un plugin en su lugar, lo que la mantiene actualizada a medida que el repositorio cambia:

/plugin marketplace add Continuum-AI-Corp/orca-code-review

/instalar plugin orca-code-review

¿Nada de agente? El mismo ciclo de vida son simples subcomandos — init escribe el flujo de trabajo, reconfigure cambia las reglas de bloqueo y los límites de diff, doctor diagnostica revisiones que no se ejecutan o no se publican, uninstall lo elimina (quitando primero la verificación requerida). La skill es la puerta principal, no la única puerta. O conéctalo manualmente: copia el flujo de trabajo, añade un secreto llamado ORCAROUTER_API_KEY y marca la revisión como requerida.

El motor subyacente es Open Code Review de Alibaba, fijado a una versión exacta y con licencia Apache-2.0. OrcaCode decide cómo revisar; OrcaRouter decide qué modelo lo ejecuta. El balance entre autoalojamiento y alojamiento gestionado — lo que “gratis” realmente cuesta cuando autoalojas un revisor de código abierto — se explica en nuestro artículo sobre revisión de código abierto.

¿Qué se ejecuta, en orden, en cada push?

Ayuda conocer el orden, porque cada paso puede fallar u omitirse de forma independiente:

• El guardián de diff se ejecuta primero, antes de que el modelo lo haga. Si el diff de merge-base supera 512 KB o afecta a más de 300 archivos, la revisión se omite y se publica un aviso. El valor predeterminado es on-oversized-diff: fail, por lo que un diff inflado más allá de los límites no puede atravesar una compuerta obligatoria sin revisión. Esto también es el control de gasto: un PR sobredimensionado cuesta cero tokens.

• El motor revisa el diff. Una pasada, con concurrencia por archivo cuyo valor predeterminado es 24, y un tope de tiempo real de 20 minutos por pasada.

• El filtro de precisión posprocesa los hallazgos en bruto. L1, un filtro determinista, verifica el fragmento de código existente reclamado por cada hallazgo contra el commit revisado y reubica o descarta las discrepancias. L2, un juez LLM, agrupa los hallazgos por causa raíz y descarta los clústeres de baja confianza. Ambas capas son de fallo suave: un error conserva los hallazgos de la etapa anterior y nunca aborta la revisión.

• El gate aplica. Los hallazgos P0 y P1 hacen fallar la verificación; el resumen del PR cuenta todos los hallazgos, incluidos los silenciados del diff.

• El medidor imprime lo que costó.La entrada del medidor registra la contabilidad de tokens por llamada — prompt, finalización, tokens en caché y el modelo que resolvió el enrutador — e imprime una tabla de totales en el registro del trabajo.

• Un informe de ejecución opcional envía conteos de severidad y metadatos de compuerta al plano de control de OrcaRouter para el panel de análisis. No contiene código, ni diff, ni texto de hallazgos.

Lo que realmente configuras

Hay tres superficies, y tienen radios de explosión muy diferentes.

1. El archivo del flujo de trabajo. El flujo de trabajo de consumo es deliberadamente ligero. Las entradas que vale la pena tocar residen en la acción: block-on (qué severidades hacen fallar la comprobación — por defecto P0,P1), fix-first (qué severidades detienen temprano una revisión exhaustiva), auto-review-authors (una lista de permitidos para quién recibe revisión automática), max-diff-kb y max-diff-files y on-oversized-diff (la protección de tamaño), timeout-minutes, concurrency, meter, y report. Cada uno tiene un valor predeterminado documentado, así que un flujo de trabajo nuevo consta de cinco líneas de YAML más un secreto.

2. El panel. Con settings: true (el valor predeterminado), cada ejecución obtiene la configuración por repositorio de OrcaRouter → Apps → OrcaCode Review: el modelo, el modo de revisión, la política de merge, los niveles de severidad de los informes, el modo silencioso, la revisión exhaustiva, una rúbrica personalizada y las salvaguardas. Establece settings: "false" y el archivo de flujo de trabajo tiene la última palabra — ningún valor del panel puede anularlo. Si nunca abres la consola, no pierdes nada del andamiaje; solo configuras en YAML.

3. La receta de enrutamiento — la que la gente pasa por alto. La acción nunca nombra un modelo. En cambio, inyecta hechos en bruto como cabeceras de petición — en qué nivel se registró la ejecución, si la pasada anterior encontró un P0/P1, y un marcador de lente cuando la solicitud es el juez L2 — y la receta DSL del router del espacio de trabajo mapea esas cabeceras a un modelo concreto. La receta incluida establece la revisión por defecto como DeepSeek V4 Flash y el juez como GLM-5.3, enrutando los dos a modelos separados a propósito. Cambiar el modelo que revisa tu código es una edición a esa receta en tu propio espacio de trabajo: sin incremento de versión de la acción, sin reescritura de YAML, sin redespliegue.

El contrato de severidad son dos ajustes independientes, no uno. Política de merge decide qué bloquea el merge; severidades de reporte decide qué se publica en el diff. Los valores predeterminados son: P0/P1 bloquean, P2/P3 pasan. Una severidad que bloquea siempre se publica, sin importar lo que diga el ajuste de reporte — una verificación fallida sin nada en el diff que la explique es peor que una que genere ruido. P0 significa una vulnerabilidad de seguridad explotable, pérdida de datos, un cierre inesperado en una ruta normal o una compilación rota; P1 significa un error real pero contenido; P2 significa un defecto genuino que solo se dispara bajo una precondición anormal; P3 es estilo. Cuando se duda entre dos niveles, la rúbrica dice que se elija el más bajo.

Lo que cuesta

Por token, no por asiento. Tú eliges el modelo en OrcaRouter, la facturación se calcula por token consumido, y el medidor hace que el número por ejecución sea visible en lugar de misterioso. Los mecanismos de GitHub, la revisión de código medida de Copilot desde el 1 de junio de 2026, y cómo se integran los revisores de terceros en ese flujo de trabajo se tratan en nuestra guía de revisión de código de GitHub. La comparación completa de costos campo por campo — productos por asiento vs. productos por token, con un ejemplo práctico — está en nuestra comparación de herramientas de revisión de código con IA, y la pregunta de cuánto cuesta en tokens una sola pasada de revisión cuando el revisor realmente explora el repositorio (la distinción bot-vs-agente) está en nuestro artículo sobre agentes de revisión de código. El punto que aporta este artículo es la forma de la factura: se escala con el código que revisas, no con el número de personas que lo revisan.

Dos controles de gasto son importantes desde el primer día. En un repositorio público, pull_request_target omite la compuerta de aprobación de forks de GitHub, y la clave de revisión se mide por cartera: un desconocido puede abrir un PR y activar revisiones pagadas. Establece un presupuesto de cartera con alertas en la clave, y configura auto-review-authors con algo como OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR para que los contribuyentes desconocidos no se revisen automáticamente. Y el guardián del diff, como se indicó, hace que los PRs demasiado grandes no cuesten nada.

Qué se rompe

La revisión automatizada es CI. Se rompe como CI, y los modos de fallo no son en su mayoría culpa del modelo:

• El flujo de trabajo nunca se ejecuta. Para pull_request_target el flujo de trabajo se lee desde la rama base — un flujo de trabajo añadido solo en la rama del PR no se ejecutará hasta que se fusione. También comprueba que la aplicación esté habilitada, que auto_review esté activado, que el PR no sea un borrador (los borradores se omiten en el modo ready_for_review) y que las Actions estén habilitadas en el repositorio (los repositorios bifurcados vienen con ellas desactivadas).

• /orcacode-review no hace nada. El desencadenante del comentario requiere que el comentario comience con una de cuatro grafías — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — y que quien comenta sea PROPIETARIO, MIEMBRO o COLABORADOR. Un espacio inicial invalida la coincidencia. El comando de un contribuidor externo se ignora silenciosamente, a propósito: el comando ejecuta un flujo de trabajo privilegiado que contiene la clave de pago.

• Un error de autenticación. El secreto tiene un nombre incorrecto o falta, la clave está revocada o fuera de presupuesto, o el flujo de trabajo se cambió a pull_request (que no puede leer secretos de los forks).

• La verificación está en rojo con un aviso de “diff too large”. Ese es el guardián de tamaño, funcionando según la configuración. Divide el PR, o aumenta los límites, o configura on-oversized-diff: pass — y entiende que, con una verificación obligatoria, pass significa que un PR lo suficientemente grande pasa directamente por la puerta sin revisión.

• La revisión se ejecuta, pero no aparecen comentarios. Tres causas, todas inofensivas o de configuración: una ejecución limpia publica un resumen en lugar de comentarios en línea; el modo silencioso está silenciando P2 al momento de publicar (el gate y el informe siguieron contándolo); o el filtro de precisión descartó los hallazgos — L1 descarta hallazgos cuyo snippet no coincide con el commit, L2 descarta clústeres de baja confianza. Los conteos de severidad del log del trabajo te indican cuál.

La postura de seguridad merece ser expuesta claramente porque es lo que hace seguro todo el diseño. El motor solo lee el diff y los archivos del repositorio; nunca ejecuta código del PR. El revisor no tiene autoridad para fusionar; los hallazgos pueden bloquear una fusión o añadir un comentario, pero ninguna ruta de código permite que la salida del modelo apruebe o modifique el repositorio. Un hallazgo no etiquetado falla de forma segura, tratándose como bloqueante en lugar de como asesoramiento. Y el informe de ejecución no contiene código ni texto de hallazgos. La configuración de dos capas que detecta lo que una revisión de una sola pasada pasa por alto es el tema de nuestro artículo sobre seguridad en la revisión de código con IA; el modelo de amenazas anterior está documentado en el SECURITY.md del repositorio.

Cuando la revisión automatizada es la herramienta equivocada

Está equivocado más a menudo de lo que admiten los proveedores de herramientas. No participes en este cuando:

• El problema es el contexto, no el volumen. Si las revisiones son lentas porque los revisores deben entender por qué el código se escribió de esta manera, un LLM que lea el diff aporta poco. No tiene memoria del hilo del mes pasado ni sentido de la historia del sistema.

• El diff es en su mayoría código generado o de terceros. Salida con formato automático, archivos generados, instantáneas de dependencias. Revisarlo consume tokens y produce ruido, y es exactamente donde la directiva de convenciones ayuda menos — el código no sigue el estilo del proyecto por elección.

• El equipo ya revisa todo en parejas. La revisión automatizada es una palanca de escala. Si cada cambio ya es revisado por un humano que estuvo en la sala, la máquina aporta una segunda opinión que suele estar menos informada que la primera.

• Nadie lee los hallazgos. Una revisión en la que nadie actúa es un flujo de trabajo que falla en verde para siempre. Este es el fallo silencioso más común, y ningún filtro de precisión lo soluciona.

• La revisión debe ejecutar el código. Si lo que necesitas es un conjunto de pruebas para el PR, una revisión con LLM es la herramienta equivocada. Lee; no ejecuta. Un escaneo de seguridad que necesite compilar y ejecutar el artefacto pertenece a un trabajo separado y cuidadosamente delimitado — recuerda que el flujo de trabajo de revisión nunca debe ampliarse para ejecutar código controlado por el PR.

• El repositorio es diminuto o desechable. Por debajo de cierta tasa de cambios, la revisión es más sobrecarga que los errores que detecta.

Falsos positivos, y qué arregla y qué no el filtrado de precisión.

La acusación contra todo revisor de IA es que da falsas alarmas. El arnés aborda esto en dos capas, y conviene ser preciso sobre qué capa corrige qué fallo.

La capa determinista (L1) elimina el hallazgo fantasma: un motor a veces afirma código que no está allí — un fragmento que se desvió, un hallazgo copiado a un archivo hermano. L1 verifica el fragmento de código existente de cada hallazgo contra el commit realmente revisado y reubica o descarta las discrepancias. Eso corrige la clase de falso positivo de «esta línea ni siquiera existe», que es mecánica y verificable.

La capa de juez (L2) elimina el duplicado y la afirmación no respaldada: un juez LLM agrupa los hallazgos por causa raíz y descarta los grupos cuya confianza cae por debajo del umbral del juez (por defecto 0.5). Eso corrige el “mismo error reportado de tres maneras” y el hallazgo especulativo.

Lo que ninguna capa corrige merece decirse en voz alta. Un hallazgo equivocado pero seguro sobrevive al juez — el juez es un LLM, y un LLM que suena seguro no es lo mismo que un hallazgo que es verdadero. Un juez que se ejecuta en el propio modelo del revisor se da la razón a sí mismo y la verificación se vuelve inerte mientras sigue reportando éxito; por eso la receta que viene con el producto enruta el juez a un modelo distinto del revisor. Y la rúbrica de severidad es deliberadamente conservadora — “cuando dudes entre dos niveles, elige el más bajo” — lo que significa que un error real pero condicional tiene más probabilidades de clasificarse como aviso P2 que como P1 bloqueante. Esa es la calibración correcta para una herramienta que no debe bloquearlo todo, pero es una calibración: intercambia bloqueadores omitidos por menos falsas alarmas. El resumen del PR siempre cuenta todos los hallazgos, así que los P2 atenuados siguen ahí para leerse. Si el equilibrio no es el adecuado para tu equipo, la rúbrica y el umbral del juez son configuración, no un ticket de soporte.

El resultado final

Para un equipo que ya vive en GitHub Actions, la herramienta de código abierto es la forma más barata de obtener revisión de código automatizada en cada PR: un archivo de workflow, un secreto, una factura de tokens que escala con el código revisado y una elección de modelo que tú controlas. Compra un producto por usuario cuando quieras cero operaciones y un proveedor al que llamar — no porque la revisión sea mejor, sino porque estás externalizando el problema en lugar de gestionar el tuyo propio. Y antes de configurar cualquier cosa, pregunta si la revisión será leída. La herramienta puede hacer que la revisión ocurra automáticamente. No puede hacer que nadie la lea.

¿Quieres el mismo revisor sin ejecutarlo tú mismo? OrcaCode Review ejecuta este mismo harness como una GitHub App alojada: misma receta abierta, misma factura por token, sin asientos.