Qodo compara LLM para revisión de código: bugs detectados, ruido y coste de cada revisión

Hoy los modelos de frontera salen casi cada mes, y cada uno desplaza el equilibrio entre calidad, precio y velocidad. El 12 de octubre de 2026, Qodo, una compañía que desarrolla productos de revisión de código y governance, publicó en su blog el artículo «Which LLM should review your code?». En él compara modelos según tres parámetros: cuántos bugs encuentra el modelo, cuánto ruido genera y cuánto cuesta cada revisión. El anuncio disponible no incluye cifras finales ni un ranking, así que a continuación se analiza el planteamiento de la pregunta y lo que importa en él.

Por qué la revisión de código

La revisión es un buen terreno para comparar modelos porque sus compromisos se ven de inmediato. Un bug que se cuela llega a producción y sale caro. Los comentarios superfluos hacen perder tiempo a los desarrolladores y, con el tiempo, les acostumbran a ignorar al bot. La factura de tokens crece con el tamaño del pull request y con la profundidad de razonamiento del modelo. Los benchmarks de chat no ofrecen este panorama: en ellos no hay coste del error ni un equipo real que deba confiar en el resultado.

Además, la tarea tiene un desenlace verificable. El bug estaba en el diff o no estaba, y el comentario lo acepta el autor o lo rechaza.

Tres ejes para comparar

Qodo sitúa en el centro tres magnitudes. La velocidad, que el anuncio menciona por separado, se añade como cuarta.

• Exhaustividad (recall): qué proporción de los defectos reales se detecta. Aquí importa el desglose por tipos: errores lógicos, seguridad, casos límite, incumplimiento de las reglas acordadas por el equipo.
• Ruido (precision): cuántos comentarios son útiles y cuántos carecen de sentido, duplican al linter o se refieren al estilo. Un modelo que encuentra más bugs pero genera el triple de basura puede perder frente a otro más cauteloso.
• Coste de la revisión: el precio de una pasada sobre un PR típico, con el contexto de entrada y los tokens de razonamiento. Para un equipo con cientos de PR a la semana, una diferencia de varias veces en el precio por revisión se convierte rápidamente en una partida visible del presupuesto.
• Velocidad: tiempo hasta recibir los comentarios. Una revisión que llega a los 20 minutos se integra peor en el flujo de trabajo que una lista en dos.

La principal dificultad es que los ejes tiran en direcciones opuestas. Un modelo más potente suele encontrar más, pero cuesta más y es más lento. Un modelo barato y rápido ahorra presupuesto y deja pasar con más frecuencia los errores sutiles.

Lo que el anuncio no dice

El fragmento del RSS se corta en la parte introductoria. No sabemos qué modelos participaron, con qué conjunto de PR y bugs se hizo la prueba, cómo se definió un «bug encontrado» ni qué ajustes de razonamiento se usaron. Todo ello influye mucho en las conclusiones. Además, Qodo vende un producto de revisión, por lo que le interesa que su metodología resulte convincente. No es motivo para desconfiar de los datos, pero sí para revisar la metodología en la versión completa del post en cuanto llegue a las tablas.

Cómo elegir modelo para tu equipo

El ranking de otros ofrece un punto de partida, no una respuesta. En la práctica funciona el siguiente orden.

1. Reúna entre 50 y 100 PR cerrados propios en los que los bugs ya sean conocidos: de postmortems, reversiones o commits de hotfix. Ese será su conjunto de pruebas.

2. Ejecute 2–3 modelos con el mismo prompt y el mismo contexto. Cuente los bugs encontrados, la proporción de comentarios aceptados y el coste total.

3. Considere un esquema de dos niveles: un modelo económico revisa todos los PR y uno potente entra en los cambios de riesgo, por ejemplo autorización, pagos y migraciones. 4.

Revise la elección cada trimestre o cuando salga una versión relevante. Si el pipeline no depende de un único modelo, el cambio lleva horas, no semanas. 5.

Vigile la proporción de comentarios rechazados. Si crece, el equipo empieza a ignorar al bot, y eso importa más que cualquier línea de un benchmark.

Vale la pena leer el informe completo de Qodo por su metodología y sus cifras concretas. La decisión sobre qué modelo revisará su código conviene tomarla según los resultados en su propio repositorio.