Farol: mapa de riesgo de un PR antes de aprobarlo

El cuello de botella se mudó a la revisión

Un estudio de investigadores de Harvard sobre más de 700 empresas y 300 millones de eventos de trabajo encontró que los agentes de IA aumentan un 30% las líneas de código generadas, un 20% los commits y un 23% los pull requests — pero el ritmo de resolución de features no cambia de forma significativa. Según Ars Technica, la revisión humana se convirtió en el cuello de botella: los pull requests requieren más rondas de corrección y los revisores dejan más comentarios.

Ese es exactamente el hueco que ataca farol, una CLI y GitHub Action gratuita y open source (licencia MIT) publicada por Winnin. Su premisa es simple: los agentes escriben el código y los agentes lo revisan, pero la última decisión sigue siendo de una persona. Y esa aprobación, repartida por igual entre todos los pull requests, se convierte en un vistazo rápido — que es como un cambio de una línea en un hook compartido tumba cuarenta páginas.

¿Qué es farol y en qué se diferencia de tu revisor con IA?

farol (portugués para "faro") no reemplaza a tu agente de revisión: llega después. El agente comenta las líneas del diff; farol le dice a quien aprueba cuál es el riesgo de aceptar el cambio y dónde vive ese riesgo.

La diferencia clave está en cómo lee el código. Mientras un agente de IA lee el diff y lo que quepa en el prompt, farol analiza el programa completo en la base y en la cabeza de la rama usando los compiladores reales: el type checker de TypeScript, go/types y el ast de Python. El resultado es determinista: el mismo pull request siempre produce el mismo reporte, y cada afirmación viene con su cadena de llamadas.

El equipo de Claude Code describe el mismo principio en su documento sobre cómo hace code review: el esfuerzo de revisión sigue el riesgo del cambio. Como lo formulan ahí, "el cambio define el nivel, no el autor".

¿Cómo decide farol cuánto riesgo tiene un merge?

El reporte entrega tres cosas antes de que el revisor abra el diff:

• A qué llega el cambio: cada página, operación de API, método RPC, job y script existente que ejecuta el código modificado, con la cadena de llamadas hasta cada uno.
• Qué tan riesgoso es el merge: un veredicto (fast track, quick review o careful review) y un puntaje de 0 a 100 que combina alcance, cobertura del diff, hallazgos de seguridad, rupturas de contrato y cambios de dependencias.
• Por dónde empezar: los archivos más riesgosos primero, con diffs en línea, líneas sin tests marcadas y una lista de qué probar a mano.

El veredicto careful review se dispara con un puntaje de 60 o más, una ruptura de contrato, un hallazgo de severidad alta, un archivo central sin tests o código que farol no pudo leer. Y cuando no puede leer una parte del cambio, lo dice explícitamente (unknown) y pide revisión cuidadosa: nunca declara algo seguro porque no lo entendió.

¿Qué significa esto para tu startup?

Si tu equipo ya usa un agente de IA para revisar código, el problema no es la falta de comentarios: es que nadie tiene tiempo de leerlos todos. Estos son los movimientos concretos:

• Corre farol después de tu agente de revisión, no en lugar de él. Los dos comentarios conviven en el PR y ninguno bloquea el merge. El agente cubre las líneas; farol cubre el alcance.
• Reutiliza los reportes que tu CI ya produce. Cobertura, lint, seguridad y auditoría se convierten en cobertura del diff y hallazgos sobre las líneas cambiadas. Nada corre dos veces, así que no agregas minutos de pipeline.
• Usa el reporte incremental en la segunda ronda. Cada push genera dos reportes: el pull request completo y solo los commits desde el push anterior. Después de una ronda de correcciones, revisas lo nuevo en lugar de empezar de cero.
• Calibra los umbrales con tu propio historial. El comando farol calibrate corre sobre tus commits pasados. En la validación del proyecto sobre 662 commits de cuatro repositorios, fast track tuvo cero problemas en 56 commits y el AUC del puntaje quedó entre 0,72 y 0,83 — pero los umbrales son heurísticas y el propio equipo recomienda ajustarlos a tu repositorio.

Hay un dato de contexto que refuerza la urgencia: según InfoWorld, solo el 16% del tiempo de un desarrollador se dedica a escribir código, y en la encuesta State of Code de Sonar el 96% de los desarrolladores no confía del todo en la salida de la IA, aunque solo el 48% la verifica siempre antes de hacer commit. El mismo medio cita el reporte de CodeRabbit según el cual el código generado por IA puede producir 1,4 veces más issues críticos que el escrito por personas, y el informe de Qodo sobre la paradoja del código con IA, donde el 89% de los equipos enterprise ya sufrió un incidente en producción causado por código generado por IA.

¿Cómo lo pruebas en tu repositorio hoy?

El arranque es deliberadamente corto. Necesitas Node.js 22+ y git (más Go o Python 3.11+ si tu proyecto los usa) y no instalas nada:

• Describe tu proyecto en un farol.config.json en la raíz. Una línea alcanza: { "routes": { "adapter": "next" } } para Next.js, o { "language": "python", "surface": "backend" } para un servicio en Python.
• Verifica qué ve farol con npx @winninjs/farol routes, que lista tus páginas, endpoints, jobs y scripts.
• Analiza una rama contra su base: npx @winninjs/farol analyze --base origin/main --head HEAD --out farol.json, y abre el reporte HTML con npx @winninjs/farol html.

farol corre en tu máquina o en tu runner de CI, nunca ejecuta tu código y nunca lo envía a ningún lado. En CI, el job que corre tus tests no tiene secretos ni token de escritura, y el job que comenta nunca ejecuta tu código. Está en modo sombra: informa, nunca aprueba, nunca pide cambios y nunca falla un check.

El soporte cubre React Router, Next.js, TanStack Router, APIs en TypeScript, Go y Python, con integración opcional de Datadog para ver tráfico y errores de producción de las páginas afectadas — información que se muestra pero que no altera el puntaje.

Conclusión

La adopción de agentes de IA está multiplicando el volumen de código que llega a revisión, y el límite real ya no es escribir: es decidir qué merece atención. Herramientas como farol no prometen revisar por ti; prometen decirte dónde mirar, con análisis estático y determinista en lugar de una corazonada probabilística. Para un equipo pequeño con un solo revisor senior, eso puede ser la diferencia entre aprobar a ciegas y aprobar con criterio.

Fuentes

• farol – winnin/farol (GitHub) (fuente original)
• AI coding agents generate more code, but not more software (Ars Technica)
• Five tools to bolster your AI coding stack (InfoWorld)