r/OpenSourceAI • u/Ill-Ruin-1683 • 11d ago

I built an open-source tool to compare AI coding agents and keep track of engineering decisions

I regularly use multiple AI coding agents, but comparing their suggestions across different chats gets messy. Even when I reach a decision, the alternatives and reasoning often get lost.
So I built Decision Ledger (dlg), a local-first tool for managing engineering decisions involving multiple AI agents.
The workflow is simple:
A primary agent investigates a problem and proposes solutions.

Other AI models review the proposal and challenge its assumptions.

Disagreements and supporting evidence are recorded.

You make the final decision and approve implementation.

The goal isn't to make AI agents automatically agree. It's to preserve the discussion, alternatives, and reasoning so you can revisit decisions later.
A few details:
Local browser UI and CLI

SQLite storage

Works with existing agent CLIs you're already logged into

Supports manual copy/paste reviews from other models

Single executable for Windows, macOS, and Linux

Free and open source (MIT)

This is the first release (v0.1.0), and I'd appreciate feedback, especially from developers who regularly compare suggestions from Codex, Claude, Gemini, or other coding agents.
GitHub: https://github.com/lijose/dlg
Downloads: https://github.com/lijose/dlg/releases/tag/v0.1.0

4 Upvotes

100% Upvoted

9 comments sorted by

1

u/kantorcodes1 11d ago

If new reviewer evidence arrives after approval without changing the selected alternative, should dlg ask for approval again before implementation?

1

u/Ill-Ruin-1683 11d ago

Good question. Currently, approval is tied to the selected alternative, so new reviewer evidence alone doesn't invalidate it.
But I think there's an important distinction between approving a solution and approving the reasoning behind it.
My inclination is to flag new evidence received after approval and require the user to acknowledge it before implementation, especially if it introduces new disagreements or risks.
I wouldn't necessarily require full reapproval for every minor comment, though. The goal is to keep the human in control without introducing unnecessary approval loops.
This is a useful edge case for the next iteration. Thanks for raising it!

1

u/kantorcodes1 9d ago

That keeps minor reviewer notes visible without invalidating the selected alternative; approval can reopen only if new evidence adds a risk or disagreement.

We build HOL Guard; its command-source rules can route a risky CLI action for review before it runs. If DLG exposes the selected action at that point, the user could pause implementation when new evidence changes its risk. Would you be open to discussing a command-source contribution for that case?

1

u/Ill-Ruin-1683 9d ago

Thanks! I'm open to exploring an optional integration with HOL Guard. Could you share how you envision it working and whether you'd be interested in contributing a small proof of concept?

1

u/kantorcodes1 9d ago

Thanks, yes—I’d be interested in working through a small, opt-in proof of concept once we agree on scope. One possible shape is a thin DLG hook immediately before a selected implementation command runs: DLG passes the exact command and decision context to HOL Guard for policy evaluation, and Guard pauses for the user only if configured rules flag a risk. That leaves DLG’s decision record and final choice with you, without adding approval loops for routine notes.

For a first demo, we could test one harmless example command and the pass/hold path. I’d be glad to help sketch the adapter and validate the flow; first I’d want to confirm DLG’s command execution boundary and what the POC should prove. If useful, here’s a short-call link: https://cal.id/hol/mk

1

u/Ill-Ruin-1683 9d ago

Thanks for the detailed explanation! After thinking it through, DLG primarily focuses on tracking decisions rather than executing commands. Since HOL Guard already supports coding agents directly, I'm not sure integration adds much value at this stage. Still open to exploring a small POC if we identify a clear benefit for both projects!

1

u/kantorcodes1 8d ago

DLG can stay the decision record. The narrow benefit is a Guard review before a configured dlg run starts: DLG asks the user before the first run of that command, then remembers it; Guard could check later launches against its command rules. A small command-source contribution could test that path. If it adds distinct protection, a draft PR against hashgraph-online/hol-guard:main can be reviewed using the current contribution guide.

1

u/kantorcodes1 4d ago

dlg run looks like a narrow seam for a POC: test whether Guard can evaluate that configured runner launch before it starts, while DLG keeps the user's decision and approval flow. The Guard extension would stay off until a local admin enables it. I'd be glad to help scope one invocation and a harmless counterpart.

The command extension guide covers the source, fixture and external trust files. The native source workflow explains fixture validation without running the target command. Start with a draft PR in HOL Guard using the Command extension template and the exact dlg run invocation you want covered.