HN Debrief

What it feels like to work with Mythos

  • AI
  • Programming
  • Developer Tools
  • Economics

The post is a subjective review of Anthropic’s new high-end model line, with the author saying working with “Mythos” feels qualitatively different from earlier models. In practice, most of the concrete examples center on “Fable,” the coding-focused version with extra safety limits. The author claims it can sustain long autonomous work sessions, do research-heavy coding, and produce surprisingly complete artifacts like an isochrone travel map, a game, and a draft social science paper. The article leans hard on the experience of commissioning work rather than steering it line by line.

Treat these demos as proof that AI can help non-engineers assemble convincing prototypes, not as evidence that it can replace software engineering. If you are evaluating these models for product work, demand maintenance, correctness, cost, and safety evidence up front instead of being swayed by impressive-looking outputs.

Discussion mood

Mostly skeptical and irritated. Readers saw the article as hype-heavy marketing that overclaims from weak demos, though many still conceded that Fable seems materially better than prior models on some coding tasks. The main frustrations were correctness, maintainability, cost, and the gap between impressive-feeling generation and software you would actually trust.

Key insights

  1. 01

    LLMs work best when the stakes stay low

    The practical sweet spot is not general software engineering. It is reshaping work so failures are cheap and complexity is contained. That captures why these tools shine on disposable internal apps, prototypes, and narrow modules, then stumble when requirements evolve, mistakes matter, or the system has to survive years of maintenance.

    Use coding models first on bounded projects with clear rollback paths. If a feature needs long-term ownership or has real failure costs, budget for conventional engineering discipline from the start.

      Attribution:
    • cgearhart #1
    • rpdillon #1
    • acedTrex #1
  2. 02

    Longer reasoning helps, but structure still dominates

    One developer working on a compiler-style project said Fable’s transcripts looked more thorough than earlier models that fixed one test and broke two others. The catch is that better persistence does not solve weak decomposition. On codebases where invariants and separation of concerns are fuzzy, the model still thrashes because it does not know when a refactor is actually needed.

    Before upgrading models, tighten module boundaries and invariants in the codebase. Better structure raises the ceiling on what the model can do more than another round of raw capability gains.

      Attribution:
    • mohsen1 #1 #2
    • layer8 #1
  3. 03

    Token burn is becoming the limiting factor

    People who actually used Fable described it as powerful but alarmingly expensive. Sessions consumed large chunks of weekly quotas in under an hour, some users expected a steep price jump when promotional access ends, and one commenter cited internal enterprise budgets that already forced spending caps on coding models. The model’s ability to run many concurrent tasks only makes the cost problem bigger, not smaller.

    Track model spend per completed task, not per seat or per month. If you let agents run unattended across many parallel jobs, put hard budget and usage controls in place before the invoice teaches the lesson for you.

      Attribution:
    • JumpCrisscross #1
    • matheusmoreira #1
    • rstuart4133 #1
    • throw939494555 #1
    • vb-8448 #1
  4. 04

    Polished outputs can still be wrong underneath

    The travel map became the clearest example of why visual plausibility is a trap. Readers found nonexistent routes, bad assumptions about flight availability, customs errors, and poor hub selection logic. Another commenter who inspected the Concord repository called the code unmaintainable. The common point is that these systems are now good enough to produce artifacts that look finished before they are reliable.

    Add domain checks early when using AI for anything data-driven or user-facing. A polished UI should increase your suspicion, not lower it, until the underlying logic has been audited.

      Attribution:
    • theturtletalks #1
    • skipants #1
    • jampa #1
    • SupremumLimit #1
  5. 05

    Safety guardrails block exactly the risky work

    Users hit Fable’s safety fallback on normal cybersecurity and biology-related work, which pushed them back to Opus 4.8 on the tasks where they most wanted the stronger model. That weakens the article’s broad claims about “Mythos-level capability” because the public experience is often a partially disabled version. Several readers also noted that the name confusion matters here. The post sells Mythos mystique, but the actual hands-on product is Fable with constraints.

    Test the exact model and policy tier you will get in production. Early-access impressions are not enough if guardrails or routing rules remove the capability you were counting on.

      Attribution:
    • matheusmoreira #1
    • thepasch #1
    • vunderba #1
  6. 06

    Non-engineers can now commission bespoke software

    The most durable claim in the article is not that AI has mastered software engineering. It is that non-programmers can now get custom tools that serve their own narrow use cases. Several comments argued this is genuinely new and useful, while warning that it should not be confused with producing software that can stand up to the expectations people have for cars, buildings, or commercial products.

    Separate “can build something useful for me” from “can build something robust enough to sell and maintain.” Those are different bars and they need different evaluation criteria.

      Attribution:
    • jimbokun #1 #2
    • an0malous #1
    • eithed #1

Against the grain

  1. 01

    Nine hours is still fast for full app generation

    The strongest pushback to the doom-and-hype cycle was simple. No human developer is going from a long design spec to a working full-featured web app in half a day, even if the result needs cleanup. From that angle, waiting on long inference runs is annoying but still economically attractive because the tool is compressing days of setup and boilerplate into hours.

    Do not dismiss long-running agents just because the wall-clock time feels strange. Compare them against end-to-end human throughput on the same scoped task, including setup and glue work, before deciding the workflow is too slow.

      Attribution:
    • matneyx #1
    • giancarlostoro #1
  2. 02

    Some of the demos are better than first glance

    A few people said the example game was judged too quickly. The snake demo adds mechanics over time and is more than a plain retro clone, even if the article oversold it. Another commenter found the game genuinely fun once later interactions appeared. That does not rescue the larger claims, but it does suggest some criticism came from cursory inspection rather than careful use.

    If you are evaluating AI-generated products, spend enough time to see the intended interaction arc. Quick skims are good at catching obvious failures, but they can also miss the narrow cases where the output is genuinely decent.

      Attribution:
    • coldtea #1
    • starshadowx2 #1
    • mjamesaustin #1
  3. 03

    The isochrone map still beats many past attempts

    One reader argued the travel map deserves some credit on design and scope. Even with logic errors, it is visually strong and more refined than several earlier human-made commute-time and flight-isochrone tools they linked. That reframes it as an impressive prototype with bad data and modeling, not a worthless artifact.

    When AI produces a flawed but unusually complete prototype, separate the interface and implementation wins from the factual errors. You may be able to salvage the product idea even if the first version cannot be trusted.

      Attribution:
    • pu_pe #1

In plain english

Fable ↩
The name commenters used for a newer class of AI coding models or tools they considered stronger at autonomous work and meta-work.
Mythos ↩
A model name used in the report and comments for a highly capable U.S. cyber-focused system.
Opus 4.8 ↩
A version of Anthropic's Claude language model, referenced here as the AI tool used to assist with the driver work.
Rust ↩
A systems programming language focused on performance and memory safety.

Reference links

Projects and artifacts under discussion

  • Concord repository
    The main code example from the article that one commenter inspected and criticized as unmaintainable.
  • Isochronic Passage Chart
    The travel-time map demo from the article that drew both praise for presentation and criticism for factual errors.
  • tsz project repository
    A compiler-style project used by a commenter to compare Fable against older models on difficult coding tasks.
  • lua-rs repository
    A Rust Lua interpreter project used as a real-world test case for Mythos on performance and systems programming work.

Comparable tools and prior attempts

  • Map It Out
    A human-made travel-time map shared to compare against the AI-generated isochrone map.
  • CommuteTimeMap
    Another prior travel-time mapping tool used as a benchmark for the AI demo’s refinement.
  • Flight Isochrones
    A flight-time visualization project cited as another point of comparison for the AI-generated map.

Related engineering references