iamalizaidi

decispher is live at https://decispher.com

Agreed, and the same logic applies one level up. Don't paste the error, and also don't make it re-derive the architecture. The highest leverage input is the stuff that never appears in the repo: what you tried before and why you rejected it. Which you can easily do with Decispher (https://decispher.com)

We are building in this space only, our product is called decispher

You're not. Most of the pain you're describing is the model not knowing anything your team knows. It doesn't know you already tried that approach in March and it broke billing. Until you feed it that history it will keep confidently repeating your old mistakes at higher speed.

Hello, I'm the builder of Decispher. It captures the reasoning behind your team's decisions and serves it both ways: to your engineers, and to your AI agents before they write code.

One feature i would like to talk about: Branch Story (VS Code extension + npm). It captures the reasoning, diffs, and terminal output as work happens, then surfaces it at PR review time, so a reviewer knows why the code is the way it is instead of just reading a diff and hoping it's fine.

There's also "why is this line here": right-click any line in the editor, get the decision behind it.

*Branch Story captures your agent's context and reasoning, along with diffs and terminal output. It works as a VS Code extension (or any VS Code fork) and as an npm package.

Seems purely vibecoded

Love the scorecard + guard loop idea — especially tracking retries/cost spikes as a signal. That's a meaningful feedback layer. Right now Decision Guardian is intentionally stateless: when a guard trips, it fails the check and surfaces the full decision context in the PR comment. Resolution is human — override or update the ADR. The gap you're implicitly pointing at is real though: we don't log why a guard was bypassed or whether the ADR got updated after. That memory just dies in the PR thread. Curious — is the {status:'ok'} evaluation happening in the runner itself or hitting a live service? Wondering if ADR drift just moves one layer up into the guard logic over time.

This is really cool, had no idea someone had solved a similar problem this way. The checksum idea is genius!!

Thank you for the feedback

Really appreciate that — that’s exactly the gap I was trying to address.

Re: noise — I agree, that’s the main failure mode for any PR bot.

A few things I did to keep signal high:

Only trigger on explicit file patterns (no fuzzy matching by default)

Idempotent comments — it updates instead of spamming new ones

If multiple decisions match, it groups them into a single comment

Severity levels (info / warning / critical) so teams can tune strictness

Optional “fail critical” mode so it never blocks PRs unless configured

The goal is that it behaves more like a linter than a chatbot — predictable and quiet unless something clearly matches.

If it ever becomes background noise, it’s failed

Thanks for the pushback — genuinely fair.

This is still just markdown in the repo. The Action doesn’t replace ADRs, it just surfaces the relevant ones automatically in PRs so reviewers don’t have to remember to look for them.

In teams where people consistently check ADRs, this probably isn’t useful.

In teams where the ADR exists but nobody remembers it during review, this helps reduce that friction.

And yeah — the Mongo example was dramatized. The real version was just re-explaining a past decision in a design doc. Not catastrophic, just wasted cycles.

Appreciate the sanity check.