Cómo se siente trabajar con Mythos

Artículo original ↗ Discusión en Hacker News ↗

Una reseña entusiasta del nuevo agente de codificación con IA Mythos/Fable de Anthropic provoca un debate intenso sobre lo transformadores que son realmente estos grandes modelos de lenguaje. Los comentaristas reconocen hazañas impresionantes como maratones autónomos de programación de varias horas y visualizaciones de datos complejas, pero señalan demos con errores, código inmantenible, altos costes de tokens y fuertes guardrails como prueba de que la supervisión humana y una arquitectura cuidadosa siguen siendo esenciales. El hilo también plantea preocupaciones más amplias sobre el hype, el desplazamiento laboral, las cambiantes nociones de “calidad de código” y si las ganancias actuales son incrementales o un verdadero cambio de etapa en el desarrollo de software.

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.