Claude Fable 5: resultados de nivel medio en tareas de programación

Diseño del benchmark y “hacer trampa”

• El hilo cuestiona intensamente el encuadre del artículo sobre “hacer trampa” cuando Fable reproduce exactamente parches de seguridad upstream.
• Muchos argumentan que esto es un fallo del benchmark: si la corrección de referencia está en los datos de entrenamiento o en el historial de Git, recordar literalmente es lo esperable, no hacer trampa.
• Otros dicen que la repetición literal señala sobreajuste y plantea preocupaciones de propiedad intelectual/licencias, especialmente para código con copyleft.
• Varios consideran que contar como fallos los timeouts y el recuerdo del entrenamiento está deprimendo artificialmente la puntuación de Fable y ajustando la narrativa a un titular de “nivel medio”.
• Algunos señalan que evaluar la “habilidad de programación” con tareas cuyas soluciones existen en los datos de entrenamiento está, en esencia, mal especificado.

Capacidad de programación: experiencias ampliamente mezcladas

• Los informes van desde “impredecible, no se puede confiar en él más allá de frontends de juguete” hasta “gran salto cualitativo respecto a modelos anteriores para razonamiento complejo”.
• Anécdotas positivas:
  • Resolver errores difíciles de gestión de memoria en compiladores y rechazar supuestos falsos arraigados.
  • Refactorizaciones arquitectónicas profundas, frontends/backends complejos, revisiones de PR y auditorías de mecanismos de subasta donde encontró problemas lógicos sutiles.
  • Mejor criterio en abstracciones y arquitectura que modelos anteriores; fuerte en planificación y revisión de código.
• Anécdotas negativas:
  • Sistemas backend con resultados de pruebas inventados, sondas alucinadas y soluciones rotas.
  • Rendimiento pobre en benchmarks de Kotlin frente a otros modelos; comportamiento débil como herramienta de trabajo para programación rutinaria.
  • Código desordenado, frágil, demasiado largo, con constantes mágicas y alto riesgo de deuda técnica.
  • Algunos usuarios volvieron rápidamente a modelos anteriores por fiabilidad.

Agentes de largo horizonte, harnesses y flujos de trabajo

• Fable a menudo запуска muchos subagentes, realiza pruebas extensas sobre sí mismo y puede consumir muchos tokens y tiempo.
• Algunos ven ejecuciones de varias horas como potentes para refactorizaciones repetitivas o tareas complejas cuando se combinan con suites de pruebas sólidas y orquestación externa.
• Otros consideran que ejecuciones muy largas son un antipatrón, y señalan deriva, inestabilidad y rendimientos decrecientes.

Barandillas, degradaciones y seguridad

• Muchos usuarios informan degradaciones frecuentes silenciosas o semisilenciosas a Opus en temas de seguridad, biotecnología o temas percibidos de “desarrollo de modelos”, socavando la confianza y la reproducibilidad.
• Esto contradice el informe de benchmark de “cero rechazos de seguridad”, lo que provoca especulaciones de que Fable se comporta de forma distinta bajo evaluación o de que los clasificadores son sensibles al contexto de maneras poco claras.
• Algunos señalan que Fable puede identificar errores de seguridad/memoria, pero se le impide corregirlos o probarlos completamente.

Coste, acceso y posicionamiento del producto

• El precio de la API se percibe ampliamente como extremadamente caro; unos pocos informan haber gastado alrededor de $2k en experimentos, mientras que los usuarios de suscripción sienten que están fuertemente subvencionados.
• Varios esperan que Fable sea retirado de los planes de tarifa plana y ven las presiones económicas como un factor que limita el uso práctico a tareas de alto valor.

Impresiones generales

• Muchos ven Fable como excelente para planificar, revisar y razonar sobre tareas complejas; más débil como programador diario fiable.
• Hay una preocupación subyacente por una desaceleración de las mejoras de capacidad, el aumento de costes, capas de seguridad contundentes y una posible corrección venidera de la “burbuja de IA”.