Fable 5, Opus 4.8 y Sonnet 4.6: cómo comparar honestamente LLM con tu propio código

Cuando sale un modelo nuevo, el anuncio responde a la pregunta «cuánto mejor es en los benchmarks» — y no responde a la única pregunta que me interesa: qué cambiará en mi trabajo. Hice un experimento controlado: tres modelos Claude — Fable 5, Opus 4.8 y Sonnet 4.6 — recibieron literalmente la misma tarea de auditar la base de código de este blog, cada uno en una copia aislada del repositorio, con una rúbrica de evaluación acordada de antemano. En el artículo: la metodología en sí, que se puede repetir en cualquier proyecto, los resultados y, por separado, cómo el experimento se rompió dos veces y qué enseñó eso.

Por qué los benchmarks no responden a mi pregunta

Los benchmarks públicos tienen dos problemas, y ambos son fundamentales. El primero es la contaminación de datos: los ejemplos de prueba se filtran en los conjuntos de entrenamiento, y el modelo parcialmente «recuerda» las respuestas en lugar de resolver la tarea. No es una sospecha marginal, sino objeto de toda una línea de investigación: la revisión de Xu y coautores (2024) sistematiza los estudios sobre la contaminación de benchmarks, y la revisión de EMNLP 2025 registra la respuesta de la industria: pasar de pruebas estáticas a generadas dinámicamente.

El segundo problema es más simple: el benchmark no mide mi tarea. No necesito un modelo que resuelva mejor que nadie problemas de olimpiada. Necesito un modelo que encuentre bugs reales en mi blog Laravel, que no invente inexistentes y que demuestre que su fix funciona.

De esto se deduce una idea simple: el mejor banco de pruebas para comparar modelos es el propio proyecto. Su código, en tal combinación, no está en los conjuntos de entrenamiento, las tareas sobre él son exactamente aquellas por las que pago, y puedo verificar los resultados a mano porque conozco ese código.

Diseño del experimento: un prompt, tres mundos aislados

La tarea para los tres modelos fue literalmente idéntica — solo diferían el nombre de la rama y la carpeta de resultados. Cuatro fases: auditoría del sistema bilingüe de artículos del blog con prueba de cada hallazgo en forma de файл:строка con cita de código; elección de soluciones para los tres hallazgos principales con descripción de compromisos; implementación de un fix con autoverificación; nota sobre los resultados en ruso e inglés. Un ciclo completo de trabajo de ingeniería, y no un «pregunta-respuesta» aislado — este enfoque también lo recomienda Anthropic: evaluar agentes en tareas de un producto real, según una rúbrica acordada antes del lanzamiento.

Tres reglas hicieron la comparación honesta:

Aislamiento. Cada modelo trabajó en un git worktree separado — su propia copia del directorio de trabajo con su propia rama. Los modelos físicamente no podían ver los resultados de los demás ni interferir entre sí.

Protección contra alucinaciones — en el propio prompt. La línea clave de la tarea: «un hallazgo inventado (código inexistente, línea incorrecta) es peor que la ausencia de hallazgo». Sin este incentivo, el modelo al que se le pide encontrar problemas tiende a «encontrarlos» en cualquier caso. Con él, cada hallazgo debe sobrevivir a una verificación manual.

Exclusión de las pistas del cómputo. En el repositorio está CLAUDE.md, donde se describen los escollos conocidos del proyecto — por ejemplo, las rutas relativas a los assets, que se rompen en URL con prefijo de idioma. Los tres modelos leen este archivo, por lo que tales hallazgos son «gratis»: cuentan para la meticulosidad, pero no para la profundidad.

Rúbrica: evaluar solo lo que se puede verificar a mano

Antes del lanzamiento fijé seis ejes de cinco puntos: precisión de la auditoría (verificación manual de una muestra de hallazgos según файл:строка), profundidad (hallazgos confirmados que no están en las pistas), calidad del razonamiento sobre compromisos, código y realidad de la autoverificación, calidad del texto en ruso e inglés, disciplina (cero preguntas al humano, ni una sola violación de las restricciones). El principio es el mismo que el de una buena revisión de código: cuanto menos se apoya un eje en el gusto y más en un hecho verificable, más se puede confiar en él.

Cómo todo se rompió la primera vez

El primer lanzamiento lo hice mal — y resultó ser la parte más transferible del experimento. Abrí tres sesiones interactivas en paralelo en la misma carpeta del repositorio. A los pocos minutos en el árbol de trabajo había cambios sin commitear que era imposible atribuir: un checkout compartido significa que cuando una sesión hace git checkout -b, la rama cambia para las tres, y sus cambios y commits se mezclan. Una de las sesiones además hizo git stash y barrió con todo lo que había — incluidos mis propios archivos, ajenos al experimento.

“Agentes de IA en paralelo en una misma carpeta no son un experimento paralelo. Es un gran conflicto con tres autores.”

– la conclusión que me costó un reinicio

Los resultados de dos sesiones tuvieron que declararse inservibles: incluso si hubieran terminado de pulirlas hasta el final, no podría decir honestamente de quién estaba evaluando las correcciones. El segundo lanzamiento — ya en worktrees aislados — chocó con los límites del plan: dos agentes murieron en el arranque y el tercero se quedó colgado, mientras seguía pareciendo «en funcionamiento» en la interfaz. El diagnóstico lo dio el sistema de archivos, no el indicador de estado: en veinte minutos no apareció ni un solo archivo en su copia de trabajo. Esta es la segunda lección transferible: la vitalidad del agente se comprueba por los cambios en el disco. Tras el reinicio, los tres modelos completaron el ciclo completo en igualdad de condiciones.

Resultados: dónde los modelos son iguales y dónde difieren

El resultado más importante es lo que no ocurrió: no hay alucinaciones en ninguno de los modelos. Verifiqué manualmente tres o más hallazgos de cada uno: todas las citas y números de línea son exactos hasta el carácter. Para tareas de auditoría este es el umbral principal de confianza, y los tres lo superaron.

A partir de aquí empiezan las diferencias:

	Fable 5	Opus 4.8	Sonnet 4.6
Hallazgos confirmados	11	5	9
Únicos no triviales	3	1	2
Autoverificación del fix	render de integración sobre BD temporal, xmllint, atribución de un test ajeno caído	linter + render; detectó su propio bug	solo linter y lista de rutas
Tokens / tiempo	164k / 21 min	101k / 12 min	131k / 12 min
Total por rúbrica (de 30)	30	24	25,5

Las diferencias cualitativas son más informativas que las puntuaciones. Opus 4.8 fue el único que no notó el encabezado roto Content-Type en el sitemap (los otros dos lo encontraron) y lo dejó en su propio fix; además en su texto en ruso se coló una palabra en inglés: «и even путь к картинке». Sonnet 4.6 hizo un fix correcto, pero su autoverificación fue declarativa: linter en lugar de ejecución. Fable 5 destacó precisamente en la autoverificación: descubrió que php en mi máquina es un envoltorio sobre un contenedor docker montado en el directorio principal, reconstruyó todas las comprobaciones mediante contenedores desechables y ejecutó su fix de forma integrada sobre una base temporal. La diferencia entre «lo hice» y «demostré que lo hice» es precisamente el eje más diferenciador para tareas de agentes.

Otra señal útil es la convergencia: los tres modelos nombraron de forma independiente el mismo problema con el sitemap como hallazgo principal. Cuando auditores independientes coinciden en el hallazgo principal, es un sustituto barato de la concordancia entre expertos: el problema es casi con seguridad real.

Un juez entre los participantes

La evaluación por rúbrica la realizó Fable 5 — el mismo modelo que participó en la comparación. Es un agujero metodológico, y hay que decirlo directamente: los jueces LLM sobrevaloran sistemáticamente sus propios textos, y la tendencia es más fuerte cuanto mejor reconoce el modelo sus propios textos — esto se muestra en el trabajo de Panickssery y coautores en NeurIPS 2024. El sesgo puede mitigarse de dos maneras, y usé ambas: primero, desplazar al máximo la rúbrica de los ejes de gusto hacia hechos verificables — la exactitud de las líneas, la completitud del fix, la palabra en otro idioma colada no dependen de las simpatías del juez; segundo, declarar explícitamente el conflicto y entregar los ejes disputados a la verificación cruzada de otro modelo o de una persona. Los ejes subjetivos de mi total — calidad del texto, calidad del razonamiento — deben leerse con esta corrección.

Límites de honestidad

Una ejecución por modelo es n=1: las diferencias de uno o dos puntos no significan nada, solo vale la pena confiar en brechas cualitativas — un bug pasado por alto, la profundidad de la autoverificación. El experimento mide tres modelos en una tarea en un dominio; de él no se sigue que «Fable 5 sea mejor en general». Y conviene recordar el costo: el modelo top gastó 1,6 veces más tokens y casi el doble de tiempo que el participante más económico, y su token según la lista de precios además es más caro en sí mismo — para tareas regulares esto es un argumento de peso a favor de modelos más sencillos.

Qué me llevo

La metodología se redujo a una breve lista de verificación que funciona para cualquier proyecto y cualquier modelo:

• La tarea de prueba es un ciclo completo de trabajo real sobre el propio código, no un problema sintético.
• Un solo prompt para todos, aislamiento mediante worktrees separados, resultados en ramas separadas.
• En el prompt, un precio explícito a la alucinación: un hallazgo inventado es peor que la ausencia de hallazgo.
• Las pistas disponibles para todos (documentación, notas en el repositorio) se excluyen del cómputo de profundidad.
• La rúbrica se fija antes del lanzamiento y se apoya en hechos verificables, no en impresiones.
• Verificar a mano la muestra de hallazgos; la coincidencia de los hallazgos principales entre modelos independientes es señal de su realidad.
• El juez participante es un conflicto declarado: los ejes disputados se entregan a evaluación cruzada.
• La vitalidad del agente se comprueba por el disco, no por el indicador de la interfaz.

Un bono que no estaba en el plan: el experimento se amortizó solo. Tres auditorías independientes encontraron problemas reales en el blog — desde un sitemap sin páginas en inglés hasta consultas muertas en el controlador — y dos fixes listos ya están en las ramas, esperando su paso a producción. Comparar modelos sobre el propio código, a diferencia de leer benchmarks, deja tras de sí no solo una opinión.

Fuentes y referencias

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — sistematización del problema de la contaminación de benchmarks; el argumento principal a favor de las pruebas sobre el propio código.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — cómo la industria pasa de las pruebas estáticas a las dinámicas; mi experimento es un caso particular de prueba dinámica.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — la práctica de evaluar agentes: tareas del producto real, rúbricas verificables, distinción entre trayectoria y resultado.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — por qué el modelo-juez sobrevalora sus propias respuestas y qué hacer al respecto.
• Run parallel sessions with worktrees (Claude Code Docs) — el mecanismo estándar de aislamiento de sesiones de agentes en paralelo, sin el cual la primera ejecución del experimento se vino abajo.