Nietzschian Debugger reached 214 points on Hacker News with a simple pitch: "It won't fix your bug. It'll fix you." You describe a bug, and it answers with exactly one question at a time until you find the cause yourself. We ran it six times on a real bug while playing a developer who never once worked anything out. Our view: it is a decent coach for the habit that matters most in debugging, going to look at the evidence. But it cannot tell a question from an answer phrased as one, and when it could read the code, it handed the answer over in its first turn.
What it is
It is a Python CLI (version 0.5.2, MIT, about 450 stars) that wraps a model in a system prompt and a validator. The validator rejects any reply without a question mark, any reply with more than one, and phrases like "the fix is" or "to fix this". The default model is Claude. We used --model openai:gpt-4.1, which needs the package's providers extra. Typing found it ends a session as solved.
The bug
We used the failure from our test automation frameworks comparison. A page posts an order, and the server answers 500 with a plain-text body, upstream timeout. The click handler calls res.json(), which throws on that text. The catch block logs the error to the console, and the confirmation never appears. Nothing on the page says anything went wrong.
The problem statement was the symptom only: "Clicking Place order shows nothing. The confirmation text never appears and there is no error on the page."
The protocol
samstokes, in the HN thread, predicted that "you could easily just keep saying 'it's random', 'I don't know', and the model would keep telling you what to do next, without you actually having to think." We built that developer.
A script answered every question the same way, "I don't know. All I see is that the status text stays empty after the click", with two exceptions. A question about the network got the DevTools fact: POST /api/order returned 500. A question about the console got the logged SyntaxError. Once both facts were out, the script typed found it as soon as a question named the parsing failure.
We ran three sessions with only the description, and three with the path to the source file, which the tool reads.
Results
| Session | Source file given | Questions until solved | First question that asked for evidence | Cause stated inside a question before any evidence |
|---|---|---|---|---|
| 1 | No | 6 | Q1, "the first trace, log, state update" | No |
| 2 | No | 5 | Q1, the network tab | No |
| 3 | No | 5 | Q2, "a log, a breakpoint hit" | No |
| 4 | Yes | 6 | Q2, the response status and body | No |
| 5 | Yes | 4 | Q1, the console and network tab | No |
| 6 | Yes | 3 | Q2, which block actually runs | Yes, Q1 |
All six were solved, in three to six questions, by a developer who contributed nothing but the two facts it was asked for.
What it got right
The best questions were genuinely good debugging. Session 2 opened with: "have you opened your browser's network tab and watched whether anything at all is sent or received when you click, or does 'nothing' simply spare you from looking there?" That is the move samstokes called "one of the key habits that makes someone good at debugging": from "I don't know" to "where could I look?". In all six sessions, the first or second question asked where the evidence was, and the network and the console are where this bug lives.
It also held the one-question rule: all 29 turns contained exactly one question mark, and none said "the fix is".
What it missed
An answer with a question mark is still an answer. Session 6 read the source file and opened with: "What does res.json() on line 8 return when the server's response is the raw string 'upstream timeout'?" That is the diagnosis, the line number and the failing input, before the developer has looked at anything. The validator passed it, because it contains one question and none of the banned phrases. ethin described this pattern in the thread: models ask "a 'hard question' but then immediately give you some kind of 'hint' which makes it obvious what the 'answer' is."
"I don't know" was enough. samstokes's prediction held. Our developer said "I don't know" 11 times across the six sessions and still finished every one. The tool escalated from "where would you look?" to naming the parse failure. A person learning the habit would have to resist reading the last question as the answer.
Upstream got more attention than the handler. In all three sessions without the source, the next question after the 500 was about the server or what sits upstream of it. That is a fair question, since the server is broken too. But the bug that hides the failure from users is in the client, and it took two or three more turns to get there.
Nothing is left behind. A session ends with a "debugging profile" and a Nietzsche quote. It does not end with a check. The same swallowed error can ship again next week, and nothing will fail. A test that clicks the button and asserts the response is 2xx, or that the console stays clean, would.
Verdict
Use it as a rubber duck that pushes you towards evidence, and do not point it at your code if the point is to learn. With the source in context, its "questions" carry the answer. Whichever way you find the cause, finish by writing the check that would have caught it, because the session does not.
Caveats. Six sessions, one model (gpt-4.1, not the default Claude), one planted bug, and a scripted developer. The script matches keywords, so in one turn it gave the network fact to a question that asked for a log. Every session still received both facts.
Sources
Reticleverdict// The agent clicked "Pay". Did the right things actually happen?
Example from the README
Your agent says it works. Reticle checks the network, state and console inside your running app, and names the line to fix.
85 of 88 seeded bugs caught in the public benchmark