6 puntos por GN⁺ 2025-11-01 | 1 comentarios | Compartir por WhatsApp
  • Herramienta que distingue cada línea y token con colores dentro de los cambios de código (diff) para visualizar qué tanto requieren revisión
  • Diseñada para resaltar las partes que “vale la pena volver a revisar”, en lugar de limitarse a detectar bugs
  • Se puede usar de inmediato cambiando github.com por 0github.com en la URL de un Pull Request de GitHub
  • Internamente, clona el repositorio en una VM y ejecuta gpt-5-codex para generar resultados de análisis en una estructura JSON

Descripción general

  • Esta herramienta muestra en forma de mapa de calor qué tanto debe revisarse con atención cada parte del código modificado durante el proceso de code review
  • Los colores se asignan con base en el nivel de atención humana necesario, lo que plantea un enfoque distinto al de la simple detección de errores

Cómo funciona

  • El usuario accede cambiando el dominio de la URL del Pull Request de GitHub de github.com a 0github.com
  • El sistema clona el repositorio correspondiente en una máquina virtual (VM) y ejecuta el modelo gpt-5-codex sobre cada diff
  • Luego analiza la estructura de datos JSON generada por el modelo y la convierte en un mapa de calor por colores

Criterios de análisis

  • No se enfoca solo en “si hay un bug”, sino en resaltar partes que una persona necesita volver a revisar, como secretos hardcodeados, modos de cifrado anómalos y lógica compleja

1 comentarios

 
GN⁺ 2025-11-01
Opiniones de Hacker News
  • En una base de código que ya conozco, pienso: “gracias, LLM, pero yo lo conozco mejor, así que no lo necesito”
    En cambio, si es código que no conozco, desde el principio no aprobaría el review ni haría merge
    Aun así, este uso creativo de los LLM es un intento interesante

    • Lo probé yo mismo. Elegí al azar Laravel PR #57499 y, con la configuración al 60%, solo resaltó código de pruebas y pasó por alto cambios importantes
      Tampoco mostró nada del código eliminado, y solo se resaltaban líneas sin cambios
      Fue un intento honesto, pero el resultado fue decepcionante
  • Me pregunté por qué pide incluso permiso para actuar en GitHub en mi nombre
    cmux-agent solicita acceso completo a toda la cuenta de GitHub
    Quise abrir un issue, pero la función de issues estaba desactivada en el repositorio
    Me dio una sensación un poco sospechosa

    • Si es un repositorio público, debería poder accederse sin iniciar sesión
      Lo probé en modo incógnito con PRs de ejemplo, stack-auth, tinygrad y datasette, y funcionó bien
      No sabía que los issues estaban desactivados, y ahora la página de issues ya funciona normalmente
    • Es un problema estructural de GitHub. Si ves la discusión relacionada, el modelo de permisos de OAuth App y GitHub App es distinto
      Una GitHub App puede instalarse solo en un repo específico, pero aun así incluye permiso para “actuar en nombre del usuario”
      Por eso aparece ese popup que da miedo
      Mi app codeinput.com es una OAuth App, así que solo pide el email, pero después de iniciar sesión hay que pasar otra vez por el proceso de instalación, lo que crea un flujo de autenticación complejo
    • La app exige iniciar sesión en GitHub la primera vez que se ejecuta. Antes de eso no se puede ver nada
  • La dirección es interesante, pero la relación costo-beneficio no está clara
    A los LLM todavía les cuesta entender el contexto de un proyecto usando solo el diff de un PR
    De hecho, un heatmap basado en datos usando bugs pasados o frecuencia de cambios probablemente sería más confiable

    • Si usas una clave gratuita de Gemini, el volumen diario de solicitudes alcanza de sobra, así que para un equipo pequeño (10~20 PR al día) no sería un gran costo
      Sería aún mejor si pudiera ejecutarse con una clave personal
    • Me pregunto si existirá alguna herramienta similar que analice la entropía del diff
    • Nosotros también hicimos antes un experimento clonando repos en una VM para explorarlos con Codex, pero lo dejamos por problemas de latencia y costo
      Parece que con distillation se podría bajar el costo, pero todavía estamos experimentando
      También estamos pensando si habrá una forma de calcular la correlación con bugs pasados sin usar LLM
    • Al hacer code review, a menudo termino mencionando líneas que no están en el diff
      Estas herramientas al final solo pueden resolver una parte del problema
    • Que una parte del código cambie con frecuencia no significa necesariamente que tenga más bugs
      También puede ser un área donde la gente pone más atención
      Sería interesante validarlo con datos de open source
  • Me alegró ver que mi PR apareció en HN
    Estaría bien poder dejarlo con umbral de 0% y ajustar con más variedad el gradiente de colores
    También me pregunto si este tool podría usarse para revisar por adelantado código generado por IA antes de crear el PR

    • Está previsto que los colores y el gradiente se puedan configurar
      También me gustaría conocer opiniones sobre si tendría sentido una forma de comando para renderizar el diff en CLI o HTML
    • Al final, usar herramientas así puede terminar tomando más tiempo que programar directamente
  • El nombre de dominio 0github.com parece difícil de mantener a largo plazo. Sería bueno buscar pronto otro dominio

    • Me da curiosidad por qué
  • Parece especialmente útil para PRs enormes
    En lugar de un slider, estaría bien poder hacer clic por color para ver de inmediato el significado
    Ahora no es fácil entenderlo de un vistazo, pero si se usa seguido uno probablemente se acostumbre

    • Actualmente, al pasar el mouse sobre las palabras resaltadas se muestra un tooltip
      Pienso mejorarlo para que también se vea en móvil. Me pregunto si habría otra forma de mostrarlo que sea mejor
  • Lo probé en un PR simple de Rust y funcionó bastante bien
    Eso sí, estaría bueno poder ajustar con más detalle la posición de los resaltados
    Me impresionó que detectara un typo casi invisible en el PR de un colega
    Link al PR probado
    Muestra parte del código eliminado, pero ignora mucho
    Me preguntaba si tal vez calcula la distancia entre tokens

    • La implementación está en este archivo
      Por ahora se basa en un prompt simple con LLM
      Más adelante podría evolucionar hacia un método de detección de tokens alucinados. Voy a buscar papers relacionados
  • Últimamente, con tantos PRs grandes generados por IA, sentí la necesidad de una herramienta así
    Estaría bueno que aprendiera el estilo del reviewer para dar reviews personalizados
    Estoy verificando si este commit es el correcto

    • La lógica principal está en este archivo
      Estamos experimentando con un sistema DSPy para hacer reviews automatizados adaptados a las preferencias del reviewer
  • En realidad, es más importante hacer PRs de tamaño razonable para no necesitar herramientas así
    Últimamente reviso PRs escritos con IA, y hasta la IA responde a mis comentarios
    Al final, parece que viene una época en la que hasta los reviewers serán reemplazados por IA

  • Hice clic en un PR de ejemplo y se quedó cargando sin parar. Parece que hace falta caching

    • Se supone que ya debería haber caching, lo estoy revisando
    • Ya quedó corregido. Ahora funciona normalmente