Resumen

Este revisor de código con IA es en realidad un checker de pre-revisión basado en reglas. Pegas un git diff o un fragmento y escanea las líneas añadidas con trece reglas: secretos hardcodeados, SQL construido con cadenas, excepciones silenciadas, tests desactivados y restos de debug. Además marca cambios demasiado grandes o sin tests y devuelve una puntuación de 0 a 100 con hallazgos numerados por línea. Todo se ejecuta en tu navegador, no usa ningún modelo de IA y sirve para limpiar los problemas mecánicos antes de que lo revise una persona.

Revisa tu diff antes de que lo haga un revisor

Pega un git diff o un fragmento. Este revisor de código con IA gratuito marca secretos, SQL inseguro, errores silenciados, código de debug olvidado y cambios demasiado grandes en tu navegador, y da al pull request una puntuación sobre 100.

Revisar mi diff
Ingeniero revisando un diff de código lado a lado en un monitor

Checker de diff antes de la revisión

Pega un diff unificado o cualquier código. Solo se revisan las líneas añadidas cuando se detecta un diff. Nada de lo que pegas sale de tu navegador.

--/100
Pega código para empezar
Todavía no se ha revisado nada.
    Cómo funciona

    Qué mira el checker y qué ignora

    Solo líneas añadidas

    Si pegas un diff unificado, el checker lee las cabeceras de hunk, cuenta los números de línea del archivo nuevo y escanea solo las líneas que añadiste. Las líneas eliminadas y el contexto sin cambios nunca generan un hallazgo, así que no te penaliza código antiguo.

    Puntuación ponderada por severidad

    Trece reglas en tres niveles. Alta resta 15 puntos: secretos hardcodeados, eval, SQL construido con cadenas, comprobaciones TLS desactivadas. Media resta 7: excepciones silenciadas, tests marcados como focus, innerHTML, un diff de 400 líneas. Baja resta 2: TODOs, prints de debug, código comentado. Cada regla cuenta como máximo tres veces.

    Comprobaciones de tamaño y de tests

    Por encima de 200 líneas añadidas recibes un aviso para dividir el cambio; por encima de 400, un aviso más firme. Sigue el hallazgo del estudio de SmartBear sobre Cisco: la calidad de la revisión baja cuando un revisor se enfrenta a más de 200 a 400 líneas a la vez. Un diff de más de 50 líneas añadidas sin archivo de tests también se marca.

    Cómo usarlo

    Del pegado a un pull request limpio en cuatro pasos

    1. 1

      Pega tu diff

      Ejecuta git diff main...HEAD, o git diff --staged antes de hacer commit, y pega la salida. Un fragmento suelto también sirve, pero pierdes los nombres de archivo y la detección de archivos de test.

    2. 2

      Lee primero los hallazgos altos

      Los elementos en rojo son los que un revisor va a frenar. Una clave hardcodeada en un commit queda en el historial aunque borres la línea, así que rótala en lugar de limitarte a quitarla.

    3. 3

      Corrige o justifica el resto

      Cada hallazgo incluye una corrección de una línea. Si una alerta es un falso positivo, dilo en la descripción del PR. Así evitas que el revisor haga la misma pregunta.

    4. 4

      Copia el checklist

      El botón de copiar convierte los hallazgos en un checklist en markdown que puedes pegar en el cuerpo del PR, para que el revisor vea lo que ya detectaste.

    Por qué una pre-revisión

    Los primeros treinta segundos de una revisión no deberían gastarse en console.log

    Abres un pull request de un compañero y conoces la rutina. Recorres el diff, detectas un print de debug olvidado, un TODO sin ticket, un test saltado y un bloque catch que se traga el error. Nada de eso necesita a una persona. Necesita un checklist que se ejecute antes de que salga la petición. Ahí es donde encaja esta herramienta. La atención de un revisor es limitada: el estudio de SmartBear sobre revisiones de Cisco encontró que la detección de defectos se mantiene cuando se revisan 200 a 400 líneas en 60 a 90 minutos, y se degrada a partir de ahí. Cada minuto dedicado a hallazgos mecánicos es un minuto que no se dedica a las preguntas que solo una persona puede responder: ¿es este el enfoque correcto?, ¿encaja con la arquitectura?, ¿seguirá teniendo sentido dentro de seis meses? No sustituye a un revisor y no finge hacerlo. Quita las objeciones baratas para que la revisión humana empiece por la parte interesante.

    • Detecta los hallazgos mecánicos antes de que salga la petición de revisión
    • Asigna a cada hallazgo un número de línea tomado de las cabeceras del diff
    • Se ejecuta en local, así que es seguro pegar código propietario
    Dos ingenieros comentando un cambio de código frente a un portátil
    FAQ

    Preguntas sobre el checker

    ¿Es un revisor de código con IA o un linter?
    Ni una cosa ni otra, estrictamente. Es un checker de pre-revisión basado en reglas. Ningún modelo lee tu código y no se genera nada. Trece reglas de patrones escanean las líneas añadidas en busca de lo que un revisor marca en los primeros treinta segundos: secretos, SQL construido con cadenas sin protección, excepciones silenciadas y salida de debug olvidada. Lo decimos sin rodeos, porque un revisor con IA que adivina es peor que un checklist que no adivina.
    ¿Sale mi código de mi navegador?
    No. Las comprobaciones se ejecutan en JavaScript en esta página. No hay subida, ni llamada a una API, ni cuenta. Lo único que se registra es un evento anónimo de que se usó la herramienta, sin contenido del cuadro de texto.
    ¿De dónde salen las reglas de 200 a 400 líneas y de archivos de test?
    El umbral de tamaño sigue el estudio de SmartBear sobre datos de revisiones de Cisco, que recomienda revisar no más de 200 a 400 líneas a la vez. La regla de cambios pequeños sigue las prácticas públicas de ingeniería de Google sobre CLs pequeños. La regla de tests que faltan es una convención nuestra: un diff con más de 50 líneas añadidas y sin archivo de test recibe un aviso, porque es una pregunta que los revisores hacen de todos modos.
    ¿Cómo se calcula la puntuación?
    Empieza en 100. Cada hallazgo resta puntos según su severidad: 15 por alta, 7 por media y 2 por baja. Cada regla cuenta como máximo tres veces, así que una regla ruidosa no puede dejar la puntuación en cero. Es una convención para ordenar el trabajo, no una medida de la calidad del código. Un 100 significa que ninguna regla se activó, no que el código sea correcto.
    ¿Qué se le escapa?
    Todo lo que requiere entender: lógica de negocio incorrecta, condiciones de carrera, una mala abstracción, una API que no envejecerá bien. Las reglas por expresión regular también dan falsos positivos, por ejemplo un fixture de test que contiene una contraseña falsa. Trata cada hallazgo como una pregunta que hay que responder, no como un veredicto.
    ¿Con qué lenguajes funciona?
    Las reglas son patrones de texto, así que funcionan con JavaScript, TypeScript, Python, Java, Go y la mayoría de código de la familia C. Algunas reglas son específicas de un lenguaje: except sin tipo es de Python, System.out.println es de Java, InsecureSkipVerify es de Go. Pega un git diff unificado y los números de línea salen de las cabeceras de hunk.
    ¿Es gratis?
    Sí, sin registro. Si mientras revisas quieres respuestas sobre el resto de tu repositorio, como quién llama a esta función o dónde se lee un valor de configuración, para eso está codebasechat.

    Revisa con todo el repositorio a la vista

    Un diff muestra lo que cambió, no lo que toca. codebasechat responde preguntas sobre tu base de código en lenguaje natural, para que compruebes quién llama a la función modificada antes de aprobar.

    Prueba codebasechat gratis