So far it seems the same. I used Opus 5.5 for an hour this evening and it was just as painfully verbose as Opus 5. It also used the term "load bearing" 4 separate times.

I noticed that when opus 5.5 was on parts on my codebase that had lots of 5.0-generated comments, it picked up its style. Unfortunately I think 5.5 has been trained to mimic what it sees so that you can ease up on the instructions, but this does mean parts of your codebase that 5 touched will be somewhat viral.

GLM-5.3 does the same, funnily enough.

I gave it some vibecoded patch someone created with Opus 5 with the task of together figuring out the real root cause and what to do about it.

Big mistake. The rest of the session was all claude-speak up until I've rage-quit and restarted with Qwen and no context other than "here's what I think we've missed in the current implementation. How could we approach that?"

GLM felt like it got at least 20 IQ points dumber just from being exposed to claude's writing.

I will forgive it using load bearing as long as it finds the right seams.

Yeah, you definitely don't want to hang things off the wrong seams, or you'll end up with quite the blast radius

Let's not paper over that gap and find the root cause instead

Let's unblock that gate

Due to this release note, I used it once to rewrite a doc, and was disappointed.

If anything it seems worse. I'm experiencing about -10% insufferable jargon, but +30% more verbosity. It's unredeemable. There also seems to be even less structured output (headings, bullets, etc).

thank you, i did not try it myself and having read this, will not waste my time and energy

I agree with the sentiment but unless it leads to better financial outcomes for them to A) have engineers on staff and B) have them know their systems then enterprise will continue looking for reasons to shed all the engineers and just leave everything to AI. Anecdotally I think most companies are still looking for ways for AI to help them shed headcount so raising this alarm doesn't mean anything to the decision makers at the top.

Kinda curious why releases just aren't fully immutable? Sane semver would dictate any update should at least be a new patch release.

The files in a release are immutable, but a release on pypi consists of multiple files for binaries that is a cross of architecture, os, and python version. Per other comments the upload api is stateless. The consideration is an attacker adding new files to an old release

GP wasn't asking about the files being immutable, whatever a mutable file would mean. They were asking about the releases. I'm curious too.

The way it's done with rubygems, if you messed something up with the gem (pushed secrets, etc.), you "yank" (remove) the release and push a new one (different version). You can't work with the files in a release once it's been pushed.