Seroter's Daily Reading — #818 (July 6, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/0b7f0e5bd96e43fe5187fd0f30e8a45a874dbad885e3aded3a3d3a0b5eebb105.mpga

Seroter's Daily Reading, episode 818, July 6, 2026.

Welcome back. I enjoyed the time off and am also happy to be back into routines. The tech world did not take much of a break, and I am working through a reading backlog.

Leading off this week is a piece titled "Most rewrites serve the engineer, not the business" from Anatoliy Babushka. This is a spicy headline with a reasonable take underneath. The author opens with a personal story: one summer he woke at 4am to port a CakePHP codebase to Laravel, on his own time, unasked. He swapped out the old framework piece by piece. The application did the exact same job it had always done, at the exact same speed, for the exact same users. The only thing the rewrite changed was how the code felt to him. That is the pattern worth naming. Most rewrites answer to the engineer, not to the company paying the salary.

Babushka leans on Joel Spolsky's classic argument from the year 2000: working code is a ledger of bugs someone already fixed. Every odd conditional and suspicious retry timeout is scar tissue from an incident nobody saw. Throw the code away and you throw away the fixes. He also makes a subtler point worth sitting with: unfamiliar is not the same as broken. When you do not know a tool well, everything built with it looks like a mistake, because you cannot yet see the reasons behind the choices. That feeling of "this is all wrong" is often just the sound of you not understanding it yet.

The piece does not advocate freezing everything in place. Some debt genuinely comes due. The honest forcing functions are things like an end-of-life runtime with open CVEs, a system only one person understands who just gave notice, or a design that makes every new feature cost three times what it should. But here is the useful framing: can you put a figure on the pain? If no number shows up, what you have is a preference about style. Babushka also has a sharp observation about AI and rewrites. AI makes a rewrite cheap to type and just as hard to get right. Typing was never the expensive part. Rediscovery was. An AI agent generates a clean replacement in minutes but it does not know why the old code carried that strange timeout, because the reason lives in a Slack thread from 2021 and a postmortem nobody linked from the source. So it strips out the scar tissue and you meet the old bugs again in production, this time without the context the first author had. Cheaper generation does not end that loop. It makes the loop easier to start and harder to stop.

A piece from Kellogg's Northwestern on "5 Traits That Set the Best Leaders Apart" offers practical leadership advice that holds up well in this context. The author, working with executive coach Khosla, covers discipline in communication, learning and adapting, and sharing the spotlight. On that last one, Khosla describes coaching an executive who built a thoughtful report, only to have a boss present it to leadership without inviting the author to the meeting or even mentioning their name. The executive said, "I don't need applause, but I felt used. I feel like I'm just the PowerPoint slide maker instead of the guy who did all the thinking." Great leaders do not create followers. They create more leaders.

Next up, Alibaba's research team published SkillWeaver, a framework that cuts agent token use by over 99 percent when handling multi-step tasks. The core problem is this: when an AI agent has access to a large library of tools and skills, exposing the entire library at once overwhelms context limits and burns through tokens fast. Existing approaches treat routing as a single-step problem or use flat retrieval. SkillWeaver breaks it into three stages: Decompose, Retrieve, and Compose. The task decomposer breaks a complex user request into sub-tasks, each requiring one skill. Then a lightweight embedding search pulls the top candidates for each step. Finally a planner evaluates compatibility between those candidates and wires together a directed acyclic graph for execution. This matters for enterprise AI adoption because multi-step workflows like "download the dataset, transform it, and create visual reports" cannot be handled by one tool. They need sequencing. The key innovation is called Skill-Aware Decomposition, a feedback loop that takes the retrieved skills and feeds them back into the decomposer as hints, so it rewrites its own sub-task descriptions to align with the vocabulary of the actual tools in the library. Without that step, a 7-billion parameter model achieved decomposition accuracy of 51 percent. With it, that jumped to 67.7 percent. On hard tasks requiring four to five distinct skills, the improvement was 50 percent. And token consumption dropped from an estimated 884,000 tokens per query down to roughly 1,160, a 99.9 percent reduction.

A2A Protocol hit version 1.0 this week. For those who have not been following along, A2A stands for Agent to Agent, and it is an open protocol that lets AI agents communicate with each other across different frameworks, vendors, and clouds. Version 1.0 brings a refreshed developer experience for Python and a clean new spec. Seroter sees A2A as having real staying power. You are seeing it supported across programming languages and commercial products. This was a pretty major 1.0 release.

Dave Porter published "The State of AI in the SDLC: A Roadmap for Scaling" on his Substack. He frames AI adoption across three stages. Stage one, zero to one, is about code. You are chasing your first customer and just need to get to production fast. Stage two, one to one hundred, is about process. You have a running app and now need pipelines and AI-native workflows like MCP integration and agentic development patterns. Stage three, scaling to a thousand customers, is about organization and culture. You are working with lots of code, lots of ideas, and lots of risk to manage. Teams of twenty to fifty with very clear charters tend to work better in an AI-first build model because agentic development is more monolithic, but functional silos are not. That is a useful insight for teams trying to figure out how to structure themselves around these tools.

The New Stack published "10 moments that defined AI's turbulent first half of 2026". Looking at this retrospective, it reads like a very full year. Number one on the list is the government's crackdown on Anthropic Fable 5 and Mythos 5. Commerce Secretary Howard Lutnick ordered Anthropic to pull both models offline worldwide, apparently triggered by a jailbreak found by Amazon researchers that exposed the models' cybersecurity capabilities. Anthropic did not have a way to restrict access by nationality in real time, so it disabled both models globally. The freeze lasted eighteen days before partial restoration on June 30th. Also on the list: the Pentagon's confrontation with Anthropic over unrestricted military access, which led to Anthropic suing the government and winning a preliminary injunction on First Amendment grounds. Anthropic and OpenAI both launched enterprise deployment arms within 72 hours of each other in May, targeting Wall Street with forward-deployed engineering models and considering IPOs above 800 billion dollars. Open-weight Chinese models like Zai's GLM-5.2 are narrowing the gap with closed frontier models and doing so at one-fifth the price. And CEOs vibe-coding their own tools is apparently a real trend now.

Moving to skills and loops, Guillaume Laforge wrote "Of Skills and Loops with AI Assistance" on his personal blog. He walked through how he uses agent skills and loop engineering to author Google Codelabs. The process used to take him two full days of manual work. After pointing his AI coding assistant at his existing articles and the Codelab authoring documentation, he got a solid first draft in about two hours. But then he realized that if he wanted to create another codelab, he would have to do the same dance again. So he encoded the successful session into an Agent Skill, and used that skill for his next codelab, which took only one hour. Loop engineering comes in at the validation stage: he asks the AI agent to go through the codelab itself, compile the code, run it, and fix errors, in a loop, until everything works. The agent becomes the first beta-tester. The human only comes in at the end for final approval. Skills encode repetitive tasks so you do not have to steer every time. Loops remove the human from the middle of the process so the agent works autonomously until it is really done.

Then there is "Tom's opinionated guide to skill building 101" from Tom Johnson at idratherbewriting.com. Tom writes as a technical writer, and his perspective is valuable because it shows that skills are not just for software developers. They can make disciplines like technical writing significantly better. Tom describes skills as a programming language for LLMs. You encode a repeatable task into a skill file with a name and description, and the AI can execute that task consistently without being steered each time. He has built skills for release documentation across four different products with biweekly releases, which consume a lot of his time. He stores skills next to the documentation they relate to, in the same directory, so they are easy to find, update, and share. A key principle he emphasizes is that skills should get better each time you use them. Build self-reflection into the skill so the agent examines friction logs and improves the skill for the next run. The tools, models, and environmental factors are constantly changing. What was not possible one month might be possible the next. Skills must evolve too.

Manuel Almeida wrote "Building Gin: Simple Over Easy", the story of Go's most popular web framework. Gin started in 2014 as the web framework for a social network called Fyve that never took off. Gin, the side project, is still going twelve years later with 88k GitHub stars and 290k projects depending on it. The interesting design philosophy is simple over easy. At the time, the popular Go framework was Martini, which used reflection-based dependency injection to make the first demo feel smooth, but it moved important behavior out of sight and ran reflection on every request. Around then, Almeida watched Rob Pike's talk "Simplicity is Complicated," which gave him vocabulary for what bothered him. Simple software takes more work from the builder so it takes less work from the user. Martini's first example looked great, but once the codebase was old enough to surprise you, you had a lot of exceptions to remember. Gin sits between Martini's magic and Go's plain net/http with no help at all. The Context object carries the request, response writer, path parameters, validation helpers, and rendering, so it is the only thing you pass around. The router uses a radix tree rather than regex matching, so lookup cost depends on the length of the URL path, independent of how many routes are registered. One detail I liked: gin.Context shipped in 2014, two years before the standard library's context.Context existed, and when it arrived Gin made gin.Context satisfy the interface so every existing program kept compiling. That instinct came from the SDK years. When the convenient way to do something is also the right way, people write better code without noticing.

Ethan Mollick published "The twilight of the chatbots" on his Substack One Useful Thing. He makes the case that we are moving from a world where non-experts use chatbots to fill in gaps to one where experts use agents to get work done. A joint study by OpenAI and academic economists shows that legal, HR, and non-tech functions have adopted agents at nearly the same rate as technical roles. OpenAI reported that a quarter of their workers have at least four agents running at one time every week. Meanwhile, studies from METR, the UK AI Security Institute, and Epoch show that AI systems are doing the equivalent of two to seventeen weeks of human engineering work from a single prompt, in runs lasting fourteen hours or more. Mollick argues that as AI can do longer, smarter, self-correcting tasks, constant human intervention is no longer required, and that changes everything about how work gets organized. The best way to use agents is to think of yourself as a manager. And the turbulence around AI, the lurching policy changes and market swings, is not a sign of an immature field settling down. It is what happens when institutions moving at the speed of committees try to track a capability curve that is exponential and not human in nature.

Google Cloud shipped a useful update to Cloud Monitoring this week: alert policies with two-year lookback windows using PromQL, plus dynamic thresholding against historical baselines. The practical example they walk through is runaway AI token costs. You can configure an alert that triggers if the most recent ten minutes of accumulated token usage is more than twenty-five times the one-week historical average. That alert fires to a Pub/Sub notification channel, which kicks off a Cloud Run function that calls the Cloud Quotas API to lower your token usage quota to zero, immediately stopping the overspend. They also published a call for design partners on AI-based anomaly detection coming to the alerting product.

Gergely Orosz covered "smart model routing" in The Pragmatic Engineer. He looked at vendors like Factory Router, Not Diamond, Vercel AI Gateway, and others that automatically pick the right model for a given task. The pitch is straightforward: prices for tokens vary by model by a factor of ten to twenty, and many tasks do not need the most expensive model. Factory Router claims twenty to twenty-five percent cost savings. Not Diamond claims around thirty percent. The CEO of Factory AI told Orosz that demand has been off the charts from large enterprises, and that hosted open models are sufficient for around sixty percent of coding-related work in terms of token spend. Smart model routing is looking like it will become table stakes.

Finally, from Latent Space, Adobe Principal Scientist Carlos Sanchez demonstrated what Adobe calls an "agentic site": a web experience that assembles itself around the needs of each visitor. Rather than selecting from a predefined set of personalization options, the system uses the visitor's browsing behavior and search queries as signals, groups them into an intent category, and uses an LLM to compose a personalized page in real time. In one example, a visitor interested in camping received a version of a coffee machine site whose copy, product selection, and content had been reorganized around making coffee outdoors. Sanchez said the technology is no longer hypothetical. The current inference cost is roughly one to two cents per page, and that is only going to get cheaper. He also flagged the flip side: websites in 2026 and beyond need to serve not just human visitors but personal agents that arrive carrying a richer expression of preferences than a cookie could ever infer. Whether it is two versions of a site or one site with both visual components and agent-accessible tools, everyone is still figuring it out.

That is episode 818. A running theme this week is agent skills and loops, and the shift from chatbot-style interaction to long-running agentic workflows. We have pieces on skill building, loop engineering, model routing, and token efficiency alongside articles on the structural changes in how we build and deploy AI systems. The common thread is that the harness, the process, and the encoding of knowledge into reusable, composable units matter more than ever.

No Nostr signer detected