Make the Commit Gate Enforce the Diagnostics Path—Without Replacing Review

A pre-commit hook can turn an observability convention into something that rejects a bad diff before it lands. That matters most for teams running coding agents: you can tell an agent what the approved path is, but only a check on the diff can confirm it took that path.

On October 13, 2026, Simon Willison's Weblog reported Geoffrey Huntley's proposal to scan Git diffs for direct calls to observability modules that bypass a diagnostics library ¹. Huntley's point: updating AGENTS.md after an agent skips the library leaves a gap that can drift. His hook instead fails the commit and tells the agent to use the approved path ¹. He called the result "ten out of ten" ¹.

The idea earns attention because it's narrow, not because it's clever. It doesn't settle whether every instrumentation choice is correct, and a green check is not a substitute for review. Its whole value rests on one question: does the rule catch the unwanted pattern with low enough noise that developers and agents can actually act on it?

Why use pre-commit hook checks as AI coding agent guardrails?

An instructions file tells an agent what the team expects. It's guidance, and it doesn't check whether the resulting diff followed it. One reading of Huntley's observation is that a post-hoc update addresses the current mismatch, while the convention can drift again ¹.

A diff check moves the convention from the prompt to the gate. If a change calls an observability module directly instead of going through the diagnostics module, the hook rejects it before the commit lands ¹. That's a different kind of control than a prompt: one describes desired behavior, the other tests for a specific violation. It also fits a broader pattern of putting runtime governance controls around agents instead of relying on instructions alone.

Analysis: One reason teams might apply this approach beyond agents is that people can also miss conventions. A check can enforce a known pattern, but it cannot establish that the pattern captures the team's whole observability policy.

What should the first observability standards check cover?

Start with Huntley's reported rule: scan the diff for direct calls to observability modules that bypass the diagnostics module ¹. The source doesn't specify languages, file types, module names, exact call signatures, or matching logic ¹. Those are implementation choices for the team building the check, not features of Huntley's proposal.

Resist turning version one into a general observability linter. Every additional pattern means more matches to explain and more exceptions to maintain. A small rule is easy to evaluate: did this change introduce a direct call the team wants routed through the diagnostics library? A big rule is a project.

Where practical, scope the check to changed lines or files rather than the whole repo. That avoids blocking unrelated work because of pre-existing violations, and it makes failures easier to read: the current diff introduced this match. That's a recommendation, not a detail from the source.

Illustrative policy, not Huntley's implementation:

For each changed line:
  if it adds a direct observability call outside the approved diagnostics path:
    fail with the location and the approved path

The detection mechanism is left open on purpose. A text match is simple to ship but brittle once syntax varies; a parser is more precise but adds language-specific maintenance. Pick based on the repository and the cost of false matches, and run the rule against real diffs before making it blocking.

How should legitimate exceptions work?

The source doesn't describe an exception mechanism ¹. That's a policy gap to close before you enforce this broadly.

Analysis: Favor exceptions that are explicit and reviewable over blanket exclusions. A narrowly scoped exception should state which call or location is allowed and why the diagnostics path doesn't fit there. Keep the default strict for ordinary application code, and make exceptions visible, either in the diff itself or in an adjacent policy file. Don't exclude whole directories unless someone can explain why every call in that directory needs different treatment.

The failure message is part of this policy, not an afterthought. Huntley's hook fails the commit and prompts the agent to use the diagnostics library ¹. A useful message should name the matched location, explain the direct-call pattern, point to the approved path, and say how to request an exception. That gives a developer or agent something to do, not just a red light.

What does an agent-friendly failure look like?

A failed check only helps if the agent can respond without guessing. A message might read:

Direct observability call detected in the changed code.
Use the diagnostics library for this operation.
If this is an approved exception, document the reason and request review.

That wording is illustrative, not a quote from Huntley or a description of the hook's real output. What's attributed to him is simpler: a failed commit paired with a prompt to use the diagnostics library ¹.

Analysis: Keep messages specific, but don't let them imply the mechanical fix is always right. A direct call might be a genuine bypass, or it might expose a case where the approved wrapper doesn't support the behavior the code needs. The message should make that distinction reviewable, not push the agent to keep editing until the warning disappears. Clear permission boundaries for agents follow the same logic: say what is allowed, and make the exceptions visible.

Huntley's "ten out of ten" ¹ is a reported judgment, not a benchmark. The source gives no test setup, no false-positive rate, no language coverage, and no independent evaluation ¹. Read it as one person's reaction, not measured effectiveness.

What a passing hook proves about AI-generated code

A passing check proves only that the diff didn't match the bypass pattern the team encoded. It doesn't prove the diagnostics library was used correctly, that telemetry is complete, or that the instrumentation belongs where it was added.

Analysis: Reviewers still have to judge intent, error handling, sensitive data exposure, and whether instrumentation fits the boundary being changed. A diff can satisfy the rule and still be operationally useless. It can also fail the rule for a legitimate reason the rule should have let through.

Use the hook to stop a repetitive, known class of violation, not to replace AI-generated code review. That matters more, not less, as agents produce more code: the hook constrains one implementation path, while a human still has to evaluate the behavior and design around it. More code shipped is a throughput number, not proof of productivity, and a passing check doesn't change that.

What should teams measure before expanding the rule?

The source is silent on false-positive rate and review burden ¹. Measure both before you add more patterns or roll the rule out to more repositories.

Start by classifying rejected changes:

• Genuine bypasses
• Legitimate exceptions
• Detector errors
• Failures the developer or agent couldn't parse

Then watch the correction loop. How often does the agent fix the diff correctly after seeing the message? How often does a human have to step in and rewrite it? Is anyone disabling the check to get past it? These are the signals that tell you whether the rule is earning its keep or just generating noise.

Assign an owner, too. The source doesn't say how the hook gets maintained as the codebase evolves ¹. Someone needs to revisit the detector when approved wrappers, languages, or repo structure change. Otherwise an accurate rule today becomes either stale or overly permissive next quarter.

A rollout sequence worth trying

1. Document the approved diagnostics path and the direct-call patterns that are out of bounds. Huntley's proposal gives you the core distinction, direct calls versus the diagnostics module, but the exact pattern list is yours to define ¹.
2. Run the detector in report-only mode against real diffs. Use the output to find ambiguous matches and legitimate exceptions before anything starts failing commits.
3. Turn on the narrowest reliable version of the rule. Make failure messages actionable; keep exceptions explicit and reviewable.
4. Compare hook results against human review regularly. Tighten or loosen the detector where it misses real bypasses or blocks legitimate work.

The hook isn't there to decide whether instrumentation is good. It's there to make one specific, agreed-upon path hard to bypass by accident, whether the author is an agent or a human, while design judgment and code review stay exactly where they were.