‹ BackHN Continuity

Thread

Sonnet 5.5

884 points · 613 comments · D2OQZG8l5BI1S06

  1. Sol- · · focus · HN ↗
    Probably a first world problem, but with Opus 5.5's efficiency, the limits on the 5x plan are simply sufficient for my everyday work, even when running 2-3 sessions at a time. So I wonder when I would use Sonnet 5.5.

    More concurrency than that isn't really practical for me if I want to retain some semblance of understanding. Perhaps it's different for purely web app or frontend tasks, where the outcome is more relevant than the process, I don't have much experience there (and also don't want to belittle these domains, I might be underestimating their complexity).

    So surprisingly, my own work is at least for the time being almost saturated by the model capabilities. I am not sure how I'd scale from here. Sure I could run all requests at max effort to burn tokens for the sake of it, but that can't be it. And for many tasks, I am not really able to define so clear cut success criteria or self-verification loops that I could benefit from letting an agent (or a fleet thereof) autonomously run for a day.

    So I realize it's a skill issue on my side, but I can't be the only one. I wonder if there is a limit to token demand, at least short term. Feels like either they accelerate to AGI and RSI, where the AI can find uses for token, or things might plateau at some point.

    Note I don't think this because I'm an AGI skeptic or think there's a ceiling to intelligence, but there might simply be a valley of economic hardship for the companies where the supply of tokens outpaces the demand, due to a lack of ideas of what to do with them. And this might slow down the funding enough that they never reach escape velocity with the training run scaling. But we'll see.

    1. miki123211 · · focus · HN ↗
      I find that "vibe coders" (that is, people who do not know anything about programming, but nevertheless produce useful tools for themselves and others) are using a lot more tokens than we do as programmers.

      I think this is partially because we're still attached to pre-LLM notions of architecture, good design and code quality (which are still important, but maybe less important than they once were and that we think they are), partially because their projects are in a messy state, so models have to work around the technical dept.

      They're essentially trading off programmer time for LLM time (which is a good trade financially speaking).

      1. satvikpendem · · focus · HN ↗
        LLMs these days write better architected and produced code than most programmers, so the fallacy that LLMs produce slop code is increasingly false.
        1. drewnick · · focus · HN ↗
          Every new generation of model goes and cleans up the slop of its predecessor in my code bases, and it has turned out to be quite effective.

          Last year I held off on implementing a few features knowing that a model like Opus 5.5 was around the corner. I'm now implementing them in a much more efficient and quality manner than I could have fall of 2025.

          1. satvikpendem · · focus · HN ↗
            Indeed. Maybe people down voting me don't like to admit it but when models train on the entirety of human input you can assume they'd be better than the average human.
            1. Tanjreeve · · focus · HN ↗
              This is probably why web development and scripts are much more effective domains while anyone working on anything even slightly off the track is either tearing their hair out or writing a new layer of software to write the software.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.