Something like this seems unlikely to work for a behavior so burned into them. It'd be better to do a second pass to delete all the nonsense comments.

That's a Claude.

What is?

The cyborg you replied to.

> I have a stage-gated workflow

This is a Claudism, right? I feel like I never saw "gated" used this way before it.

A normal person would say “my workflow has stages” and their normal coworkers would say “no kidding”.

I'm not normal, nor do i have coworkers. Sorry :(

Just a guy trying to make his subscription last longer than the single Fable prompt anthropic includes for 100 bucks a month, lol.

> Looks to me like I can run Claude Code without being able to afford my own datacenter.

Well, unless of course you want to train your own LLM, or do some biochemistry (and increasingly just regular health stuff) or cybersecurity. These capabilities are not made available for plebs like you or I.

Unlike GPT (I think?), Claude is served by all of AWS/GCP/Azure and you can go buy it from any of them.

Whether Claude is or is not available via AWS Bedrock is entirely decided by Anthropic, not by you and not by Amazon. And you can't buy the data sets (the REAL power...) from any AI company.

No, there's no reason chatbot behavior would have anything to do with frequency of text in pretraining.

I think the specific issue with Opus 5 is that its writing style is just trying to cheat at RL. It makes everything hypey yet self deprecating and constantly brings up "honest caveats" because the scoring rubrics look for those.

The specific issue with Opus 5 is that it sucks all around.

It was causing so many issues with coding (even Opus 4.8 was better) that I did agent handoffs to Sol. One of the Sols stated the handoff was "incoherent", which I couldn't have said better myself.

Yes, I pretty much took August off waiting for the next version.

> Twitter was changed so that only views favoured by Musk show up prominently in replies.

This doesn't happen anymore, it's actually relatively good at sorting bad comments to the bottom now. The current problem is it's full of wannabe LinkedIn influencers with "Building for AI agents in business in public" in their profile using LLMs to reply to everything.

Twitter only shows you what you want to see

Eh. They recently changed the algorithm quite a lot, and the guy who was in charge of it (Nikita Bier) made it a lot less evil when Elon wasn't looking. But now he's gone so who knows what will happen.

Anything with ranged numeric types. Like everyone's favorite functional programming language, Ada.

This issue raises SIGFPE. Ada would raise Constraint_error, which is easier to catch than a signal, but still occurs at runtime.

You need range proofs to be 100% safe, and then you can as well use the regular type because invalid values will not occur.

Or Liquid Haskell.

Haskell's type system would not easily prevent this bug. It's not good at numeric/logic issues like that. When people say "Haskell makes it impossible to write bugs" they mean "Haskell has enums" (ADTs).

Liquid Haskell might require you to prove that the divisor is nonzero, but even in standard Haskell there's common idioms for ensuring that a list is non-empty (data NonEmpty a = a :| [a]) or that text is non-empty (newtype NonEmptyText = NonEmptyText Text, with non-exported constructor, helpers like make :: Text -> NonEmptyText, or more advanced tricks like https://exploring-better-ways.bellroy.com/haskell-koan-type-... ).

The big problem preventing this approach from working for numbers is that it's just so cumbersome there. Most of this is because all the arithmetic operators are bundled into a single Num typeclass, and `fromInteger :: Num a => Integer -> a` has a type that's impossible for a "non-zero number" wrapper to satisfy.

Definitely room for improvement on Haskell's standard library when it comes to the number-related type classes. Modern Haskell could do very well in this area with a good type-class redesign in this area. The issue I think is that this would invalidate a lot of existing code, relying upon that. But you can already replace Prelude with something else in your own code if you want to.

I think Idris has a better chance there.

In Haskell they are a little less annoying. It is just easier to reason about (including proving) pure functions.

I meant the constrained types by hiding the constructors. Super annoying, not automatically convertible, in Haskell you have to remember what the fake constructor is called, and write it every time you use it, but at least it's efficiently implemented with newtype, unlike the Java OOP version. Think about writing a value with several nested constrained types, like NonEmptyListOne (makeNonZeroNumber 42, 'h' `NonEmptyString` "ello world"). It's just really annoying.

The blog link I mentioned avoids this cost with literals, by providing using a required type argument to check the string length at compile time without TH. It requires a relatively recent GHC:

    make :: forall symbol -> (IsNonEmptySymbol symbol) => NonEmptyText

    type family IsNonEmptySymbol symbol :: Constraint where
      IsNonEmptySymbol "" = Unsatisfiable (Text "Expected a non-empty string")
      IsNonEmptySymbol _ = (()::Constraint) -- empty constraint is always satisfied

I am not claiming you cant write buggy code in Haskell! But following good functional style, your bug will more likely be compartmentalised, and fixing it will not break some other part of your program.

You can write good functional code in many languages. (Even C++!)

Sure! I have done my fair share of pretending Java and C++ support my functional style. But at the end of the day, you have better support for writing that style in a real functional programming language. And I wonder how well one can enforce a functional style in say Java or C++ upon the LLMs. Who knows, they might be great at it?

People don’t say "Haskell makes it impossible to write bugs"! You may have heard "if it compiles it works" which is somewhat tongue in cheek, but also true for a sufficiently loose interpretation of "works" in a way it is not true for languages with a less strong and flexible type system.