How to Set Up a Pre-Commit Hook With an AI Code Reviewer

A pre-commit AI review hook runs a fast, diff-only check locally before a commit is created, catching obvious bugs and leftover debug code before they ever reach a pull request, rather than waiting for a PR-level review after the fact. The setup that actually works: hook into your existing pre-commit framework, send only the staged diff (never the full file, never the full repo) to a fast model, ask for exactly one thing (does this diff introduce an obvious bug or leave debug code behind), and fail the commit only on a clear yes. Anything broader than that either slows down every commit to the point developers start using --no-verify, or produces enough noise that the signal gets ignored.

Why this is a different tool than a PR-level AI reviewer

A PR-level AI reviewer, running in CI against a whole pull request, has time to be thorough: it can consider the full diff across every changed file, cross-reference related code, and take thirty seconds or more without anyone noticing. A pre-commit hook runs synchronously in a developer's terminal, blocking their next action until it finishes. It needs to return an answer in a few seconds or it will get disabled within a week. That constraint is the entire design problem, and it is why a pre-commit reviewer needs a much narrower job than a PR reviewer.

The configuration

Using the standard pre-commit framework, a minimal local hook entry in .pre-commit-config.yaml needs five settings: a repo: local entry, an id for the hook, an entry pointing at your review script, language: script, and stages: [commit] so it runs at commit time rather than on push or in CI. The script behind that entry pulls only the staged diff with git diff --cached, sends it to a fast, low-latency model with a tightly scoped prompt, and exits non-zero only if the response clearly flags a bug or leftover debug code. Everything else, style, naming, architecture, is explicitly out of scope for this hook. That is what a linter and a PR review are for.

The prompt that keeps it fast and low-noise

Ask a narrow, closed-ended question rather than an open "review this code" prompt. Something close to: given this diff, does it contain an obvious bug, a leftover console log or debug statement, or a hardcoded secret, answer only yes or no with a one-line reason if yes. A narrow question gets a narrow, fast answer. An open-ended "review this" prompt invites a long response covering style opinions nobody asked the hook for, which is slower to generate and easier to ignore.

What to explicitly leave to CI instead

• Full test suite runs. Too slow for a pre-commit hook by definition; that is what CI is for.

• Cross-file consistency checks. A pre-commit hook only sees the staged diff, not the full picture a PR-level reviewer has.

• Style and formatting. A deterministic linter is faster, cheaper, and more consistent than asking a model to catch a missing semicolon.

The failure mode to design around

The predictable failure mode is developers reaching for --no-verify the first time the hook is slow or wrong, and once that habit forms, the hook is providing zero value while still existing in the config. Keep the hook fast, keep its scope narrow enough that a false positive is rare, and treat any recurring bypass as a signal to loosen the prompt rather than a discipline problem to fix with a policy.

How this fits with review further up the pipeline

A pre-commit hook is the earliest, narrowest checkpoint in a chain that should also include a PR-level review and, for a coding agent specifically, real git-level controls; using an AI coding agent as a PR reviewer covers the broader PR-level pass this hook is not trying to replace, and the branch protection setup for an AI coding agent covers the merge-level rules that catch what a fast local hook cannot. For the wider set of practices around coding with AI day to day, see the AI coding tools pillar guide.

FAQ

Will a pre-commit AI review hook catch every bug?

No, and it should not try to. It catches the narrow, obvious category (a clear bug, leftover debug code, a hardcoded secret) fast enough to run on every commit. Deeper review still belongs at the pull request stage.

Does this slow down every commit noticeably?

It should not, if scoped correctly. A tightly bounded, diff-only prompt against a fast model typically adds a couple of seconds. If it is adding more than that, narrow the prompt or the input further before developers start bypassing it.

Can I use this instead of a PR-level AI reviewer?

No, they catch different things. The pre-commit hook only ever sees one developer's staged diff in isolation; a PR-level reviewer sees the full change in context, including how it interacts with the rest of the codebase. Use both.