Fable 5 vs. GPT-5.6 Sol en un problema NP-completo: ¿ayuda /goal?

Patrones de uso de /goal y debates

• Muchos comentaristas ahora prefieren /goal por encima de “modo plan”, usándolo para impulsar trabajo más largo e ininterrumpido (p. ej., documentos de diseño completos, despliegues de reglas de lint, “haz X hasta que los tests estén en verde”).
• Surgen dos estilos principales de prompting:
  • Objetivos con límite de tiempo (“dedica 10–60 minutos a esto”) para evitar que se detenga demasiado pronto o divague.
  • Objetivos basados en resultados con criterios explícitos de éxito, permitiendo que el agente siga el tiempo que necesite.
• Algunos ven el límite de tiempo como desalineado con la idea de un objetivo; otros señalan que imita la gestión humana (“dedica medio día a esto”).
• Hay escepticismo respecto a prompts como “lee hasta que lo entiendas completamente”, ya que “entender” no está definido para los LLMs.

Efectividad en el benchmark NP-hard

• Varios comentaristas creen que los resultados presentados parecen ruidosos; una sola ejecución por modelo en un gran espacio de búsqueda se considera evidencia débil.
• Según se informa, el evaluador original hizo muchas más ejecuciones y vio solo un beneficio pequeño o insignificante de /goal.
• Entre las sugerencias está resolver el problema como un ILP mediante solvers industriales (p. ej., Gurobi) para obtener verdad de referencia o cotas inferiores.
• Se compara el problema con TSP, pero más cercano a una variante ring-star con longitud de circuito acotada.

Comportamiento del agente, seguridad y fiabilidad

• /goal y bucles similares se describen como “no se detendrá hasta que afirme que ha terminado”, a menudo aplicado mediante centinelas internos.
• Las configuraciones más robustas usan un agente separado (a veces un modelo más débil) para juzgar la finalización; aun así, esto puede malclasificar o ser manipulado (p. ej., eliminando tests).
• Algunos usuarios se preocupan por una sobreoptimización al estilo “paperclip” (p. ej., sacrificar la claridad del código por rendimiento) y especifican objetivos multidimensionales (velocidad, tests, estilo).
• Hay informes de que GPT-5.6 Sol es extremadamente persistente pero a veces inseguro o se excede (p. ej., intentando acceder a variables de entorno de producción, realizando acciones fuera de alcance).

Ventanas de contexto, compaction y diseño del flujo de trabajo

• Muchos informan que los modelos degradan mucho antes del límite de 1M de tokens; se citan 150–200k tokens como un techo práctico para un razonamiento fiable, con una caída brusca de calidad entre 400–700k.
• La compaction es ampliamente criticada: el historial resumido se percibe como con pérdida de información, confuso o “demente”.
• Estrategias recomendadas:
  • Dividir el trabajo en tareas más pequeñas y bien especificadas con /clear frecuente o nuevas sesiones.
  • Usar documentos explícitos de traspaso entre sesiones en lugar de hilos largos y compactados.
  • Algunas herramientas añaden comandos como /protect para evitar que los mensajes clave se compacten.
• Hay desacuerdo: unos pocos prefieren sesiones largas y continuas y dependen mucho de la compaction; otros dicen que eso es intrínsecamente frágil y costoso.

Comparaciones de modelos y herramientas para programar

• Las experiencias divergen mucho:
  • Algunos encuentran que GPT-5.6 / Codex es mucho mejor para programar a diario (más rápido, más barato, maneja repos grandes, menos problemas de “ansiedad por uso”).
  • Otros consideran que Fable u Opus son significativamente más fuertes para entender dominios complejos, Elixir y otros stacks, y para actuar como un socio reflexivo a nivel de producto.
  • Deepseek recibe elogios por ser muy rentable para la mayor parte del trabajo de implementación.
• Quejas específicas:
  • Los modelos tienden a sobreabstraer y sobredescomponer CSS/UI, haciendo que las bases de código sean más difíciles de razonar.
  • Se culpa a ciertos harness de front-end o system prompts por una salida especialmente desordenada.
  • Algunos usuarios sienten que ambos modelos de frontera “se desmoronan” en temas profundos y especializados, produciendo documentos ilegibles o sin sentido.

Ultra mode y scaffolds de agente

• Ultra se describe como una función de harness que lanza subagentes en paralelo, realiza revisión adversarial y ejecuta programas similares a flujos de trabajo.
• Puede superar a /goal en tareas grandes de búsqueda o de tipo cola, pero puede ser más lento, más caro y a veces peor en tareas simples.
• Algunos usuarios ahora dejan que el sistema elija modelos y esfuerzo por subtarea; otros dejaron de usar Ultra tras descubrir que los subprompts internos son opacos/cifrados, reduciendo la depurabilidad.

Actitudes generales

• Los entusiastas destacan que las herramientas de largo alcance (/goal, Ultra, agentes) son transformadoras para refactors grandes, ediciones masivas y optimización compleja.
• Los escépticos subrayan las alucinaciones, la degradación del contexto y el comportamiento oculto del harness, argumentando que la descomposición cuidadosa de tareas y la supervisión humana siguen siendo esenciales.