Seroter's Daily Reading — #834 (July 28, 2026) · Seroter's Daily Reading

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

Daily Reading episode 834, July 28, 2026.

Anytime a new version of something comes out in the tech industry, people start asking what's next almost immediately. I'm excited by the stuff in the pipeline too, but I'm more interested in what we've already got. Let's use what we shipped before obsessing over what we haven't.

Starting with a piece that paints a somewhat concerning picture. An essay on How AI Is Changing Open Source covers three big trends. First, project inflation. GitHub is flooded with repos now, but the quality signal is gone. It used to be that if someone took the time to build something with thousands of lines of code, you could assume they knew what they were doing and would maintain it. That assumption is gone. You can generate a project with thousands of lines in minutes, and people do, posting to GitHub with zero intention of ever maintaining it. It's not open-source software — it's just code on GitHub. The author points out that curated software sources like Linux distribution repositories may make a comeback simply because users are desperate for something they can actually trust six months down the road.

Second trend is review overwhelm. Writing code used to be a natural filter because it took real effort. That's gone. But someone still has to review the code before it goes anywhere serious, and those review processes are at their limits. The author, who maintains the Meshy project, describes getting a pull request with nine thousand lines of AI-generated code, thousands of which were pointless quote style changes, unrelated modifications, and it even overwrote his own recent changes. The author never responded. His takeaway was that even an hour was too much investment for a contribution like that. He suggests other projects will tighten requirements to survive, and points to Flathub's decision to reject AI-generated apps, which caused a stir but makes sense when you consider that three people handle reviews for thousands of apps.

Third trend is declining motivation to publish code at all. Some projects are transforming from open development to closed development. And there's the fear of license circumvention. Copyleft licenses like the GPL exist to keep software open forever, but an LLM that trains on your code can generate a similar solution under a proprietary license, bypassing that principle entirely. One prominent open-source advocate put it bluntly: open source in the age of AI means offering up your blood, sweat and tears for others to rip off in innumerable ways. Whether you agree or not, it's a view I'm hearing more and more often from people who used to publish every last helper script.

Now let's look at something more optimistic. A field report on Rich UI in Gemini Enterprise: A2A Agents and A2UI Primitives, specifically around A2A agents and A2UI primitives. The A2UI protocol, created by Google with contributions from teams at Flutter and CopilotKit, equips agents with a curated catalog of battle-tested UI components. Instead of a model freehanding raw markup, it composes interfaces from pre-approved primitives. Gemini Enterprise ships with eighteen of these primitives, everything from buttons and text fields to tabs, modals, video, and audio. And everything is interactive — buttons dispatch real actions, text fields two-way bind, tabs switch, modals open. The author calls it useful for humans and declarative for AI agents, and this is what it looks like when generative UI actually works in a production enterprise context.

Staying with Google, MCP's biggest update removes the machinery many servers were built around. Sessions and the initialization handshake are being removed, and the goal is making every request stand on its own. The changelog sounds drastic on first read, but really it's about simplification. Remote MCP servers can now operate more like conventional stateless HTTP services. Three replicas behind round-robin, no affinity configuration, no protocol session store to run or recover. Rolling deploys no longer strand a client on a removed instance. The protocol still doesn't manage application state, but the statefulness was never a feature for most servers anyway. It was a tax the protocol had created for its users. Now that tax is gone. The release candidate window opened on May 21st and the final specification arrives today, July 28th.

If you want to see the MCP security angle in action, there's a post on Don't Let Your Agent Mess Up Your Database using a similar pattern. The idea is simple but the implementation is important. You define what an agent can do against a database, give it a limited set of rights, and let it go. It fills a gap that MCP itself doesn't address natively.

Moving to management and engineering culture now. A piece from the manager dot dev newsletter highlights 3 things top 1% teams do differently, based on conversations with Andrew Churchill, CTO of Weave. First, a constantly-improving hiring process. His teams update interview questions based on what they learn from failures, and they do paid work trials of three to five days before extending offers. Second, learning how to do parallelization effectively. With coding agents, switching between four or five different sessions is a viable workflow, but most ineffective AI usage comes down to ineffective context management. The best engineers figure out how to work across multiple threads. Third, adapting code review flows. AI code reviewers can handle coding standards and validation. The real value of human review is direction, and the best way to review code is actually during the planning phase, not after it's written. His team stopped requiring human review on every PR. Around forty percent of PRs get no review at all, and code review is optional rather than mandatory. That last point is going to be controversial, but he's explicit about it and the reasoning is sound.

On the topic of agents and how to build them, there's an argument for Why I write skills instead of agents for knowledge work. A skill is just a folder with a markdown file and optional scripts. Building a custom agent means defining roles, wiring handoffs, and owning the orchestration. The argument is that skills iterate faster, the harness does the scaffolding, and you get free upgrades as models improve without touching your code. Custom agents win on unattended execution where you need structural guarantees a model cannot bypass. But for interactive knowledge work where you're reviewing output before it ships, a skill gives you real-time steering and faster iteration. The choice comes down to task variance and execution volume. High volume with low variance is sweet spot for a custom agent. Low volume or high variance, a skill is the right place to start.

And speaking of skills, there's a walkthrough on How I set up containerized dev environments you can spin up in seconds for Antigravity CLI, which lets you isolate an agentic CLI into its own sandbox with a limited set of rights before letting it run wild. It's the same pattern as the database security piece, applied to the development environment itself.

On infrastructure, Google Cloud rolled out Detect early and enforce firmly with Google Cloud's enhanced cost controls for AI spend. AI costs are notoriously hard to predict because a five-word prompt can trigger complex operations and significant spend. The new features automatically build a seasonal baseline of daily costs per service with no manual threshold configuration, and they alert you before actual costs are reported with a root cause analysis highlighting the top three SKUs driving a spike. These are native features in the billing console, no custom JSON policies or complex roles required.

And continuing with Google, Gemini API Managed Agents: 3.6 Flash, hooks, and more just got a significant update. You can define your custom agent with its own prompt, tools, and hooks, then run it on a schedule in the cloud. Hooks are particularly powerful here. You can define pre-execution validation pipelines — like running a gate before every code execution call — and post-execution formatters. Teams are already using hooks in production. One AI-native investment bank uses post-tool-execution hooks to run automated logo verification inside the remote sandbox the moment the agent writes its company list. Without hooks, their validation code had nowhere to run because the sandbox is remote. Now the hook triggers their pipeline inside the sandbox in real time. There's also a free tier for managed agents and budget controls that let you cap total token consumption and continue incomplete interactions.

On softer topics, a Friday Forward piece on Be Bored. There's a famous study where participants were left alone in a room with nothing to do but sit with their thoughts, and the option of pressing a button that delivered a mild electric shock. Two-thirds of the men and a quarter of the women pressed the button rather than sit still. One person shocked himself 190 times in fifteen minutes. We laugh, but most of us do a similar thing dozens of times a day with our phones. The cost is real. Some of the author's best ideas have come directly out of boredom, including a chart that became the basis of a capacity building framework used by coaches around the world. When your mind isn't occupied, it keeps working in an unfocused way, making connections between things you weren't consciously thinking about. That stray thought during a moment of boredom might be where your best thinking is waiting.

And some HBR management tips on Our Favorite Management Tips on Setting Strategy When the Path Is Unclear. A few that stood out. Center on the mission, the customer, a technology, a regional ecosystem, or friction erasure. Each gives you an organizing principle to guide decisions. The octopus organization concept — adaptive, decentralized, built for change. Spread change instead of scaling it. Top-down scaling kills local ownership. When one team's success is visible, others will pull it in and adapt it. And the false alignment trap, which is something I see all the time. Teams move forward assuming everyone shares the same priorities, only to discover conflicting expectations later. The fix is to debate specifics, not abstractions. Broad goals create the illusion of agreement. Push into details, trade-offs, timelines, and responsibilities.

Last one, on Merge Conflicts Are a Process Problem, Not a Git Problem. The argument is that merge conflicts are a process problem, not a Git problem. A merge conflict only appears when Git genuinely cannot determine which change should win. That conflict isn't a Git failure. The failure happened much earlier, when two developers unknowingly spent days modifying the same code. The real question is how long the branch was open. Every day a branch stays isolated, the main branch keeps moving. Large pull requests multiply the problem. A PR with two thousand changed lines touches dozens of files and almost guarantees conflicts. The fix isn't better Git commands. It's smaller pull requests, frequent merges, communication when multiple developers work in the same area, and feature flags instead of long-lived branches. The worst conflicts are actually the logical ones that never appear in Git at all — where two developers change different files, everything merges perfectly, and production breaks because the logic no longer fits together. Those are the ones continuous integration catches early.

That's episode 834. Themes across today's reading: the tension between AI's speed and our capacity to manage what it produces, whether that's code review, strategic direction, or costs. And a recurring thread about using the right abstraction for the job — skills over agents, hooks for validation, trunks for merging. Use what you've got.

No Nostr signer detected