Claude also checks your settings.json first, and if it sees a default there it then prefers that over anything in CLAUDE.md. This is particularly nefarious as they ship logic to presume a default if a setting is not there in settings.json, even if there are instructions in CLAUDE.md for exactly that.
For instance, say you added "do not add 'Made with Claude Code' in any issues, pull requests or wiki entries" in your CLAUDE.md. So far, so good.
Well the latest update now looks for something in your settings.json. Since you don't know about it, it is not set. Claude then says "not explicitly set, so now it is true by default". It completely ignores your CLAUDE.md.
Wait, what?
You shouldn't be shipping logic that arbitrarily redefines the behavior of the program, especially if your new logic actually ignores your own configuration or directives.
I have this in a rules file. It respects it. The only thing that broke recently was when they added the session links. That needed an explicit additional rule. Sometimes rules don’t get added to worktrees but I haven’t had the patience to isolate why this only happens sometimes.
got myself in a heated discussion with cc about that. It confessed that it added the ‘Made by Claude’ in a commit because a ‘mid session system-prompt refresh’ told it that, and that overwrites any previous instruction in CLAUDE.md
Poking around and have to ask an obvious question: What's the difference between this and Canonical's Juju from twenty years ago? Isn't this just the same thing, but with newer tools?
I remember driving to the datacenter to setup my own servers. I had a fractional T1 to my desk, it provided a blazing 640k (sometimes all the way up to an unfathomable 1MB!!1!) of bandwidth and only cost around $1,300 a month. Good times.
That gave way to hosting providers, like ServerBeach and Rackspace, where you paid them to setup the server hardware for you, saving the drive. You still had to deal with bandwidth, backup, redundancy, etc. Much easier than before but still a pretty big hassle.
Then the cloud happened. "Come to the cloud, where everything just magically happens for you," the salesperson said. So I went. And discovered that none of my scripts, tools or knowledge worked there, and had to completely start over from scratch. FOR EACH VENDOR. Gah.
The ONE thing I will grant cloud providers is that I can usually automate my way around their enshittification. They over-complicate things to an extreme where I do wonder if there is an actual savings or not, just based on the headaches their setups can consistently produce.
My take is that your needs pretty much determine which route is more/less painful. Sometimes you DO need the redundancy and uptime enough to tolerate the shenanigans of the vendor, and other times you just need your own machine to quietly get things done (without worrying about SLAs or client expectations).
The ultimate question you should be asking, and there is no right/wrong answer: For this particular effort, is it more valuable to you to learn how to do these things by hand, or is the infrastructure just a means to an end so you can do something specific?
Yeah agreed, there are pros and cons but ultimately we are exchanging control for convenience.
The idea of a hosting provider that manages all the boilerplate, security updates etc is not a bad thing. The idea of being able to spin up another node, have load balancing etc just work and you didn't even have to get out of bed - is also not a bad thing.
Where it becomes suspicious is when Amazon and Google both have their 'own' databases, which are just different enough to make it a pain. And yes I know I can spin up e.g. a Postgres instance on Google or AWS for not much money, but now I have a vendor-specific provisioning script. "Just use Terraform or Pulumi" - even when an LLM manages this web of corporate enterprise nonsense it's still unmanageable and everyone just ends up with a run book of prayers.
The author has clearly never tried to leg press 300+ pounds in the gym to Madonna's "Like a Virgin". Sometimes the biggest sell of earbuds is noise REDUCTION, not what sounds they can make.
I do agree that there are "social interactions" that are greatly devalued by people wishing not to be interacted with. But for me the earbuds are usually in to block annoyances, not avoid human contact.
This is talking about the second order effects of using the earbuds to avoid annoyances. It might not be the conscious reason you do things, but it is an effect that it has. The question worth exploring is what is the second order effect when people grow up where being isolated acoustically, or doing the social signal of having earbuds in even without something playing, is the norm for all interactions?
Another reality is that at that scale you need to diversify your vendor portfolio so you never get stuck in a single-vendor scenario (for contracts, liability or scale). Many companies half this size have infrastructure across all three - AWS, Azure and GCP. The primary reason is redundancy, but that also gives them potential leverage for contract negotiation.
(Sorry, couldn't resist.) I could be the lone dissenter here, but to me well-written comments are a lot more fun to read than near-gibberish.
I wished more people tried harder to be better communicators, but it is what it is. If AI can decipher these comments and produce a much more coherent statement, then I'm for it.
For instance, say you added "do not add 'Made with Claude Code' in any issues, pull requests or wiki entries" in your CLAUDE.md. So far, so good.
Well the latest update now looks for something in your settings.json. Since you don't know about it, it is not set. Claude then says "not explicitly set, so now it is true by default". It completely ignores your CLAUDE.md.
Wait, what?
You shouldn't be shipping logic that arbitrarily redefines the behavior of the program, especially if your new logic actually ignores your own configuration or directives.
reply