Idea #1
Adding more rules to an agent's system prompt actively degrades performance once past a threshold, but adding hooks (middleware) improves it. A study built a harness that let a coding agent self-evolve its own AI layer — appending rules and modifying hooks — and used a separate evaluator to judge whether changes improved performance across easy/medium/hard tasks. When the agent was allowed to evolve only its rules (system prompt), performance dropped relative to the control. Agents appending rules split the model's attention across an ever-growing list of conventions, diluting focus even when individual rules would help in isolation. When hooks (middleware) were evolved instead, performance improved across easy and medium tasks. Only hard tasks showed a slight regression from hooks alone, because hard tasks benefit from co-evolving the full AI layer together. The actionable lesson: treat your rules file as something to keep lean and prune aggressively, and route process-oriented requirements into hooks. Anthropic's own reduction of the Claude Code system prompt by ~80% is consistent with this finding — less rule surface, not more.
Idea #2
Pre-tool-use hooks function as programmable security gates that intercept and block specific tool calls before they execute, and can redirect the agent rather than just crashing it. The hook script receives the pending tool call, evaluates it (e.g., via regex on the file path), and exits with code 0 (allow) or code 2 (block). Critically, the block can include a message that feeds back into the agent's context, letting the agent adapt rather than stall. Two strong use cases: (a) blocking reads of secrets files — when asked 'what is my OpenRouter API key in .env?', the agent tried to read the file; the pre-tool-use hook intercepted, returned 'Access to secrets is not allowed. Use .env.example instead', and the agent pivoted to reading the example file. (b) Enforcing read-before-edit coupling — a hook on edits to a specific file checks whether the agent has already read all coupled files in the session; if not, it blocks and lists what must be read first, preventing context-blind edits. The broader principle: any 'never do X' or 'always read Y before doing Z' rule that is about tool calls specifically is a pre-tool-use hook, not a rule, because a hook guarantees the check happens for every matching tool call without relying on the model to remember the constraint.
Idea #3
A simple two-question audit separates rules that should stay rules from rules that should become hooks: (1) Does this rule name an event? (2) Does it encode a judgment or convention? If it names an event — 'when X happens, do Y' — it belongs in a hook, not a rule, because the model may forget the trigger. If it encodes judgment or a domain constraint — 'money is stored as integer cents, never floats' — it belongs in a rule, because there is no event to hook; this is context the model needs for every decision it makes. If it's neither (e.g., 'write clean code'), delete it: the model already knows, and the line just dilutes the rules file. Applied to a sample rules file in the video: 'after implementing, run the tests' → stop hook; 'never read the .env file' → pre-tool-use hook; 'at the start of every session, read decisions.md' → start-session hook; 'before editing routes/, read rag/citations.py' → pre-tool-use hook on that file path; 'money is integer cents' → stays a rule. This framework is mechanical enough to run as a quick pass over any existing CLAUDE.md or agents.md today.
Idea #4
Hooks are the only deterministic layer in an AI coding harness; everything else is guidance. Rules, skills, and prompts are all probabilistic — the model interprets them and may miss steps, especially across long sessions or large codebases. Hooks, by contrast, are shell/Python/TypeScript scripts wired to harness events (pre-tool-use, stop, post-tool-use, sub-agent-stop, start-session) and executed by the harness itself, not the model. This means a hook truly guarantees its action happens — no LLM attention required. The practical implication is that any workflow requirement where the cost of missing it even once is non-trivial should be a hook, not a rule. A rule saying "run tests after implementing" will sometimes be skipped or partially skipped; a stop hook that exits with code 2 when the test suite is red literally prevents the conversation from closing until the tests pass. The canonical demo: a stop hook runs the full test suite on a trivial "add one line to the README" conversation; the suite fails; the hook blocks and feeds the failure output back to the agent, which is forced to resume and fix it — all without any instruction in the conversation itself.
Source: Watch This If Your Coding Agent is Ignoring Your Rules (You Need Hooks) (Cole Medin)
Text summarized and optimized using Anthropic’s models and reviewed by a human.