On October 18, a tool passed 200 points on Hacker News. It is called Sphinx, and its one-line pitch is precise: it quizzes you on your AI's code before shipping.

Here is how it works. You run git push as usual. Git pauses. A separate reviewer model reads the change you just pushed and asks one question: what happens when this change goes wrong? Answer correctly and the push continues. Answer wrong and you learn why, then try another scenario.

The nature of the question is the point. It is not "what does this code do" but "what breaks when this code is wrong." It is checking whether you understand the failure conditions, not whether you read the code.

What it is

Sphinx (MIT, github.com/parthh01/sphinx)

- Form        : a Git hook for agent-assisted development
- Trigger     : a push to a protected branch
- Reviewer    : a model that never saw your chat reads only the diff
                and asks a question
- Interaction : right -> the push proceeds
                wrong -> learn why, try a new scenario
- Supports    : Codex, Claude Code, Cursor, OpenCode, Pi, or plain Git
- Model        : your existing coding agent, OpenRouter, or any
                OpenAI-compatible endpoint
- Safety       : your answers never reach the coding agent,
                .env files and keys are never opened
- Skip         : sphinx yolo (every skip is logged)

Installation is one line.

# Node 22.19+ · macOS, Linux, or WSL
npm install -g sphinx-understand
sphinx install

# then push as usual
git push

sphinx install connects Git and your coding agents and asks which model should review. The project says it is built to run on minimal tokens.

What kind of question it asks

The example the project published captures the tool's character. The change edits a Stripe webhook handler.

$ git push origin main

sphinx · understanding check for main
11 files changed · +5,012 -3,147

Sphinx : Your webhook handler now saves the event ID before
         calling charge(). Stripe times out and sends the same
         event again. What happens on the retry?

You    : It runs twice, so the customer is charged twice.

Sphinx : Not quite. The retry finds the saved ID and returns 200
         without charging. But that ID is stored before the charge
         succeeds. If charge() fails, what does the next retry do?

You    : It skips the charge, so the customer is never billed.

Understood. Pushing to origin/main.

The interesting part is that the question aims at boundary conditions, not trivia. What a change does is visible in the diff. The hard part is what happens when it fails — double charges, retry handling, transaction boundaries.

Why it exists: review and understanding are different problems

The question the tool raises is sharp. When AI writes code fast, the bottleneck moves from review to understanding.

[The old premise of code review]
  If a person reads the code, that person understands it
  -> "did they read it" was a proxy for "do they understand it"

[In the AI era]
  The volume of code outpaces what a person can read
  -> "read it" and "understood it" come apart
  -> the proxy stops working

Anthropic's Claude Code team made a similar point and abandoned the question "did a human read the code" altogether (The Claude Code Team's Six Layers of Code Review), moving to automated review and risk-based approval. Sphinx approaches the same problem from another direction: it hands the "understanding gap" — the part automated checks miss — back to a person as a question.

The limits and the pushback

Balance matters here. There are clear reasons not to overrate the tool.

[Technical limits]
1. Local Git hooks are bypassable
   - --no-verify, removing the hook, and so on
   - so it cannot replace security checks or required CI
   - treat it as a habit device, not a gate

2. It never opens .env or keys, but a person still answers
   - the reviewer model can produce false positives or hallucinations
   - question quality depends on the nature of the diff

Counterarguments from the Hacker News thread are practical too.

[Community pushback, summarized]

- A lazy person can paste the question straight into the agent
  -> weak as an enforcement mechanism
- "What does this code do" and "how do you know it is wrong"
  are different questions. A quiz checks the first, not the second
- A quiz tests the person, not the diff. Things you can pass
  a quiz on and still miss live in the diff:
    leftover debug prints, an assertion weakened to match a bug,
    an import of a package that never existed
- so pair it with diff-level checks

One developer's take was more favorable: "I noticed a drop in my understanding of the code I ship, so I built a similar skill. But I keep it optional rather than a forced gate."

The value that remains

Even accounting for the pushback, the tool touches something real.

[What holds up]

1. It surfaces the understanding gap as a question
   - people struggle to ask themselves "do I understand this?"
   - a concrete, scenario-based question from outside forces it

2. It becomes a learning device for new or non-CS developers
   - similar to the old warning against pasting Stack Overflow code
     you did not understand

3. It saves reviewer time
   - a PR that first passes "do you understand it" reviews faster

The observation that understanding is the bottleneck for learning is especially worth keeping. One commenter put it well: "Learning is the bottleneck for shipping code. Building the model in your head, feeling out the edge cases and system interactions. Typing out the code is a small part. If you want to speed things up with LLMs, the bulk of the speed comes from reducing learning."

So the real question Sphinx raises is this: speed gained by reducing understanding — at what cost does it come back?

Conclusion: make understanding a habit, not a gate

The briefing's action, turned into an experiment:

[A mini Sphinx exercise]

1. Start in a test repository
   [ ] npm install -g sphinx-understand
   [ ] run sphinx install, then designate one protected branch

2. Deliberately make hard-to-understand changes
   [ ] double charges, retry handling, timeouts, transaction boundaries
   [ ] see how question depth scales with risk

3. Keep the two kinds of checking separate
   [ ] what Sphinx catches (understanding gaps)
   [ ] what diff-level checks catch (leftover debug, weakened assertions)
   -> they complement, not replace, each other

4. Decide whether it is a team rule or an optional tool
   [ ] if enforced, document that it can be bypassed
   [ ] if optional, frame it as the tool you reach for when unsure

One line captures it.

What runs short in the age of fast AI code
is not review time but understanding.

Sphinx pokes at that gap with a single hook. It is not a perfect gate — which is exactly why it should not be used as one. As a habit of asking yourself about failure conditions before a push, it earns its place. For the Git fundamentals underneath, see Practical Git and Version Control.

Further reading

References

Go deeper with a course

To wire up hooks and understand why they are bypassable, hands-on Git experience is the base. Branch protection, hooks, history and reverting show you why a local hook alone cannot guarantee safety.