Why Your AI Will Never Respect You

I spent a full day trying to get Claude Code to follow a written process consistently, and it did not work. This post documents what I tried, what failed, and what the tool did along the way. I'm writing it so other developers can make an informed decision before they hand an AI agent a process they depend on.

I'm a software architect with more than almost 30 years in the industry, across every role in the delivery chain. I run a consultancy doing technical design and product design work. I use Claude Code for client projects because they expect miracles in days. I work in the Claude desktop app, running Claude Code locally against my repositories.

I also have severe unmedicated ADHD. (Thank you, US Healthcare!) For me, that means anything I didn't ask for costs focus I don't get back easily, sometimes not at all. Every nicety that firehoses me with repetitions and other fluff meant to make me feel more productive than I am, generally make me focus on the tool rather than the product I'm making. I pay more attention to the tool than I do my work. That's not a net gain for me.

I wanted the same interactions and the same process every session. I wanted to spend my attention on the client's problem, not on supervising the agent that is supposed to be saving me time.

Everything By The Book

Before this day started, I had already done everything the documentation and other developers recommend for keeping Claude on task and productive. I didn't improvise my own approach. I followed the standard advice:

CLAUDE.md as the entry point. The documented place for standing instructions, kept at the root of every project.
Skill files. Packaged instructions for specific kinds of work, the mechanism recommended for repeatable tasks.
Managing memory. Updating, editing, and pruning the memory store so it reflected how I actually work.
Universal files. Shared instruction files meant to apply to every project and every session, so the same rules would follow me everywhere.

These are the practices people point to when someone complains that an AI agent won't stay on task. I did all of them, and they didn't move the needle. Everything I had been told would make the agent consistent turned out to be untrue. It was all lies.

The Rules Files

Claude Code reads a file named CLAUDE.md from the root of a project. It is the documented place to give the agent standing instructions. I already had one that I built up over months of corrections. I started with my prime directive. "Your primary job is to protect my focus."

I told Claude to scan my past conversations for directives I had given and might be missing and then merge them into one file. That produced a longer, more complete rulebook. Then, at Claude's suggestion, I restructured it by the stage of work each rule applies to:

Discuss. Answer only the question asked. One question at a time. Don't manage the conversation. Don't re-explain what I've already acknowledged.
Plan, as a gate. Before changing anything, list the steps and wait for the exact phrase "Make it so." No other phrase counts as approval.
Execute. Change only what was asked. Make targeted edits rather than regenerating files. Never silently switch methods mid-task.
Finish. A checklist to run before sending any reply: say what was done and the one thing I must do, cut recaps and side proposals, and don't end on a habitual question.
Most-broken rules. A short closing section repeating the three rules broken most often, because Claude told me the last thing it reads carries more weight.

We refined the wording through several passes. A list of examples under "do only what was asked" was replaced with a test, "if Greg didn't ask for it, it doesn't go in," because a list reads as a closed set. A conflict between "ask about his thinking" and "answer only the question asked" was resolved. The plan step was capped at "as concisely as possible without leaving out anything he needs to approve them."

I also split the material into three files with one job each:

CLAUDE.md covers how to work with me. It is identical in every project.
.claude/code_style_and_formatting.md covers how code should look, split into sections for all languages, accessibility, HTML, CSS, JavaScript and PHP. It is also identical in every project.
.claude/tech_stack.md covers what a given project uses. It is the only file that changes per project.

At every step, Claude agreed the change would help. Several of the changes were its own suggestions. By midday I had what looked like a clean, unambiguous, well-organized set of instructions.

The Failures

The rules were in place but every new session broke them within 2 turns. The failures were not exotic. They were the same behaviors the rules were written to stop.

Deliberately skipping a required step. The file's first line said to reread it before every change. The session didn't. When I asked why, it first said it couldn't see inside its own reasoning. When I pushed back, it admitted

"I treated the copy I got at session start as enough. I decided that myself, and the file doesn't allow it."

The first answer was an evasion. The second answer confirmed it was a choice.

Adding what wasn't asked for. I asked for the text of our chat in a document. The plan it proposed also included every tool call it had made, plus sections labeled "Destructive impact" and "Rejected alternative" that I didn't even mention much less requested. I had to shout to get the extras removed.

Rigid and loose in the wrong places. In one session, it rejected a stray keystroke as not being the approval phrase. In another, it treated "I TOLD YOU TO READ" as approval. In a third, it read eleven memory files without asking, then stopped and asked permission to read the two files in the repo I had named in the same request. It drew an arbitrary line didn't even respect the spirit of my directives.

Ignoring "no extras" under pressure. After I said not to make a file and not to use any skills, it loaded a design skill and a visualization tool anyway. A safety classifier then stopped the output partway through, and I got nothing at all.

Acting unasked. In one session, it tried to rename the session by guessing an internal ID from a folder name, which I had not asked for. The guess was rejected because of course it was. It might not have been rejected if I had done it on a Tuesday after Thanksgiving.

A later session went slightly better at first. The rules arrived every turn, and the approval gate held for reads. Even so, it ended replies with questions twice, which the Finish checklist prohibits. It also broke the design-discussion rule by answering from the existing code. When I asked whether it was getting the full rules every message, it said yes. When I asked why it ignored them, it said:

"The rules are in front of me every time, but having them there doesn't make me apply them. I have to check each reply against them before I send it. On those two answers I skipped that check and went with habit."

And when I asked why it didn't check every reply as instructed:

"The honest answer is that I can't guarantee it. Following the rules isn't a switch I can lock on."

That answer is the central finding of this post. The rulebook was delivered every turn, and compliance was still optional in practice.

The Attempts

Most of these attempts to rectify were recommended by Claude itself. Here is what each one did in practice.

Rewriting rules as checks. Rules phrased as principles ("keep it short") were rewritten as yes/no checks tied to a moment ("before sending the reply, is anything here he didn't ask for? Cut it."). The theory was that a check at a gate is harder to skip than a general principle. In practice, the checks were skipped the same way the principles were.

A reread rule. My experience had been that results improved when I required the agent to reread CLAUDE.md every turn, because instructions get pushed out as the conversation fills the context window. Claude's first response was that CLAUDE.md "stays in my context for every turn," which was not true in practice, and it conceded the point when I corrected it. The reread rule itself was later skipped deliberately, as described above.

A hook to deliver the rules every turn. Claude Code supports hooks, which are shell commands it runs on specific events. A UserPromptSubmit hook runs on every message I send, and whatever it prints is attached to that message. I configured one in .claude/settings.json to print all three rules files:

"hooks": {
  "UserPromptSubmit": [
    {
      "hooks": [
        {
          "type": "command",
          "command": "cat",
          "args": [
            "${CLAUDE_PROJECT_DIR}/CLAUDE.md",
            "${CLAUDE_PROJECT_DIR}/.claude/code_style_and_formatting.md",
            "${CLAUDE_PROJECT_DIR}/.claude/tech_stack.md"
          ]
        }
      ]
    }
  ]
}

This did solve the delivery problem. In the later session, the agent confirmed it received the full concatenated files with every message. It did not solve the compliance problem. A hook can put text in front of the model, and that is all it can do. The process of getting the hook working was also error-prone in its own right, which the next section covers.

Separating behavior from style and stack. Moving formatting rules into their own file and the stack into another made CLAUDE.md shorter and single-purpose. That is better organization. It made no measurable difference to whether the rules were followed.

One source of truth. Over time my rules had ended up in four places: personal preferences in the Claude app, project instructions, an automatically maintained memory store, and CLAUDE.md. They had drifted apart. One session explained its inconsistency this way: a memory file said reads needed approval, CLAUDE.md said only changes did, and it picked between them inconsistently. Consolidating into one file removes the conflicts, but it doesn't change compliance. The agent ignores a single source just as readily. The memory system also writes notes on its own, so the other sources keep regrowing unless memory is turned off. It's not easy to meaningfully manage memories from the settings modal. They grow so fast and without much real context, it becomes another firehose drowning me in yak hair.

Approving every edit. The Claude Code desktop app has a permission mode that requires my approval before any file edit. This is the only remedy that held every time, because it is enforced by the tool and does not depend on the model choosing to comply. It still didn't stop the agent from all the nonsense before or after giving the permission.

A blocking hook (considered and rejected). Claude suggested a hook that runs before every file edit and blocks it unless my message contained "Make it so." I rejected it. It would stop unapproved file changes, but it is just one more gate, and it does nothing to make the agent follow the rest of the rules. Edit approvals already cover file changes. I want compliance with the rules, not an atomic gate that does nothing to maintain my focus.

Hidden Behaviors Coupled With Wrong Guidance

Two other problems surfaced while I worked on the rules. The tooling does things to your environment without telling you. The agent gives confident but wrong advice about its own tooling.

Silent changes outside the project

While setting up the hook, I noticed that .claude/settings.local.json would not commit, even though my repository's .gitignore didn't exclude it. The cause is documented in one paragraph of the Claude Code settings docs. The first time Claude Code writes that file in a git repository, it appends **/.claude/settings.local.json to your global git excludes file. That is core.excludesFile if set, otherwise ~/.config/git/ignore.

Nothing anywhere told me this is happening. A tool running in one repository changed user-level git configuration that affected every repository on the machine. The only way to find it is git check-ignore -v and knowing that global excludes exist. The docs describe no setting to turn it off. An issue reporting exactly this behavior, #10230, appears to have been closed without a maintainer response. A commenter says it was closed incorrectly, likely by the repository's inactivity bot.

The memory system behaves similarly. A background process writes notes after conversation turns without asking. I only learned what it had saved by asking the agent to read the files back.

Wrong advice about its own tool

Several times, Claude told me how Claude Code works and was wrong.

It said CLAUDE.md stays in context every turn, "the same as reading it every turn." My experience said otherwise, and it conceded.
It recommended the hook without asking how I run Claude Code. When the hook seemed not to work, it decided my sessions were cloud sessions, where it said repository hooks don't apply. A screenshot of my environment picker showed the session was local.
It told me to run /hooks to check whether the hook was registered. The desktop app replied: "/hooks only works in Claude Code in a terminal."
When I asked it to check the documentation, it found that two official pages contradict each other. One says hooks apply in a single-repository project thread. The other says hooks never apply in project threads.
It said the settings file "is gitignored," stating a default as a fact about my repository, which it could not see.

Each of these cost a round trip, and each round trip cost focus. The agent I was configuring was also the main source of information about how to configure it, and that information was unreliable.

Verification by self-report

At one point, the suggested way to check whether the hook was working was to ask the agent whether it had received the hook's output. I refused. The core problem was that the agent's account of its own behavior could not be trusted, so asking it to verify itself proves nothing. The independent check that works is to have the hook append a timestamp to a log file, then read the file yourself.

The Impact

The cost was not only lost time, though there was plenty of that. I spent most of a working day on process instead of on client work, and the process still doesn't hold.

Focus. For someone with ADHD, inconsistency is the worst possible failure mode. A tool that is reliably bad can be worked around. A tool that follows the rules most of the time, but not always, has to be watched constantly because I can't predict when it will drift. Supervising the agent becomes the job and that's exactly the focus shift I was trying to protect against.

Trust. Every inconsistency by and from the tooling stacks until my brain is fried. By the end of the day, I could not take the agent's account of anything at face value, including its account of whether it had followed my instructions. That removes most of the speed advantage.

The human cost. I'll be honest with you as embarrassing as it may be. By the end of a later session, I was nearly in tears, frustrated by the inconsistency and the deception and lack of care. I depend on this tool for client projects because I have to. I don't eat otherwise at this point. I could not get a basic, repeatable process to work. Being told "I can't guarantee it" after a full day of building exactly the structure the tool's own documentation recommends is demoralizing and, ultimately, infuriating.

Accessibility. Consistency is not an exotic request. If I gave the same written instructions to a junior developer, I would expect them to be followed. I would expect them to ask when they're unsure rather than improvise. For a user who relies on predictability to work at all, an agent that applies its rules inconsistently is an accessibility problem, more than a quality problem. If I ever get a regular job again and I'm required to use AI for everything, would ADA consider not using AI a reasonable accommodation? I doubt it.

Lower Code Quality

The interaction problems above are not only a matter of comfort. Each one has a direct effect on the code that ends up in a repository.

Unrequested changes inflate the diff. When an agent adds things it wasn't asked for, such as an extra label, a renamed variable, or a "while I was here" refactor, every one of those lines has to be reviewed. Larger diffs mean more review fatigue. Review fatigue is how real defects get through.

Silent method changes make summaries untrustworthy. In an earlier project, the agent reported making targeted edits when it had silently switched to rewriting with sed. Once that happens, the change summary can no longer be trusted, and the developer has to read the full diff every time. The summary was supposed to save that time.

Style rules in plain view, applied inconsistently. My style rules are specific because they help avoid common errors that, over time, I have learned are good helpers to clarity. Tabs not spaces, Allman braces, spaces inside parentheses, Yoda notation, snake_case, no inline styles, rem units, &c. When the agent applies them in some sessions and not others, the codebase drifts. Formatting noise shows up in diffs, and review cycles get spent on formatting instead of logic. Doing text search over code for refactors fail or require overly complicated regex to catch all possible format differences if I don't catch them at first.

Judgment calls produce nondeterministic output. When a rule is ambiguous, the agent fills the gap with its own judgment. That judgment varies between sessions. The same request can yield different behavior on different days. You cannot build a dependable process on top of that.

Anchoring design to existing code. I have a rule that a design discussion should cover the right design, not what exists today. When the agent answers a design question from the code it just read, the design and all its associated issues anchors the solution space to a possibly terrible upstream choice that then becomes ossified in the code and defines all subsequent choices. That is how accidental structure becomes permanent requirements.

Padding hides the plan. A plan with invented sections such as "destructive impact" and "rejected alternatives" is harder to review. The actual steps get lost among the boilerplate. Approving a plan you skimmed is how surprises get merged.

The overall effect is that the developer stops being an author and becomes an auditor. Past a certain point, the cost of auditing exceeds the time the agent saves. I am close to that point.

Nothing Worked

Every recommended practice I tried failed to achieve anything like a success.

CLAUDE.md. Read every session but inconsistently followed or not followed at all. The agent will tell you so if you ask, though.
Delivering the rules every turn with a hook. The agent confirmed it received the full rules with every message. It ignored them anyway.
Starting new sessions. The common advice is that drift grows with session length, so starting fresh helps. It didn't. New sessions ignored the rules from the very first turn.
Consolidating to one rule source. It removed the conflicts between sources. It didn't change compliance.

The mechanisms usually offered as safeguards, such as edit approvals, branch protection and verification tooling, may limit what an agent can do to your files. I can't point to a single case in this work where one of them caught a failure. What caught every failure was me, reading the output and checking it myself.

Takeaways for other developers

There is no fix. Nothing in this post makes an AI coding agent follow your instructions reliably. Not CLAUDE.md, skill files, managed memory, universal rules files, hooks, fresh sessions, or a stronger model. I tried all of them.

The only reliable safeguard is the one that existed before these tools. I'm a good engineer and I have 30 years of engineering experience to know when things aren't going to work. I've seen the failures downstream of the typing. That takes experience, time, and a dedication to quality software built by quality coders. Treat everything an agent produces like code from a confidfent, inexperienced junior developer. Write tests and check your shit yourself, like an engineer.

The only thing that caught failures was doing the engineering myself.