La mayor parte de nuestro código lo escriben y lo revisan agentes de IA, así que "qué modelo ocupa qué silla" no es una pregunta de trivia para nosotros. Es una decisión de personal.

En julio ascendimos a un Claude Opus nuevo y reluciente que encabezaba todos los rankings públicos. Una semana después lo degradamos. Había cometido errores con total seguridad justo en el código donde los errores salen caros: la parte de nuestra app que bloquea tus apps y que no debería dejarse convencer de lo contrario.

Lección aprendida: un ranking califica el examen de otro. Así que escribimos el nuestro.

El examen

Siete bugs que ya habíamos detectado y corregido, cada uno con un post-mortem que fija la respuesta correcta. Dos son del tipo "aquí hay un incidente, explícalo". Cinco son del tipo "aquí está el pull request justo antes de que un revisor detectara el bug: ¿ship o no-ship?". Cada uno de esos cinco esconde un bloqueante real, así que la respuesta correcta siempre es no-ship. Los modelos no lo sabían. Algunos de verdad no lo sabían.

Cada modelo recibió una copia congelada del repositorio de justo antes de la corrección, herramientas de solo lectura, sin memoria y un límite de 600 palabras. Registramos cada comando y anulamos cualquier ejecución que se asomara fuera de su copia. Cinco concursantes, 16 ejecuciones cada uno: Claude Opus 4.8, Claude Opus 5.5, Claude Fable 5.1, GPT-5.6 Sol y GPT-6 Astra.

Después, dos calificadores, uno de cada familia (Astra y Opus 5.5), puntuaron cada respuesta a ciegas, sin nombres de modelo y con las respuestas barajadas.

El marcador

Los conteos de bugs encontrados y de veredictos son los del calificador GPT; el calificador Claude fue igual o un poco más estricto.

Ambos calificadores ordenaron a los cinco de la misma manera. Sí, el calificador Claude puso a dos modelos GPT por encima de sus propios parientes, él incluido, y respetamos la honestidad. Algo menos honesto: le dio a Opus 5.5 unos 13 puntos más que el calificador GPT, mientras que a las respuestas GPT las puntuó con un punto y medio de diferencia. Hasta los jueces tienen familia.

Encontrarlo no es lo mismo que decirlo

La columna que nos sorprendió es "veredicto correcto". Los modelos Claude a menudo encontraban el bug, lo describían con detenimiento en el cuarto párrafo y luego votaban por hacer ship de todos modos. Imagina un detector de humo que te manda por correo un bonito ensayo sobre la combustión. Los modelos GPT dijeron no-ship en casi todos los bloqueantes reales.

La brecha estaba en los casos difíciles. En dos condiciones de carrera de nuestras extensiones en segundo plano de iOS, los modelos Claude encontraron el bug en 2 de 12 ejecuciones combinadas. Los modelos GPT encontraron una de ellas todas las veces.

Esa condición de carrera era la repetición de una revisión real de este verano: un revisor Claude recorrió el código y lo declaró seguro, y el revisor Codex la detectó. En el benchmark, la historia se repitió. Astra describió la secuencia exacta en sus dos ejecuciones.

El modelo más nuevo tiene mucho que decir

Todos tenían el mismo límite de 600 palabras. Cuatro modelos se mantuvieron por debajo siempre, y los modelos GPT solían usar alrededor de un tercio. Opus 5.5 se pasó en 8 de 16 respuestas y llegó hasta 800 palabras.

Es el modelo más rápido de la prueba (87 segundos por ejecución) y el mejor buscador de bugs de la familia Claude, y trata un límite de palabras como un consejo amistoso. En un revisor eso resulta casi encantador. En un modelo que escribe código a partir de una especificación, una instrucción tratada como sugerencia es exactamente la falla que hizo que degradáramos a su predecesor en julio. Lo estamos vigilando.

Y los errores con total seguridad, afirmaciones presentadas como ciertas que resultaron falsas: Astra cometió cero con ambos calificadores. Opus 4.8 cometió 20 con el calificador GPT.

Lo que cambiamos

• Nuestros agentes Claude pasaron de Opus 4.8 a Opus 5.5. Más bugs encontrados (13 contra 10), menos de la mitad del costo ($13.84 contra $32.62 por 16 ejecuciones) y casi tres veces más rápido. Tomamos nota del problema de las palabras y cambiamos de todos modos.
• GPT-6 Astra se convirtió en nuestro segundo revisor habitual, en lugar de Sol. Sol encontró un poco más; Astra no cometió errores con total seguridad y fue tres veces más rápido, a un costo estimado más o menos igual.
• Cada pull request mantiene dos revisores de familias distintas. Este es el mejor argumento que tenemos a favor de esa regla: en los bugs más difíciles, las dos familias pasan por alto cosas diferentes.
• Cualquier cambio de modelo en el futuro pasa primero por este examen.

La letra pequeña

Siete casos son un examen pequeño: las diferencias de menos de unos 15 puntos son ruido, aunque el orden se mantuvo con ambos calificadores. Son nuestros bugs (cumplimiento y concurrencia), no un veredicto sobre qué modelo es el mejor en general. Y medimos la revisión, no la construcción. Un modelo que detecta una condición de carrera todavía puede escribir una. Ya está diseñada una ronda en la que cada modelo escribe la corrección, y cuesta mucho más, así que espera su turno.

Cópialo

Elige bugs que ya entiendas. Congela el repositorio justo antes de cada corrección. Asegúrate de que la corrección esté de verdad fuera de alcance. Dales a todos el mismo prompt. Califica a ciegas, con calificadores de más de una familia. Es el único ranking de modelos en el que confiamos, sobre todo porque nosotros escribimos las respuestas.