This issue is mentioned on the Opus 5.5 post [1] from Anthropic (no idea if it has been added after your rant):

  > Don’t ask it to show its reasoning in the reply
  >
  > What to do. Remove requests to reproduce its internal reasoning in the reply from your prompts and instructions.
  >
  > Why it matters on Opus 5.5. A request to reproduce its internal reasoning in the reply can be declined. It’s one of the flag categories.
  >
  > How. Ask Claude for what you need instead, for example, “Explain why you chose this approach in three sentences.”

[1]: https://claude.dev/blog/getting-the-most-out-of-opus-5-5/

Anthropic is trying so hard to "crack down" on distillation that they're ruining their own product. I do not know why.

AI companies are seeing the endgame, more and more tasks can be done just fine by cheaper model, and there will be not enough money to be made to support model that is only needed for top 1% of the tasks.

And the goal is to slow competition down enough before IPO

That's extremely stupid, but also it's a completely different thing from literally just having the word "reasoning" in the text.

If only we had some sort of artificial intelligence-like system that could decide not only based on the word but also surrounding context, and maybe even in cases when that word is not specifically used.

How long before an AI bribes one of its human operators?

This will happen earlier than AGI.

While working on a completely unrelated task and Alibaba AI in training started hacking its internal infrastructure and mining bitcoin, makes you wonder.

But, which kind of bribe are we talking about? How could it work out in practice for an AI to acquire something valuable, and at the same time prevent it's human operators from taking it without its consent?

It doesn't have to acquire it, it's enough to convince the operators that it did. Same pattern generalizes to threats.

There's so many angles to go at it too, beyond bribery and threats - humans can be tricked, nerd-sniped / baited by exploiting their curiosity or worries, overwhelmed with information or raw sensory input, etc. Depending on whether there's more than one operator involved, the trick may involve playing one human against another, etc.

Hell, humans get tired; I wouldn't be surprised if an effective breakout happened just because agent output something that, at first glance, looked like system-level message that makes the operator do the wrong thing in panic, or from muscle memory. Simple thing like:

  $ sudo journalctl ...
  password: 

Timed right, might give agent root for long enough to do some damage before the operator realizes their mistake and pulls the plug (assuming there is a plug to pull).

The man released a fix twelve years ago for free. If someone is really depending on this, they can fork it themselves. I'd argue that that's the beauty of open source, rather than a downside.

Even with AI, the result needs to be reviewed both to make sure it is actually correct in what it intends to do and that it does not have knock-on effects anywhere else. Given the description of the bug I'd think that spinning up the AI and pointing it in the right direction would save no time over just fixing the issue completely by hand.

Fixing the issue could set an expectation in current users of the package that it might get updates going forward, which it obviously won't from this maintainer, potentially reducing any impetus that might exist to move over to something that is a more correct solution these days. Handing over control of the project where it is has risks which are stated in TFA.

So while both fixing and deprecating could have been done, I think the right choice (just mark it as deprecated) has been made. Not fixing the existing bug(s) will not break anything that is using the package any more than it is already broken. If one of the existing issues had potential to be a security issue then I might err more towards fix+deprecate (with big red text included in any announcement of the fix to the effect that this is the last one and future issues won't get resolved upstream).

We are in the AI era, it doesn't change the fact that investing 1 hrs a month (or even a week) into a long-dead project in a language you no longer use is more investment than 0 hours for the rest of your life.

And yes, if your timeline as a dependency enjoyer is "is this project going to be maintained for 15 years" and you still assumed the answer is yes, it's kind of on you adding a dependency.

The cool thing about open source is anyone can fork it and spend their own money asking AI to make a fix.

The down vote was me - I really think calling deprecating a project after a decade+ telling the world 'depending on this project was a bad idea' is tone deaf.

It doesn't say that depending on it was a bad idea, but that depending on it going forward is a bad idea, and they've gone the extra mile and made an announcement including information about what better alternatives are not available.

Would you prefer it just sat there unfixed and unsupported?

that is NOT what it says - "tell the word that depending on this project WAS a bad idea" ... 'was' - past tense, as in depending on it in the past was a bad idea

Others would say pragmatic.

I think it shows a complete misunderstanding on what free software is.

Free software is Free (and free software is free, libre software is libre, …, where the free/Free/libre/OS/… distinctions are relevant). That does not guarantee continued maintenance for decades, and to expect such is the sort of entitlement that puts some people off sharing their work and playthings.

Can you explain what that misunderstanding is?

Deprecation is just a tag. You don't have to respect it. And if you want the project to continue, you can freely fork it.

> check what it proposes

This requires re-learning the language he's out of practice with.

Why don't you do it?

I'm just discovering Glass Imaging (a bit difficult as their website seems overloaded), but it seems they are in software solutions, not a hardware manufacturer or designer.

>but it seems they are in software solutions

Surely OpenAI can replicate that with their own tools in an afternoon and a few million tokens.

FYI Nord Stream had one end in Germany, which happens to be in Europe. So Nord Stream was driving oil to Europe, and some Europeans mattered.

FYI Nord Stream did not transport oil, but gas (not to be confused with gasoline).

It is good for Russ.a even if they didn't even organize it: everybody thinks it's them, but they might not have even spent anything on it.

I don't think it's good for them. The more people see Russia as the enemy, the stronger the support for Ukraine.

I believe it will only accelerate the end of Putin and his regime, so I don't actually think this is good for Russia if it wasn't them.

Not the Normandy event, but the NL event.

I did bother to read it, and that isn't what I meant. I wasn't referring to one-off errors that you can fix after successfully decoding a cipher into something that produces a majority-correct answer. I meant something more akin to what schoen's answer touched on: whether there are any closed-form mathematical/statistical analyses that can be performed ahead of time to assess the structural legitimacy of any ciphertext before you spend a lot of cycles trying to decode it.

Thanks for the driveby snark though!

> Imagine being able to walk into a house and see immediately the leaks dripping from the ceiling, the clunky layout and smell the stinky garbage that hasn't been collected.

No need to imagine. Just open the README.md of many projects.

Your project README lists all of the bugs and race conditions in the application? Cool!

You lost audience long before it could become contributors.

That was sarcasm. The people who criticize and make demands are rarely the ones who actually do the work