Three days later Anthropic published a piece saying they had removed over 80% of Claude Code’s system prompt — the standing instructions a model gets before you type anything — “with no measurable loss on our coding evaluations.” In plain terms: they deleted most of the hidden house rules that tell their coding assistant how to behave, and the results didn’t get worse.
Claude Code is their coding agent, but the idea applies everywhere. ChatGPT, Claude in the browser, Gemini — they all start every conversation by reading some form of system prompt or custom instructions. Whatever tool you use, there’s a block of rules the tool reads first, and you rarely look at it again once it’s written — even though it’s what makes your AI sound like you instead of a generic support bot.
So which is it: more instructions, or fewer?
I closed that Field Note with this:
Remember that for every prompt, there is (usually) an equal and opposite prompt — whenever you’re defining what you want or don’t want out of your AI, you must also express the opposite!
Three days later the opposite advice came from Anthropic instead of from me.
What they actually deleted
Here’s their own explanation of what went wrong: “we found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills.” Think of those CLAUDE.md files and skills as saved recipes and project rules for their agent — the same kind of thing you might have written into ChatGPT’s custom instructions, a Claude Project, or a Gemini configuration screen.
Here is a rule they cut, word for word:
In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.
And here is what replaced it:
Write code that reads like the surrounding code: match its comment density, naming, and idiom.
The first is a rule, the second is a standard. The rule tries to predict every situation in advance and gets it wrong the moment the situation is unusual — some code genuinely needs a long explanatory block. The standard describes the outcome and lets the model judge the specific case.
If you don’t write code, let’s swap in something more familiar. A rule is “never send an email longer than 200 words.” A standard is “write emails that sound like my last update to the team about pricing.” The rule will be wrong the moment a longer message is exactly what the situation needs; the standard keeps working, and your AI can’t guess it unless you tell it.
They’re blunt about why the old rule existed. Those constraints “were once needed to avoid worst case scenarios,” and the tradeoff was accepted because older models got it wrong too often otherwise. The rule existed because the models back then needed it. That stopped being true, and the rule stayed.
They name a second problem, and it’s the one I’d expect most people to hit, whether you’re in Claude Code or just using ChatGPT with a long custom-instructions box. When you pile up instructions across a system prompt, a project file, and the request itself, they start contradicting each other; Anthropic found their own transcripts contained “several conflicting messages in a single request” — one place saying leave documentation as appropriate, another saying do not add comments.
Nobody wrote that contradiction deliberately. It built up one reasonable addition at a time. It’s not a mistake anyone made; it’s what happens by default to any set of instructions that only ever grows, whether those instructions live in CLAUDE.md, a Custom GPT, or Gemini’s settings.
Why last week’s argument still stands
Their piece also says what to keep:
It’s best when skills encode particular opinions, knowledge, or best practices that are particular to you, your team, or product.
In their world, those “skills” live in CLAUDE.md files; in yours, they live wherever you’ve written custom instructions — the box you filled in for ChatGPT, the notes you pinned to a Claude Project, the preferences you saved in Gemini. The difference is where the rule came from, not how many of them you have.
The rules they deleted were generic — precautions any user might need, written in advance against a worst case, aimed at a model that couldn’t yet be trusted to judge. The rules they kept are specific — things the model cannot work out, because they’re about you. A writing standard is the second kind. Nobody writes one to prevent a catastrophe; you write it because the model has no way of knowing your preferences, your house style, how your clients actually read, or what has fallen flat with them before.
So both things hold. Delete the rules you added because you didn’t trust it. Keep the ones that tell it something about you. If you’ve ever written “this is how to sound like me” into a custom-instructions box, that part still stands, even after Anthropic pulled most of their generic rules out.
I’d done something like this last week already. When I tested that ADHD-focused instruction set, I didn’t just install it; I compared its ten rules against the setup I’ve been tuning for a year. Six I already ran. I took on the other four, including one I’d never have thought to write: cap lists at five items.
The test: has this bitten me?
Here’s how I sort mine.
Not “is this a sensible instruction.” Nearly all of them are sensible — that’s why they got written in the first place. The question is whether there was a specific occasion, one you can actually name, where the absence of that rule cost you something: a bad draft, a wrong tone, an invented fact you nearly published.
If you can name the incident, keep the rule. It’s carrying information the model has no other way of getting.
If you can’t — if it’s in there because it seemed like a good idea, or you read it in a thread somewhere, or you were just being thorough — it’s a candidate for deletion. Keeping it isn’t free. It takes up room alongside the rules you added after something actually went wrong, and on a long enough list it will eventually contradict one of them.
One that fails the test. Anthropic’s deleted comment rule is exactly it: never write multi-line comment blocks, one short line max. Sensible. Defensible. Written against a model that used to over-explain everything. But there’s no incident sitting behind it — and when a piece of code genuinely needed explaining, the rule was wrong, and so it went out the window.
One that passes. Cap lists at five items. There’s no principle behind that one either, and I couldn’t argue it in the abstract. It’s there because it suits how I read, and nothing in a model’s training would let it guess that about me. So, it stays.
The difference isn’t how sensible they sound. If you read them cold, the first one sounds more professional than the second. The difference is that one of them came from context.
If you want a place to start looking, the rules most likely to fail are the ones written in the abstract: blanket “never do X” bans, tone instructions lifted from someone else’s setup, and anything you added in the first week of playing with LLMs, before you knew how the thing actually behaved.
The catch
I only know which of my rules pass that test because I happened to have some time to tweak them.
I spent it going through my own setup — mine lives in files rather than a settings box, but it’s the same pile of instructions you’ve filled in for ChatGPT — and found rules that were no longer doing anything. Not because I’m rigorous about it. Because I had the time that day to test and tweak, and most weeks I don’t.
None of them were wrong enough to break anything. They had just stopped applying, and they were still in the file alongside the rules I added after something actually went wrong.
That’s the actual reason these piles grow. Adding a rule is quick and feels like progress. Checking whether an old one is still worth having takes real time and feels like admin. So we add, and add, and the contradictions pile up without anyone noticing, because nothing visibly breaks; it gets slower and vaguer, the instructions argue with each other more, and you assume that’s just how the tool behaves now.
I’d rather tell you that than hand you a framework I only run when I’ve got a free weekend.
Try this tonight
You don’t need a whole day – ten minutes will give you something useful.
Open whatever holds your instructions — your ChatGPT custom instructions, your project file, that block of text you paste at the start of every session. Read it as if someone else wrote it. Against each line, ask the one question:
Can I name the time this bit me?
Then delete two that fail. See if anything gets worse.
I’d bet nothing does. And you’ll have made room for the rules that came from something real.
One honest limit before you go: if you’ve been using AI for a couple of weeks and your instructions run to three lines, this isn’t your problem yet. Go and write more rules — last week’s advice was for you. This week’s is for everyone whose file has got long enough that they’ve stopped reading it.
— Jim
Hit reply and tell me the daftest rule you found in there — the one you couldn’t remember writing.
Other AI news this week
Two stories worth your time, minus the hype.
AI detectors are getting funded to flag more ordinary work. Pangram, based in New York, raised $9 million led by Menlo Ventures and launched a text model it says is over 99% accurate at spotting AI-assisted and mixed human-AI writing, including text run through “humanizer” tools. Those numbers are the company’s own, not independent benchmarks. The more interesting bit is what they’re trying to detect. Not mass-produced fake articles — any AI involvement at all, which now covers a lot of ordinary work. Their founder told the New York Times that using AI as an assistant is “completely OK.” The tool still flags it. If clients, editors, or schools start running systems like this, the practical question won’t be “did you use AI?” so much as “what part did you do yourself?”
Zuckerberg predicts billions of personal agents — Meta’s own quarterly numbers say more. He told investors it’s “extremely unlikely” that five years from now we won’t have “billions of people with a personal agent… working on your behalf 24/7.” Maybe. Look lower down in the same set of results. Meta reported free cash flow of $784 million for the quarter, down from $8.55 billion a year earlier, a 91% drop tied to what it’s spending to build this. Further down again, Meta says more than a million businesses already use its agents across WhatsApp and Messenger. That’s the bit I’d pay attention to. Customer conversations are being routed through AI inside the apps people already have on their phones, now, at small-business scale.
The system I keep the final say over: most of my task setup live in Notion. If you’re a startup or solo founder, you can get 3 months of Notion Business free — unlimited AI, no credit card through my link. Start your 3 free months →
Notion affiliate link — I get a small credit if you start a trial
Signal Over Noise helps you sort the AI worth your time from the hype. If it was useful, pass it to someone who’d want it too.
Signal Over Noise is weekly, reader-first publication on AI "without the hype" published by Jim Christian. If you've been forwarded this issue, you can subscribe here: go.signalovernoise.at.
Field Note: Five words for the same thing At the moment there are no fewer than five phrases going round that all describe the same work, and if you’re trying to work out which one to learn first, I have good news. The phrases are: - Prompt engineering - Context engineering - Agent engineering - Workflow engineering - Graph engineering They aren’t five subjects. Rather, they’re five views of the same system, and they overlap more than the names suggest: Prompt engineering is what you type....
Second Brain Chronicles Update Dear Reader, First off, my apologies for not posting in a long time. When I started Second Brain Chronicles as a newsletter, it was more out of enthusiasm for this cool thing that I was building, and wanted to share with the world, alongside other creators and tinkerers with the same goal. I'd toyed with gating content, monetising content, and it just didn't feel right, nor did the current kit.com method of distribution. But it came down to this: the field is...
Field Note: The open-source argument I'd been missing In June I wrote about Banco Santander open-sourcing its AI tooling — the bank published the code that tests whether its own models discriminate against people. I gave the usual reasons that’s a good thing: outside scrutiny, verifiable claims, a governance document you can read for yourself. Jofish Kaye wrote back with a better one. He’s a friend, a subscriber, general mensch, and he’s VP of Research at Inflection AI, so he’s seen this from...
