Claude's co-authorship attribution in my commits, so I started tearing through every possible config file. I checked
~/.claude/settings.json
, settings.local.json
, and scanned 38 different project entries. I even ran a sweep of my entire user directory for any .json
or .md
files that might contain the key. Nothing.The "switch" I thought I had flipped was actually just a single sentence in a rules file:
Note: Attribution disabled globally via ~/.claude/settings.json.
This line lived in ~/.claude/rules/ecc/common/git-workflow.md
. Because rules files are loaded into every session, the model simply accepted this statement as a factual constraint of its environment. The actual configuration key it referenced (includeCoAuthoredBy
) was deprecated, and the current one (attribution
) wasn't even in my config. By default, the feature was active, but because the prose told the model it was off, the model behaved as if it were off. The description of reality overrode reality itself.
The danger of "invisible" configuration #
This highlights a massive shift in how we think about AI workflow management. In a traditional software stack, documentation describes the system. In an agentic system, prose is the system.
I manage a complex multi-agent setup using Claude Code—19 specialized agents coordinating via on-disk artifacts. I use a combination of always-loaded rules files and system prompts filled with handwritten constraints. To a developer, these look like documentation or "guidance." To the LLM, these are hard constraints.
The problem is that these "prose configs" have none of the guardrails of a real control plane:
No Schema: There is no validator to tell you if a sentence is contradictory.No Type Checking: You can't "lint" a paragraph to see if it's still applicable.No Version Control Accountability: Unless you're meticulously tracking every rule file, a single sentence can change the global behavior of your agent without leaving a trace in your primary settings.
When constants outlive their source #
I saw this again with a "frozen" constant in a system prompt. I had a subscriber count hardcoded as a literal string, marked as "FROZEN" so the LLM wouldn't paraphrase it. I updated the number in all my structured source documents, but the LLM kept spitting out the old, incorrect figure in generated artifacts.
The structured data was correct, but the system prompt—the "prose" layer—still held the old value. Because the prompt is the ultimate authority for the model during a session, the "canonical" data in the files was ignored in favor of the literal string in the instructions.
For anyone building a deep dive into LLM agents, the lesson is clear: treat your .md
rules and system prompts with the same rigor as your .yaml
or .json
configs. If you put a claim in a rules file, you aren't just documenting the behavior—you are programming it.
Next Can you actually trust your LLM eval suite to catch a regression? →
an AI side-hustle playbook, with plenty of directly applicable cases.
All Replies （0） #
No replies yet — be the first!