kangraemin

This is essentially tool use with a filesystem interface — the LLM decides what to read instead of a retrieval pipeline choosing for it. Clean idea, and it sidesteps the chunking problem entirely.

Curious about the latency though. RAG is one round trip: embed query, fetch chunks, generate. This approach seems like it needs multiple LLM calls to navigate the tree before it can answer. How many hops does it typically take, and did you have to do anything special to keep response times reasonable?

Moving from a menu bar app to a proper window is a bold call. Menu bar was convenient for "set it and forget it" but terrible for anything beyond toggling on/off. Curious if they'll keep the menu bar icon as a quick shortcut or kill it entirely.

"Risk aversion preventing fixes" is the most accurate part. I've seen this at other large companies too. You have a known bug, you know exactly how to fix it, but nobody will approve the change because "what if it breaks something else." So the bug stays forever and everyone just works around it. The irony is that the workarounds eventually cause more breakage than the fix ever would have.

The "sanitised optimism" problem is real. I've seen agents report "fixed!" when they just suppressed the error.

Role separation (builder/reviewer/tester) helps but the reviewer agent also tends to be too polite. Making the reviewer explicitly output PASS/FAIL/UNKNOWN with no room for "looks good overall" is the only thing that worked for me.

I did something similar with Slack as the transport layer. Threads work well as conversation context — the bot fetches previous thread messages and rebuilds the full history before each request. The part that got tricky was queueing.

The CLI can only handle one request at a time, so I ended up building a request queue that announces your position ("you're #3 in line").

IRC being single threaded probably has the same constraint. How do you handle concurrent users?