Show HN: Diffle, a keyboard-centric diff viewer with LSP support
github.com
github.com
- implementation should be harness-agnostic and not rely on a claude code feature that codex, pi, or others don’t implement
- polling sounds token inefficient, maybe there’s a better mechanism?
- it should be minimally invasive and work well with running multiple diffle instances at once (we were weighing raw endpoints the agent can curl or a socket/file, mcp seems a bit much given users might be running different instances on multiple ports)
Feel free to open an issue or a small pr to discuss the design :)
I currently use a combination of a self-written git browser (in the command line, relying mostly on fzf) that allows me to easily navigate files and diffs across worktree, staged changes and earlier commits. When looking at the code isn't enough, I reach for vim with fugitive and lsp for inspection and poking at the code.
The key bindings seems very vim-inspired, so I should feel at home with it.
I don't see how I could keep up with the volume of code my team now produces without this. How do other people do it?
That way, you get the opportunity to measure how many and what kind of issues your harness method misses, and with an estimation of their cost, you can make an informed decision about what magnitude speedup pays for the change in detection rate.
This, although vibe-coded, seems like good inspiration for a general concept that might work. Now if only I could take the time to make some Emacs commands that integrate this functionality with Magit and Ediff...
I’m wondering, is there anything about the interface or UX that “feels” vibe-coded to you? While it’s true that we’re relying heavily on agents to build this (i’m not a full stack person), we put a lot of effort into getting the details right. I personally also hate sloppy interfaces that all look alike and have weird paper cuts that agents don’t spot.
The documentation and website are both obviously not written by a human.[1] This doesn't speak to me, in part because I'm the sort of person who thinks those are the interface and UX; but also because I reflexively end up thinking, "If they can't explain to me how it works, then why should I believe they even know how it works?"
I'm not saying you aren't intimate with every little detail, but writing the descriptions yourself is a costly signal and thus valuable for me as a potential user.
[1]: https://xkqr.org/aicomment/#lang=c&prior=50&c=PZIxjtwwDEX7Pc...