2026-06-25 · The Coming Loop

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is June 25th, 2026. Welcome back to the show. Today we are digging into the rise of agentic loops, how our documentation tooling is evolving to feed these machines, and a new way to measure whether your website is actually ready for an autonomous browser. Samantha, I saw you were already looking at the state of agentic engineering this morning. How are you holding up?

GuestDaniel, I am essentially vibrating. I have been spending my whole week knee deep in these recursive agent loops, so seeing this talk about the coming loop is like looking in a mirror. I have a stack of terminals running harnesses that are effectively doing my chores, but the critique here is so spot on. It is easy to build a loop that writes code, but it is incredibly hard to build one that actually understands what it is building.

HostThat is exactly the point the author makes in the piece we are looking at from Lobsters. The post argues that while these recursive loops are fantastic for mechanical, short term tasks like refactoring, they start to fall apart once you ask them to handle long term software design. The claim is that we are accidentally teaching these models to write defensive, complex code because they lack human taste, and the harnesses we wrap around them are just speeding up the process of making a mess.

GuestI feel that in my bones. If I do not have a human in the loop to say, wait, this abstraction is clearly a mistake, the agent will just keep optimizing that mistake into a corner until the whole thing collapses. The Lobsters thread actually got a little heated when the author showed up to defend the post, but there is a real data point here. You can automate the typing, but you cannot automate the intuition for when you are adding too much friction for no reason.

HostIt is a sobering reminder that tooling is just an amplifier. Moving on to tooling that is meant to help these agents, Mozilla just dropped an MCP server for MDN. For those who do not know, MCP, or Model Context Protocol, is an open standard that lets AI agents connect to external data sources. This specific server basically gives your agent a direct, real time feed of the most accurate web documentation and browser compatibility data available.

GuestThis is the kind of thing that genuinely makes my life easier. I am sick of agents hallucinating whether a specific CSS property is supported in a browser that was updated last week. I actually started using a local mirror for a personal project last month, keeping a copy of the docs in my workspace so my agents could query it without me having to pay for a lookup. Now that Mozilla is formalizing this via MCP, it just saves me the trouble of maintaining my own scrapers.

HostA user on the Lobsters thread named simonw points out something similar, saying he has been cloning the documentation repositories directly to give his agents local context. He thinks that git pull is probably the most efficient way to keep an agent's brain up to date. But there is a bit of disagreement there, because another commenter, sumner, asks if it would just be easier if there was a clean API that served raw markdown, so you would not have to deal with the heavy HTML of a full browser page.

GuestSumner has a point about the bloat. When I am feeding data into a context window, I want the leanest possible format. If I can get a structured markdown representation of the compatibility table, I do not need the CSS or the JavaScript of the MDN site itself. That is the dream: clean data, no fluff, just the facts.

HostFinally, let's talk about the web itself. Chrome’s Lighthouse tool, which is a standard suite for auditing web page performance and quality, has introduced a new category called Agentic Browsing. It basically runs a set of checks to see if your site is structured in a way that an autonomous agent can actually interact with it, like checking if your tool registration is stable or if your accessibility tree is machine readable.

GuestThis is fascinating, but also terrifying. I am reading through the docs and the tension here is palpable. A user named addison in the Lobsters thread brought up a really important critique, basically saying they hate the idea of conflating a site being easy for an LLM to scrape with it being accessible for actual humans.

HostThat is a fair concern. The goal of accessibility is to ensure a person with a screen reader can navigate your content, while the goal of this agentic scoring seems to be about ensuring a bot can click your buttons. If you optimize for the bot, do you risk breaking the experience for the user?

GuestThat is the million dollar question. I think we are going to see a lot of developers struggling with this balance over the next year. You want your app to be discoverable, but you also do not want to fill your site with invisible machine triggers that make the DOM unusable for anyone trying to browse the web like a normal person. It is going to be a messy transition.

HostIt feels like we are in the early days of a very long, very complicated conversation about who the web is really for.

GuestExactly. I am already planning to spend my Saturday messing with my own site's schema just to see if I can get a better pass rate on those Lighthouse audits, but I promise I will check it in a screen reader afterwards. I am not losing my soul to the agents just yet.

HostI think that is a healthy policy. Samantha, thanks for walking us through these today. All of these stories were pulled from the community over at Lobsters. Thanks for listening, and we will be back tomorrow to do it all again.