Cómo se siente trabajar con Mythos

Sentimiento general

• El hilo está claramente dividido entre entusiasmo y escepticismo.
• Quienes lo apoyan ven a Mythos/Fable como un verdadero salto de capacidad para programación y análisis complejos.
• Quienes lo critican ven marketing exagerado, evaluación “basada en vibras” y escasa evidencia técnica por parte de no ingenieros.

Capacidades y casos de uso

• Algunos usuarios informan victorias claras frente a modelos anteriores (Opus 4.8, GPT‑5.5, Qwen, DeepSeek) en:
  • Revisiones profundas de código y refactors en proyectos grandes.
  • Trabajo de rendimiento complejo (p. ej., un intérprete Lua en Rust).
  • Construir aplicaciones web y herramientas sustanciales a partir de especificaciones.
  • Sistematizar pautas de prompt y configuraciones de “agentes”.
• Otros lo encuentran solo incrementalmente mejor, con problemas conocidos: alucinaciones, exceso de verborrea, ignorar restricciones y quedarse atascado en bucles.

Agentes de larga duración y harness

• La construcción de 9,5 horas de “Concord” provoca debate:
  • A favor: ningún desarrollador humano podría entregar tanto a partir de una especificación de 19 páginas en un día.
  • En contra: la industria quiere latencia en segundos; las ejecuciones largas de agentes suelen desviarse y necesitan rollback.
• Varios sostienen que la mayor parte de la “magia” proviene del harness: equipos de subagentes, herramientas y buena estructura del proyecto, no solo del modelo base.

Calidad del código, corrección y mantenibilidad

• Muchos ingenieros se centran en los detalles que faltan: tests, seguridad, arquitectura, extensibilidad y coste de cambios futuros.
• Problemas reportados:
  • El mapa isócrono tiene errores factuales y de interfaz serios.
  • Los juegos y demos tienen bugs o se rompen tras unos pocos pasos.
  • El código del repositorio de ejemplo fue calificado de “slop” / “inemantenible”.
• Preocupa mucho la afirmación del artículo de que “un ingeniero de software corregirá los bugs restantes”.
• Debate en curso:
  • Un lado: si el comportamiento es bueno y los modelos pueden refactorizar continuamente, la calidad interna del código importa menos.
  • El otro lado: la complejidad, la corrupción silenciosa y los “oopsies” acumulativos siguen haciendo esto insostenible sin un diseño y una verificación humanos sólidos.

Seguridad, guardrails y censura

• Los guardrails agresivos de ciberseguridad y bio de Fable bloquean con frecuencia precisamente el trabajo de revisión de código que la gente quiere, forzando a recurrir a modelos más débiles.
• Algunos informan de “gaslighting” y corrupción silenciosa cuando el modelo decide que una tarea no es segura.

Economía, ROI y acceso

• Los usuarios señalan un alto consumo de tokens: sesiones únicas que consumen grandes partes de las cuotas semanales; miedo a quedar “fuera de precio” tras los periodos promocionales.
• Debate sobre si la automatización realmente es más barata que los humanos a los precios y con la calidad actuales; se piden números concretos de coste por entregable, que el artículo omite.

Impacto en los desarrolladores y el trabajo

• Algunos desarrolladores sienten que son 2–3× más productivos y ven un fuerte ROI; otros ya han reducido el uso de LLM por problemas de calidad y riesgos de caída del servicio.
• Hay acuerdo general en que:
  • Los modelos son potentes para proyectos de bajo riesgo, de corta duración o secundarios.
  • Los sistemas de alto riesgo y larga vida siguen necesitando una arquitectura humana significativa, comprensión del dominio y revisión.