<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: kangraemin</title><link>https://news.ycombinator.com/user?id=kangraemin</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 06 Apr 2026 04:39:19 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=kangraemin" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by kangraemin in "Jack Dorsey says Block employees now bring prototypes, not slides, to meetings"]]></title><description><![CDATA[
<p>The "prototypes not slides" rule works great for product decisions where the devil is in the interaction details. You can't really argue about a flow in a slide deck — once someone clicks through a prototype, the discussion shifts from opinion to observation.<p>But I wonder how they handle discussions that are inherently abstract — pricing changes, infrastructure migration plans, org restructuring. Forcing a prototype there would just produce theater. The real insight is probably not "prototypes good, slides bad" but "stop presenting things that should be experienced.</p>
]]></description><pubDate>Sat, 04 Apr 2026 14:03:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=47639167</link><dc:creator>kangraemin</dc:creator><comments>https://news.ycombinator.com/item?id=47639167</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47639167</guid></item><item><title><![CDATA[New comment by kangraemin in "We replaced RAG with a virtual filesystem for our AI documentation assistant"]]></title><description><![CDATA[
<p>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.<p>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?</p>
]]></description><pubDate>Sat, 04 Apr 2026 13:07:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=47638751</link><dc:creator>kangraemin</dc:creator><comments>https://news.ycombinator.com/item?id=47638751</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47638751</guid></item><item><title><![CDATA[New comment by kangraemin in "Tailscale's new macOS home"]]></title><description><![CDATA[
<p>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.</p>
]]></description><pubDate>Fri, 03 Apr 2026 14:24:59 +0000</pubDate><link>https://news.ycombinator.com/item?id=47627007</link><dc:creator>kangraemin</dc:creator><comments>https://news.ycombinator.com/item?id=47627007</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47627007</guid></item><item><title><![CDATA[New comment by kangraemin in "Decisions that eroded trust in Azure – by a former Azure Core engineer"]]></title><description><![CDATA[
<p>"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.</p>
]]></description><pubDate>Fri, 03 Apr 2026 13:26:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=47626441</link><dc:creator>kangraemin</dc:creator><comments>https://news.ycombinator.com/item?id=47626441</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47626441</guid></item><item><title><![CDATA[New comment by kangraemin in "Show HN: Real-time dashboard for Claude Code agent teams"]]></title><description><![CDATA[
<p>The "sanitised optimism" problem is real. I've seen agents report "fixed!" when they just suppressed the error.<p>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.</p>
]]></description><pubDate>Fri, 03 Apr 2026 13:17:58 +0000</pubDate><link>https://news.ycombinator.com/item?id=47626366</link><dc:creator>kangraemin</dc:creator><comments>https://news.ycombinator.com/item?id=47626366</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47626366</guid></item><item><title><![CDATA[New comment by kangraemin in "Show HN: I put an AI agent on a $7/month VPS with IRC as its transport layer"]]></title><description><![CDATA[
<p>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.<p>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").<p>IRC being single threaded probably has the same constraint. How do you handle concurrent users?</p>
]]></description><pubDate>Mon, 30 Mar 2026 13:40:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=47574192</link><dc:creator>kangraemin</dc:creator><comments>https://news.ycombinator.com/item?id=47574192</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47574192</guid></item></channel></rss>