Fixing AI Drift with Git Hooks: Geoffrey Huntley's Forced Agent Correction Technique

AI coding agents are increasingly like "disobedient new employees": you give them the rules, and they insist on doing things their own way. In "nobody should type code by hand anymore. here's what's left." Geoffrey Huntley's solution isn't to keep rewriting prompts — it's to nail the rules onto Git hooks.

Why Constant Correction Is Doomed to Fail

Huntley describes a scenario familiar to almost anyone who heavily uses coding agents: he has a "diagnostics library" and wants all of the agent's observability-related calls to go through this unified entry point. But the agent doesn't always comply — it may call the underlying observability module directly, bypassing his wrapper layer.

Faced with this problem, Huntley says he could "introspect and update AGENTS.md" — that is, observe the agent's behavior and keep writing new rules into the AGENTS.md config file. But this approach has a fundamental flaw: "there's still a delta, and it'll drift." There will always be a gap between the rules document and the agent's actual behavior, and that gap will keep widening as the codebase evolves. Every rule you add gives the agent one more way to circumvent it.

This is essentially using an infinitely maintained text file to chase down a continuously changing actor. In traditional engineering, we've long known that constraining behavior through documentation is unreliable — what's actually reliable are compilers, linters, and CI pipelines.

Sinking Constraints Down into Pre-commit Hooks

Huntley's approach turns the specification from a "guiding document" into a "mandatory gate": write a pre-commit hook that scans the git diff and checks for direct calls to the observability module — that is, calls that bypass the diagnostics module.

Once a violation is detected, the commit fails outright and injects a prompt to the agent telling it to use the diagnostics library.

The beauty of this mechanism is that it's not a suggestion — it's a block. The agent hits a wall in its execution flow, and plastered on that wall is exactly the right approach it needs. Huntley's assessment is blunt: "All of a sudden it's ten out of ten." — instantly perfect performance.

A pre-commit hook is a client-side hook mechanism provided by Git: place a script named pre-commit in the .git/hooks/ directory, and every time you run git commit, Git will invoke it before actually creating the commit object. If the script exits with a non-zero status code, the commit is aborted and the contents of the staging area won't be written to version history. This makes pre-commit a natural "gate point" — it happens before code enters the repository (lowest cost, smallest rollback price), while also having direct access to the diff of the current commit for static analysis. In practice, pre-commit frameworks (such as Python's pre-commit package or Husky) are commonly used to manage these scripts uniformly, making it easy to distribute and version them within a team. Understanding this mechanism is the prerequisite for understanding the approach in this article: Huntley is precisely taking the question of "what the specification should look like" from an ignorable Markdown document and turning it into a script that must execute and cannot be bypassed.

Why This Is Smarter Than Editing AGENTS.md

The traditional approach to agent correction is to add information on the "input side": longer system prompts, more detailed AGENTS.md files, more examples. These approaches have two problems: first, the agent isn't guaranteed to read or follow them; second, as the codebase changes, the rules quickly become outdated.

Huntley's approach moves the correction point to the "execution exit": no matter what the agent reads or thinks, as long as the diff it produces violates the rules, it's immediately blocked. The key difference here is that the interception point is a deterministic code check, not a probabilistic model interpretation.

This idea aligns closely with the core proposition of the field of "agentic engineering": rather than expecting the model to get it right every time, use engineering gates to ensure errors can't reach the main branch. The placement of the pre-commit hook is also perfectly chosen — it's the lowest-cost interception point before code enters the version repository.

AGENTS.md is a convention file that has become popular in recent years with the spread of coding agents: it's placed in Markdown form at the repository root (or in subdirectories) to describe project structure, coding conventions, common commands, and prohibited practices to the agent. Different tools read it differently, but the essence is the same — "stuff some instructions into the context window." Its problems share the same root as system prompts: the model may not read it, may forget it after reading, may still fall back on its training-time default habits after forgetting, and its effectiveness is probabilistic. Huntley's point isn't to deny the value of AGENTS.md (it's still useful as background explanation), but to point out that it shouldn't be used as a "constraint." Constraints need determinism; explanations can be vague. Mixing the two in one document leads to the classic dilemma of "the rule is written, but the agent bypasses it anyway." Distinguishing "context" from "gate" is the first step in bringing engineering discipline into agent workflows.

A Transferable Pattern

This playbook's applicability extends far beyond the diagnostics library. Any scenario where "I want the agent to always go through a unified entry point and never take shortcuts" can be implemented the same way: enforce the company's wrapped logging module, prohibit directly reading environment variables in favor of going through a config layer, prohibit introducing certain types of dependencies in specific directories... As long as the constraint can be written as a static check, it can be written as a pre-commit hook.

Huntley's remarks are worth quoting because they demonstrate a shift in thinking from "prompt engineer" to "agent process engineer": rather than conversing with the model, build a structure for the model. AGENTS.md can be ignored, but a failed commit can't run past you.

Agentic engineering is a term positioned in contrast to prompt engineering: the latter's core work is polishing input text, hoping the model will be more obedient on the next generation; the former's core work is designing the environment the model lives in — tools, permissions, feedback loops, failure boundaries. It borrows from traditional software engineering's philosophy for handling "unreliable components": don't expect every module to always be correct, but use interface contracts, type systems, and CI gates to confine errors within controllable bounds. From the agentic engineering perspective, the model is a high-variance but high-output executor, and engineering's job is to build runways and guardrails for it, not to repeatedly persuade it not to cross the line. Huntley's pre-commit approach is precisely the concretization of this idea: rather than trying to eliminate the agent's "disobedience," make disobedience physically unable to land.

One-line Summary

Rather than repeatedly writing prompts to correct agents, use pre-commit hooks to turn specifications into gates that can't be bypassed.

Paragraph Summary

The article cites Geoffrey Huntley's view that using constantly updated AGENTS.md files to correct coding agent behavior has a fundamental flaw: there's always a delta between rules and behavior, and it will keep drifting as the codebase evolves. Huntley's alternative is to turn the specification from a guiding document into a mandatory gate — write a pre-commit hook that scans the git diff, and whenever it finds code bypassing the unified diagnostics entry point by directly calling the underlying observability module, it fails the commit while injecting a prompt to the agent telling it the correct approach. The beauty of this mechanism is that it's not a suggestion but a block — when the agent hits the wall, the answer is plastered right on it. The author further points out that this essentially shifts the correction point from probabilistic model interpretation to deterministic code gates, a typical agentic engineering approach that can be transferred to any constraint scenario expressible as a static check.