We built a debugging tool that refuses to guess
Most AI tools, when they're unsure, guess — confidently.
That's how you burn an hour chasing the wrong bug.
We went the other way. Point ours at your repo and say what's breaking — "customers are getting charged twice." Instead of guessing which API, it reads your code:
Sees you have both Stripe and Paddle installed.
Reads both webhook handlers — your Paddle one has no idempotency check (line 16); Stripe dedupes fine.
Tells you: "it's your Paddle handler." A fact from your code, not a hunch.
And when the code genuinely can't tell them apart, it does the thing most AI tools won't: it asks you — instead of confidently marching you down the wrong path.
In a year of tools that hallucinate with total confidence, we're betting on the opposite: know when you don't know.
Quietly wiring this in now. Full reveal Aug 2. 👀
Replies
FetchSandbox
honestly the "refuses to guess" part came from getting burned by my own tools. i'd describe a bug, the agent would confidently open the wrong file, and i'd lose an hour before realizing it just guessed.
so we made ours read the actual code first. if you've got stripe and paddle both wired up and one handler is missing an idempotency check — it points at that one, not a coin flip.
genuinely torn on one thing though: when an AI tool isn't sure, do you want it to just pick something and keep moving, or stop and ask you? i keep going back and forth.
more Aug 2 👀
Stop and ask, but only when the answer changes what you do next. The version that annoys people is not that it asked, it is that it asked about something it could have worked out on its own, or about something that did not matter. So the test I use is simple: if both branches lead to the same next step, pick one and keep going. If they lead somewhere different and you would have to undo the wrong one, ask. Two things made asking feel like progress rather than nagging. Say what you already ruled out, so the question reads as work done rather than helplessness. And make the ask concrete, "Stripe or Paddle" rather than "can you clarify". Your webhook example is exactly the shape where asking earns its keep. Looking forward to Aug 2.
FetchSandbox
@cmumulle You hve put it better than what i have: "ask only when undoing the wrong branch would cost you." That's the test.
And your two conditions turned out to be one mechanism for us ... before it asks anything, it reads the repo and the handlers, so the question already carries the work..
"your Stripe dedupe is fine, the Paddle handler has no idempotency check is the double-charge on Paddle?"
what I ruled out isn't politeness; it's exactly what lets the ask be "Stripe or Paddle" instead of "can you clarify."
And when the code genuinely can't tell them apart, it caps how much it'll ask and never assumes past that.
thanks for the comment this sharp ... this is the conversation we hoped Aug 2 would start.
@rnagulapalle The cap is the part I would want to get right, because it is where the honesty can quietly turn back into a guess. Once you hit the limit and still cannot separate Stripe from Paddle, what does it hand back? The two shapes I have used behave very differently in practice. Return both candidates ranked with the evidence for each and let the person choose, or stop and say plainly that the code does not decide it. Ranked-with-evidence is friendlier, but it reintroduces the confident-wrong failure you set out to avoid, because people read the top of a ranked list as the answer. Saying "the code does not decide this" is colder and safer, and it also tells you something true about the repo. Curious which way you went, and whether the cap is a count of questions or a confidence floor.
FetchSandbox
@cmumulle you landed on the exact tension we sat with. ranked-with-evidence feels like honesty because it shows the work, but it isn't, you're right that people read rank 1 as the answer, which just moves the guess one layer down and wraps it in a citation. so we took the colder path: when both handlers produce the same failure signature under the same scenario, the receipt says the code does not decide this. no winner, no ordering.
the cap is inconclusive scenarios run, not questions asked. that distinction matters to us, "questions asked" implies there's a longer investigation we chose to cut short. "inconclusive scenarios" says the tests genuinely could not build a case that separated the behaviors. that's a true statement about the repo, which is what you said and is exactly what the receipt should surface.
the coldness is the point. a confident wrong answer costs more than no answer.