<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: 0907</title><link>https://news.ycombinator.com/user?id=0907</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sat, 30 May 2026 19:10:23 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=0907" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by 0907 in "MCP Is Dead"]]></title><description><![CDATA[
<p>hadn't heard of runlayer, but it does make sense. I'm a huge advocate of skills based on the company/process or project owners perspectives and workflow habits rather than using skills.sh or similar. You will end up cosplaying as someone elses perspective and wonder why you don't understand it..</p>
]]></description><pubDate>Fri, 29 May 2026 23:51:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=48330856</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=48330856</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48330856</guid></item><item><title><![CDATA[New comment by 0907 in "MCP is dead?"]]></title><description><![CDATA[
<p>Yes and no -- you can give internal agents access to internal APIs by using rudimentary env var, and org level agentic services tend to offer that kind of permission based access (either roll your own, use an 'enterprise' service, or be knowledgeable that if things go wrong, they'll go very wrong). APIs should, at least from my perspective, always have permission mechanisms. But internal APIs, used by 'internal' agents, have access to those the same way users on the network do, just depends on what flavour of network one is using.<p>Essentially it's anything that _could_ be on a dashboard, but _might_ be accessed conversationally via an agent.</p>
]]></description><pubDate>Fri, 29 May 2026 23:48:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=48330829</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=48330829</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48330829</guid></item><item><title><![CDATA[New comment by 0907 in "MCP is dead?"]]></title><description><![CDATA[
<p>Yes, exactly that one! thanks</p>
]]></description><pubDate>Fri, 29 May 2026 23:43:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=48330800</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=48330800</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48330800</guid></item><item><title><![CDATA[New comment by 0907 in "Machine First: Why AEO Is Not SEO 2.0"]]></title><description><![CDATA[
<p>Those who succeeded at SEO are the same who will (and arguably, are) succeeding at AEO/GEO/AIO or whatever we want to call it. And more over, AEO has been gamed with false pretence of authority by hijacking influence via 'prestigious' channels - demonstrated with false attribution, press releases, reddit astroturfing or numerous other vectors. These are arguably the same techniques of early SEO, moral or not, by showing up and acting up in places one assumes authority comes from.</p>
]]></description><pubDate>Fri, 29 May 2026 23:41:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=48330787</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=48330787</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48330787</guid></item><item><title><![CDATA[New comment by 0907 in "MCP is dead?"]]></title><description><![CDATA[
<p>I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...</p>
]]></description><pubDate>Fri, 29 May 2026 23:11:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=48330571</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=48330571</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48330571</guid></item><item><title><![CDATA[New comment by 0907 in "Bitmap fonts make computers feel like computers again"]]></title><description><![CDATA[
<p>I've dabbled a few times in writing bitmap font parsers for both technically constrained and artistic projects. There is a reason that design has resolved to the same few cliches, because expectability, latent understanding, and 'obviousness' reduces onboarding curve and fatigue. It's a cognitive accessibility issue before you even get to legitimate accessibility concerns. Render a .F16 at anything larger than 16px in a modern application and you're introducing issues which are solved, quantitatively and qualitatively, by vector graphics and antialiasing. There's an optimistic naivety which is nice to have, but misunderstands design as a conduit for informed action vs design as an aesthetic function independent of intent is legitimately dangerous if you're doing anything other than building narrative products emulating older tech.</p>
]]></description><pubDate>Thu, 09 Apr 2026 20:31:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=47709516</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=47709516</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47709516</guid></item><item><title><![CDATA[New comment by 0907 in "Show HN: Hackerbrief – Top posts on Hacker News summarized daily"]]></title><description><![CDATA[
<p>Something I've been tinkering on for the last few weeks is absent.dev[1], was working towards getting the guts to share this on HN but there's a few things I want to polish first. This is the MVP, but it will essentially be moving towards what you're suggesting, much more customisable news aggregation and more importantly, where <i>you</i> consume it. Feed agnostic, channel agnostic, in the form(s) you want (longform, shortform, summary, tl;dr etc). You can check the clustering logic on the digest[2].<p>1. <a href="https://absent.dev/" rel="nofollow">https://absent.dev/</a>
2. <a href="https://absent.dev/episode/ABS-0014/clusters" rel="nofollow">https://absent.dev/episode/ABS-0014/clusters</a></p>
]]></description><pubDate>Mon, 16 Mar 2026 14:00:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=47399158</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=47399158</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47399158</guid></item><item><title><![CDATA[New comment by 0907 in "Components will kill pages"]]></title><description><![CDATA[
<p>I think that the inverse thesis is true, you make websites more accessible (a11y, wgac, aria labels etc) for humans, then the interaction heuristics are clearer for agents functioning off browser-use or similar. If a screen reader can understand your site, then an agent can. Reinventing the wheel to facilitate the current state of agents makes the web worse for everyone, it's not a preemptive move, it's actually a decline in almost objective and measurable quality, and potentially one which removes access to the internet by people who just want to.. use the internet.</p>
]]></description><pubDate>Thu, 12 Feb 2026 00:13:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=46983120</link><dc:creator>0907</dc:creator><comments>https://news.ycombinator.com/item?id=46983120</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46983120</guid></item></channel></rss>