Seroter's Daily Reading — #790 (May 22, 2026) — Seroter's Daily Reading

Listen: https://blossom.nostr.xyz/a538c7478d3a1182444725b36b07e831727aca5a3213a956fc38ebfe6a99e698.mpga

Seroter's Daily Reading, episode 790 — May 22, 2026.

Seroter notes a holiday weekend in the US and a chance to breathe after a couple of big events, with more coming up in Europe.

Let's get into it.

Starting with a piece from Davenporter on AI and the New Business Moat — the idea that LLMs are now capable enough to do work that companies used to hire specialized firms to handle. He gives a clever, concrete example: he used Gemini to design a xeriscape plan for a rental property, and got a good-enough result for free. Why hire a landscaping firm for that task? The point isn't to dump on landscapers — it's that AI is eroding knowledge and process advantages across all sorts of industries, often before the businesses even notice. The response from established firms isn't to panic but to move the moat: double down on proprietary data, deepen client relationships, or shift toward the execution side of things. He offers five tactical steps worth sitting with, including paying for AI so you aren't training competitors, asking AI what it already knows about your domain, and using AI to actually strengthen your advantages rather than just watching it erode them. It's a useful reframe — AI doesn't make your moat disappear, but it forces you to be deliberate about what the moat actually is.

From CodeOpinion, a piece on Scaling Software Architecture Without Overengineering. Derek argues that the word "scale" is so vague it usually obscures more than it reveals. Are we talking about user scale? Team scale? Database scale? Deployment scale? He points out that the tooling each scenario demands — microservices, message brokers, multiple databases, Kubernetes — all come with serious costs and tradeoffs, and you shouldn't pay those costs until you actually have the problems that justify them. The more interesting insight is the distinction between logical and physical boundaries. You can have well-defined logical modules inside a monolith, each owning its own data and communicating through contracts. That gives you the structure to split things apart later when you genuinely need independent deployability or different scaling characteristics. But spreading a rat's nest of coupling across multiple services just creates a distributed monolith, which is worse than the starting point. He calls this the loosely coupled monolith, and the key takeaway is that you can build a path for scale without pre-paying for complexity you don't need yet. Messaging doesn't fix bad boundaries, and adding Kubernetes doesn't make you more scalable — it makes you more complicated, which are very different things.

Google Cloud announced Data Agent Kit at Google I/O, and Seroter highlighted it in his session. Data Agent Kit is an open-source collection of data engineering and data science skills, tools, and plugins that integrate directly into environments developers already use — VS Code, Claude Code, Codex, Gemini CLI, and others. The core problem it solves is fragmentation: agents need access to enterprise data, but the tooling for building and managing those connections is all over the place. Data Agent Kit brings MCP tools for BigQuery, AlloyDB, and Cloud Storage into a unified harness, along with pre-codified skills for query optimization, ML best practices, data validation, governance, and troubleshooting. The idea is that practitioners go from manually writing pipeline code to intent-driven engineering — describing the desired outcome and letting the AI-augmented system figure out the execution. There's also an interesting routing layer that automatically picks the right compute engine, whether that's BigQuery for SQL-native analytics or Spark for distributed ML training. If you're doing data engineering work and haven't looked at this yet, it's worth blocking off an afternoon.

From Guillaume Laforge at Devoxx France, a recap of his talk on Agentic Design Patterns. He lays out a pattern language for building reliable, scalable AI agent systems — moving well past "hello world" into what it actually takes to get agents to work in production. The patterns include hierarchical agent decomposition, where a manager agent orchestrates specialized sub-agents rather than throwing everything at a single generalist. Feedback loops, where an agent's output gets passed to a critic or verifier and the agent reflects and regenerates. Programmatic planning, where you use state machines or hardcoded sequences for business processes that need strict determinism. And the goal-oriented action planning pattern borrowed from game AI — defining goals, preconditions, and effects rather than hardcoding a fixed sequence. He also covers progressive disclosure, the idea that you shouldn't overwhelm an agent with every tool and instruction at once; instead, you inject specific skills dynamically when the agent identifies a need, keeping the context lean and reasoning focused. The takeaway is that agents provide the reasoning engine, but it's the orchestration and harness engineering — guided by these patterns — that actually gets them to their goals consistently.

The Go team shipped an official pkg.go.dev API, and it's a good one. For years, developers building tools, IDE integrations, and automated workflows had to scrape the site or rely on fragile workarounds. The new API provides a clean, GET-only, stateless interface for querying package metadata — everything from package info and module versions to symbol listings and vulnerability data. The design principle is precision over convenience: where the web interface resolves ambiguous package paths automatically using a "longest module path" rule, the API requires you to specify the module explicitly to avoid silent ambiguity. They're also shipping a reference CLI client called pkgsite-cli that shows how to interact with the API from the terminal. For Go developers building AI-assisted tooling, this is foundational infrastructure — structured, stable access to the module ecosystem without scraping. It's nice to see the Go team thinking about the tooling ecosystem that AI coding tools depend on.

A piece from Research-Driven Engineering Leadership asks a sharp question: how well do public benchmarks predict AI coding agent performance in production? The answer, based on Meta's REAP pipeline and their Harvest benchmark built from real developer-agent sessions, is: not very well. Production prompts look nothing like GitHub issues — they assume implicit enterprise context, reference internal vocabulary and prior diffs, and embed IDE workflow actions. The language distribution is also very different. Harvest is dominated by Hack, with Python only 18.9 percent, while SWE-Bench is Python-only. A Python-heavy leaderboard tells you almost nothing about how a model performs in a polyglot codebase. Meta found a meaningful 15-point spread between the weakest and strongest frontier model on Harvest tasks, which is large enough to drive real deployment decisions, but getting that data required building evals from actual production sessions. The practical advice: build a small production-derived eval before locking in a model choice, treat the agent harness as a first-class variable since the same model performs very differently depending on available tools, and re-evaluate context files after each harness upgrade because what helps a thin harness can become noise in a richer one.

James Governors at RedMonk has a thorough roundup of Google Cloud Next 2026: The Agent Era and the Full AI Stack with his analyst lens on what actually matters. Google Cloud posted 63 percent year-over-year growth to 20 billion dollars in Q1 — absolutely crushing it, as he puts it, and now 18 percent of Alphabet's total revenue. Google is leaning hard into being a full-stack AI provider, owning the whole thing from custom TPUs through Gemini models down to productivity apps. The agent story is where things get interesting. Google introduced Gemini Enterprise Agent Platform with agent identity using cryptographic identities, an agent registry, and agent gateway — addressing the real operational challenge that agents are capable of taking destructive action and need guardrails beyond a markdown file. There's also agent simulation, evaluation, and observability. He makes the Kubernetes comparison explicitly: just as the container revolution eventually needed an orchestration layer, we're at that same inflection point with agents. Multiple autonomous agents working in parallel, requiring asynchronous handoffs and shared state management — that's a pattern that desperately needs infrastructure. One striking detail: GitHub's reliability issues are being exacerbated by agent-based software growth. There's just so much code being generated. And Jarred Sumner rewrote the entire Bun runtime in Rust — a million lines of AI-generated code. That's the scale we're dealing with. Governors also notes the virgin media O2 case study on Knowledge Catalog: twenty thousand different data assets, AI-enriched and made agent-ready. The big idea from Google's Andi Gutmans is that we're now dealing with an expectation of zettabyte-scale data management, because agents take action, not just queries. Rebuild everything in flight — that's the theme for 2026.

From Milan Milanovic, a piece titled Code Was the Smallest Part of the Job, which Seroter flagged as a better framing than "easiest." After more than twenty years in the industry, Milan writes that the parts compounding into real expertise are almost entirely not coding. The thirteen lessons he shares are grounded in that experience. A few stand out. Debugging — most days you're not writing new code, you're checking logs and understanding what's broken, and AI can't do that part well yet because it doesn't know your database, your infrastructure, or your prior decisions. Code as liability — every line is a bill you pay in maintenance, and the shift in mindset from "what should we build" to "what's the least we can build to make this work" removes most over-engineering. Solving the right problems — closing tickets is not the same as moving the system forward, and the engineers who get noticed pick problems nobody assigned. And planning before coding — one hour of thinking before the editor opens saves days of rewriting. He also makes a point that lands differently with AI in the picture: code wins arguments. Build the smallest thing that runs and the conversation moves from opinions to facts. With AI, building that prototype has never been cheaper. There's no reason to argue in the abstract anymore.

What's new in Flutter 3.44 shipped. The article was behind a bot verification wall so I couldn't pull the details, but Seroter says you might need to block off your afternoon to read everything in this release, and that it's impossible to skim it without being impressed by the breadth and momentum. That's a strong endorsement from someone who sees a lot of releases.

Wrapping up with a piece from CIO Dive on the need for a people strategy to scale AI. This one doesn't break new ground conceptually, but the framing from practitioners is useful. The core point is that for every dollar spent on AI technology, companies should consider spending three dollars on people — covering skills, culture, and change management. At MIT Sloan, Travelers' CTO put it simply: AI scales with people, systems, and workflows. Liberty Mutual's CIO referenced research framing tech and talent as a one-to-three ratio. The human concerns include FOBO — the fear of becoming obsolete — and the need for human-centric skills alongside technical ones. PwC developed fifteen human-centric skills for its AI-native push, everything from coaching and empathy to agility and judgment. The harder practical question is performance measurement: how do you hold people accountable for AI adoption and fluency? PwC is still figuring it out and hasn't introduced AI fluency as a formal metric yet, which is an honest admission. The bottom line: technology leaders underscored time and again that being a people leader is critical, and that if employees aren't on board, change isn't sustainable. Nothing revolutionary, but useful grounding for conversations with leadership.

That's episode 790. Lots of threads here around the agent era — how to build them, how to deploy them, how to manage the infrastructure and security they demand — alongside some sharp reminders that the work of software engineering remains stubbornly human in the ways that matter most.

AI and the New Business Moat — Davenporter
Scaling Software Architecture Without Overengineering — CodeOpinion
The future of agentic development: Redefining the data practitioner lifecycle with Data Agent Kit — Google Cloud Blog
Agentic Design Patterns — Guillaume Laforge
Introducing the pkg.go.dev API — Go Team
How well do public benchmarks predict AI coding agent performance in production — Research-Driven Engineering Leadership
Google Cloud Next 2026: The Agent Era and the Full AI Stack — RedMonk / James Governors
Code was the smallest part of the job — Tech World With Milan / Dr Milan Milanovic
What's new in Flutter 3.44 — Flutter Blog
CIOs need a people strategy to scale AI — CIO Dive