<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: toonvanvr</title><link>https://news.ycombinator.com/user?id=toonvanvr</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 22 Jul 2026 03:56:56 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=toonvanvr" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by toonvanvr in "Claude Is Not a Compiler"]]></title><description><![CDATA[
<p>It's funny how you describe something very close to what I was attempting to design. It was meant to trickle down from tickets to deterministic code. Data wise, it should be like a pyramid of tickets diluting layer by layer into leaf nodes which were "implementable" as statements in code. I'm not sure if that description makes sense read by someone else.<p>I think what made sense was envisioning a nanoswarm of LLMs (anticipating ASIC performance) diluting specs into semantic logic nodes, but a conversion from these to deterministic code made the vibe coded experiment come to halt. Your lock approach could be a shortcut to that.<p>Totally off-topic: it's quite intriguing that you can feel once friction starts building during a design phase. Suddenly everything slows down. I wonder if it's quantifiable and therefore can identify "wrong" design choices made by either humans or LLMs.<p>(Hoping some claw bot pics this up to finish my idea on my github tix repo in the initial-design branch, as main is empty ~ MPL2)</p>
]]></description><pubDate>Tue, 21 Jul 2026 16:34:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=48994636</link><dc:creator>toonvanvr</dc:creator><comments>https://news.ycombinator.com/item?id=48994636</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48994636</guid></item></channel></rss>