DoorDash ha contado cómo montó DashBench, un test interno para medir si podía fiarse de la IA que revisa su código. El resultado es un dato útil para cualquier equipo que use IA para revisar pull requests: emparejar dos modelos pilla muchos más fallos que usar uno solo, y meter un modelo abierto en la mezcla sale más barato sin perder calidad.
Qué es DashBench
DoorDash construyó el test tras darse cuenta de que no tenía forma de saber cuántos bugs se le escapaban a su revisor de IA. El feedback del día a día solo registraba lo que la IA sí marcaba, nunca lo que dejaba pasar. Así que cogieron 105 cambios de código reales de su propio historial, con los problemas ya conocidos, y midieron cuántos cazaba cada configuración.
Los números:
- Los modelos revisando código en solitario pillaban entre el 20% y el 30% de los problemas.
- Emparejando dos modelos de Claude, la detección subía a algo más de la mitad.
- La pareja ganadora fue Kimi K2.6, un modelo abierto y descargable, junto a Claude Fable 5: cazó dos tercios de los problemas y 8 de cada 10 bugs críticos, a un coste de 3,81 dólares por revisión.
El cofundador Andy Fang lo resumió sin adornos: mejor calidad, coste más barato.
Por qué el emparejamiento gana
El hallazgo interesante no es qué modelo es mejor, es que dos modelos distintos ven cosas distintas. Un revisor en solitario, por bueno que sea, tiene puntos ciegos. Al poner dos modelos con criterios diferentes a mirar el mismo código, lo que uno deja pasar lo caza el otro. Pasar del 30% al 66% de detección con esa simple idea es un salto enorme.
Y el segundo aprendizaje pega donde más duele, en la factura. El modelo que hizo mejor pareja no fue otro Claude, fue Kimi K2.6, gratis de descargar. Eso baja el coste por revisión y enseña hasta dónde han llegado las opciones de código abierto. La combinación de un modelo cerrado potente con uno abierto barato dio el mejor resultado global.
Por qué importa
Aquí lo relevante no es DoorDash, es el método. Cualquier empresa con un volumen serio de código puede hacer lo mismo: coger sus propios fallos pasados, montar un test con ellos y medir de verdad qué caza cada configuración de IA, en vez de fiarse de que funciona.
Ese es el paso que casi nadie da. Se mete un revisor de IA, marca cosas, y se asume que va bien porque marca cosas. Pero sin medir lo que se escapa, no sabes si estás cazando el 30% o el 70%. DoorDash montó la regla de medición antes de fiarse, y solo entonces decidió meter modelos abiertos en el pipeline.
Para un operador, dos ideas concretas. Una, que combinar dos modelos distintos suele rendir más que buscar el modelo perfecto. Y dos, que los modelos abiertos ya están a un nivel en el que compensa probarlos en tareas reales, porque el ahorro de coste es directo. Es la misma lógica que empuja el ruteo hacia el modelo más barato que resuelve cada tarea: no pagar de más por potencia que la tarea no necesita.
Y hay un tercer aprendizaje, quizá el más valioso: DoorDash no midió su IA contra un benchmark público, la midió contra sus propios fallos pasados. Ese es el dato que de verdad importa, porque un modelo puede lucir bien en un test genérico y fallar en el código concreto de tu empresa. Montar tu propio conjunto de casos reales, con las respuestas ya conocidas, es lo que convierte una intuición en una decisión con números detrás.
Relacionado
