A quiz before you ship tests the one moment that is already over

By the time you push, the thing a quiz would test has already been thrown away. The demand behind the gate is real: teams ship agent-written changes nobody could defend. But a questionnaire at push time asks about decisions the session discarded, and Backthread exists to capture that reasoning per area of the system instead.

The thread

On 18 October a Show HN introduced Sphinx, a hook that interrupts a push with questions about the code being pushed. It reached 242 points and 85 comments. The author's own description of it:

Basically it plugs into your existing coding agent workflow and every time you push to prod it'll throw up a questionnaire that checks if you understand how the code you're pushing works.

That is critiquebrowser, introducing it on 18 October 2026. The idea is not eccentric. It is the obvious response to a condition most engineering leaders now recognise, and the vote count is the condition being acknowledged rather than the fix being endorsed.

The comments are the finding

Under the post, several people who had already built this exact thing turned up.

Lol I built this and immediately got frustrated with it and stopped using it. I think I don't like being questioned by someone who I expect to work like magic.

That is chacha-bong, in the thread on 18 October 2026. Another commenter had shipped a version six months earlier, with anti-cheat work in it, aimed at open-source and enterprise submissions where the incentive to fake an answer is real. His position now:

Seems like we need to more fundamentally rethink the relationship between coding agents and human understanding of the implementation.

That is jeffreysmith, in the same thread. A third had built a quiz into a pull-request view and decided to keep it optional rather than make it a gate, because the volume of changes is already past what a gate can hold.

Our own attempt at this is on the same pile. A periodic question for engineers about areas of the codebase was one of the first things we designed, and five of five outside reads rejected it before we could finish pitching it. Nobody disputed the problem. They objected to being examined about it, on a schedule, by a tool.

The sharpest comment in the thread separates two things that get collapsed:

Maybe the useful distinction is understanding what a PR does versus knowing how to tell if it's wrong. A quiz can check the first, but the second is often where review matters most.

That is alyssassan, on 18 October 2026.

Why the gate is in the wrong place

Three reasons, in the order that matters.

It arrives after the moment it is testing. The alternative that was weighed and the trade-off that was accepted exist while the agent is working. At push they are gone, and for a large share of changes they never formed: on our own repository, of 4,302 decisions captured from agent sessions, 1,613 carry any recorded deliberation, so 62 percent record no alternative and no trade-off. For those changes a quiz has nothing to draw out beyond the diff itself.

It taxes the person who already looked. An engineer who read the output and pushed back on it answers the questions and loses the time. An engineer who did not read it fails, learns which questions get asked, and adapts. One commenter reported colleagues who already instruct their agent to delete the project's pre-commit hooks, and a hook is exactly what this is.

It measures a person when the quantity a leader can act on is an area. A result for one engineer on one push does not tell you where to put the next review hour. Which parts of the system nobody on the team has a working model of does, and that is a property of the map rather than of anyone's test result.

What to do with the demand instead

The ache is correct, so keep it and move the check.

• Put the question next to the change, while the session is still open. The agent that just weighed two approaches can record which it rejected and why, at a cost of seconds. Later, nobody can reconstruct it.
• Ask about the thing that can be wrong, not about what the change does. One assumption the change depends on, and how you would test it. That is the half a quiz misses and the half that catches defects.
• Keep it optional, and aim it by area. Voluntary in the places where the team is thin, absent where three people already work daily, and never as a merge gate whose cheapest response is to disable it.
• Spend the attention you free on the boundaries between changes, which is where agent-written work actually goes wrong, as a five-month experiment with coding agents found when it turned auto-merge off.

The honest caveat is that one of the quiz builders in the thread reports it working for him, on whole pull requests rather than single commits, and he is not wrong about what it gave him. A voluntary instrument used by the person who wanted it is a different object from a gate imposed on a team. Nearly every attempt to make it the second thing, ours included, has been abandoned by the people who built it. If you are deciding where the human hours go rather than how many of them there are, what Backthread keeps about each area of a system is aimed at that question.

Connect one repo and the reasoning behind each merged change starts accumulating against the part of the system it touched; the trial runs fourteen days.