Cómo enrutar PRs a modelos según su tamaño

Cuando empiezas a integrar revisión de código con modelos de lenguaje en tus PRs, el costo y la latencia se vuelven el primer obstáculo real. Cada pull request llama a una API que cuesta dinero y tiempo, y si multiplicas eso por cientos de PRs al mes, tienes un problema doble: presupuesto y velocidad. Aquí aprenderás a controlarlo sin romper tu integración continua.

Por qué los LLMs chocan con la integración continua

La integración continua se apoya en una certeza simple: el mismo input debería producir el mismo output. El problema es que eso no está garantizado de forma nativa con los LLMs [00:20]. Un modelo puede darte un veredicto ligeramente distinto ante el mismo diff, y eso rompe la reproducibilidad que espera tu pipeline.

Por eso conviene diseñar el sistema aceptando esa variabilidad en lugar de pelear contra ella. La estrategia no es buscar perfección, sino reducir el margen donde esa variación afecta decisiones importantes.

¿Qué es un diff en el contexto de code review? Es el conjunto de cambios entre dos versiones de código. Sobre ese diff se calcula un hash que permite saber si algo cambió realmente entre una iteración y otra.

Cómo reducir costos y latencia en la revisión de PRs

Hay varias palancas que puedes accionar para controlar el gasto y ganar velocidad. Las técnicas se complementan entre sí y vale la pena combinarlas.

• Usar un cache basado en hash del diff para reutilizar un veredicto cuando no hubo cambios reales [00:38].
• Enrutar modelos pequeños antes que los grandes, y llamar a los costosos solo cuando de verdad se necesita [00:44].
• Poner topes de presupuesto sobre lo que puede costar un solo commit [00:50].
• Aplicar paralelización para procesar varios archivos al mismo tiempo [00:56].
• Usar fail fast para recortar latencia [00:58].

Cada una ataca un frente distinto: el cache evita trabajo repetido, el routing evita pagar de más y la paralelización acelera el proceso completo.

Cómo lograr salidas más estables con temperature y seed

Para que la variabilidad no te sabotee, puedes bajar la temperature a cero, lo que hace que la salida sea mucho más estable [01:03]. También puedes fijar un seed para alcanzar cierto grado de determinismo.

Eso sí, con una advertencia honesta: no será perfecto [01:10]. La idea es reducir el ruido, no eliminarlo por completo.

¿Para qué sirve bajar la temperature a cero? Reduce la aleatoriedad del modelo y hace que responda de forma más consistente ante el mismo input, algo clave cuando necesitas reproducibilidad en CI.

Cómo enrutar PRs a modelos caros o baratos

La propuesta práctica es modificar el YAML y el reviewer para que primero determinen si el PR es grande o pequeño y, según eso, lo enruten a un modelo caro o barato [01:20]. La suposición de trabajo es simple: cuanto más pequeño el modelo, más barato resulta [01:28].

Dentro del YAML vive el routing que decide qué modelo entra en juego, apoyado en una variable configurada en Git actions [01:40]. El corazón de la decisión es un script bastante determinista que da el veredicto sobre si el PR es grande o pequeño [01:48].

Qué hace el script que decide el modelo

Ese script revisa cuántos archivos hay y, sobre todo, de qué tipo son: si es documentación o código real [02:00]. Con base en ese análisis entrega el veredicto de qué modelo usar.

Y aquí viene lo interesante: no todo es cuestión de costo, también importa el rol que mejor cumple cada modelo.

• Los modelos Gemini funcionan muy bien para documentación [02:20].
• Los modelos Claude funcionan muy bien para código [02:24].
• El mismo script calcula el hash que codifica el diff para verificar si la siguiente iteración cambió [02:34].

Ese hash es el que ahorra tiempo y costos manteniendo la integridad del commit, porque evita reprocesar algo idéntico.

Qué pasa al probar los PRs con distintos modelos

Para verlo en acción se prepararon dos PRs: uno de documentación y otro con un cambio de código más grande [02:44]. El primero ya ejecutado devuelve un veredicto de aprobación, igual que haría el reviewer previo, pero lo relevante es el modelo usado: “nan”, que es pequeño y perfecto para ediciones menores [03:00].

El segundo PR, con cambios más significativos, devuelve un veredicto de block y utiliza la plantilla mini [03:14]. La razón del bloqueo no importa ahora; lo que importa es que el cambio más grande justificó un modelo distinto.

Estos modelos son pequeños solo para el ejercicio, y puedes aumentar la capacidad o cambiar el tipo de modelo según lo que busques [03:30].

Por qué conviene usar reglas binarias para bloquear

Con este diseño reduces el costo por PR, recortas la latencia y aceptas que el veredicto de un LLM tiene variabilidad [03:40]. Justo por esa variabilidad conviene preferir reglas binarias con alto acuerdo para bloquear, donde una variación menor no cambia la decisión.

Un gate solo se vuelve realmente valioso si aprende. El siguiente paso es convertir sus errores en un factor de mejora.

¿Cómo estás controlando hoy los costos de tus revisiones automáticas? Cuéntame en los comentarios qué estrategia te funciona mejor.