Seroter's Daily Reading — #868 (September 16, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/b17c1ff5af6eb06d83c11e4c0fc65ae02d78cd54947514ad18debd7404f23759.mp3

Episode 868, September 16th, 2026.

Today I talked to a company who asked me about some advice they got from another vendor. The question was basically, should we really use frontier models for everything at our company, or is that vendor delusional? And my answer was simple: smart companies are picking the right type of model for the task, including open, flash, and pro models. That spirit of matching the tool to the job runs through a lot of today's reading.

Let's start with a piece from Sean Goedecke called Tell Agents the Why, Not Just the How. The argument is that early AI agents were, in his words, enthusiastic idiots. You had to spell out exactly what you wanted them to do, down to the method names. But the models have gotten smarter, and the failure mode has changed. Today when a frontier model does the wrong thing, it's usually not confusion, it's an incorrect assumption about your goals or priorities. His example is great: a model writing code for itself will happily produce minified, unreadable code, even though it's perfectly capable of writing clean human-readable code. You just have to tell it that humans will be reading it. So his advice is to give the agent context on your priorities, not just the specific task. He shares a real prompt where roughly half of it is broad context: the long-term goal, who it's for, what he cares about like keeping his laptop cool. That extra context is what let the model suggest better approaches he never would have written into a spec. If you're just handing over a concrete technical spec, you're basically recreating the XY problem: asking for expert advice without giving the expert the context it needs.

Next, a related piece from Capgemini engineering called The Documentation You Have Is Not The Documentation Your AI Needs. Every enterprise has the same graveyard: SharePoint sites and shared drives full of PDFs describing how a system used to work rather than how it works now. The architecture diagram wasn't updated when the system migrated, the runbook points at a decommissioned server. This was tolerable when the only reader was a human, someone who could check the date or trust their own experience over the page. But an AI agent can't do that. It reads a stale PDF with the same confidence as a current one, and answers just as fast either way. The piece makes a sharp point: humans compensate for bad documentation, but AI exposes it. And MCP changes the economics here, because a page nobody opens costs nothing to leave wrong, but expose it through an MCP server and an agent can query it hundreds of times a day, acting on information it has no way to distrust. So documentation becomes runtime infrastructure, and that can't be left to rot. If you want AI to answer real operational questions rather than just impress in a demo, fix the docs first.

Moving to infrastructure, Google announced that Agent Substrate brings high-density, scalable, trusted infrastructure to GKE. This is the idea of an agent-ready Kubernetes. The core problem is that agents spend most of their time waiting, on model inference or tool responses, and reserving CPU and RAM for idle containers wastes scarce capacity. Agent Substrate releases resources the moment an agent pauses, snapshotting its state so it can resume in milliseconds. That zero-idle model can pack over a thousand dormant agents per host, roughly ten times the compute density of traditional setups. The clever part is that Kubernetes still manages the machines and self-healing, while a purpose-built data plane handles the sub-second suspend and resume. It's open source and available to GKE customers, with Nous Research, who build the Hermes agent, as an early design partner.

There were a couple of pieces I couldn't fetch in full today because the sites were blocking, but they're worth flagging. One is a Medium post on the death of the static UI and building context-aware mobile apps in 2026. The title says a lot: adaptive interfaces are coming, and in some cases they're already here.

The other is a Google Cloud post called Do Agent Skills Help? I Ran 72 Trials to Find Out, by Karl. The caution there is that you might be loading up skills that don't actually make a difference, and the question is whether you're testing for that.

A change of pace next. Dave Porter wrote a piece called The Value of Being Bored in the AI and Attention Economy. This one resonates with me a lot. His argument is that we've grown so accustomed to constant distraction, to having a side show on the second monitor, that we've forgotten what boredom is actually for. When you're bored, your brain shifts into the default mode network, where you reflect and wander and, often, come up with creative ideas. The connection to AI is interesting: in an AI-driven engineering world, our value is even more centered on creativity and non-linear thinking, the ideas an LLM can't derive from its training data. But that requires conditioning ourselves away from the attention economy and back toward being comfortable with a little boredom. He talks about trying to be more present, and about getting off screens while driving or running, and rediscovering that his best ideas come when he has space to combine things he's read.

Then there's a big one from Google Cloud: the Forrester Wave for Public Cloud Platforms in Q3 2026 named Google a leader. I don't think I've seen us in this spot before, and some of the positions might feel unexpected. Forrester gave Google the highest possible scores in containers and Kubernetes, serverless, and operations management, and five out of five across database, analytics, data integration, and data governance. The report frames it around enabling the agentic enterprise, and Google leans hard on the co-design story: the same infrastructure that powers Gemini, Search, and YouTube, now available to customers. It's a strong validation, and it connects neatly to the Agent Substrate announcement from earlier in the episode.

On the more sobering side, The New Stack published a piece with a great headline: Your AI Coding Spend Bought 25 Percent More Output. Duplication Rose 81 Percent. The data comes from GitClear's Maintainability Gap report, covering over six hundred million analyzed changes from 2023 to 2026. Heavy AI users gained about 25 percent on their own prior velocity, a long way from the ten-X claims floating around. More troubling, block duplication rose 81 percent, while moved code, the signature of refactoring, fell from 21 percent of changed lines in 2022 to under 4 percent in 2026. Before AI, developers chose refactoring over copy-and-paste about two to one. Now they're roughly five times likelier to copy and paste. The author's point is that technical practices like refactoring and test automation aren't side quests, they're the work. And the glimmer of hope is that the teams doing well with AI are the same teams that outpaced the industry before AI, the ones with rigorous discipline.

Related to that, HBR published Stop Automating Old Processes, Design New Ones Instead. The piece notes that companies expect to roughly double AI spending this year, yet only 12 percent of CEOs report both revenue and cost benefits, and 60 percent of organizations still see no enterprise-wide EBIT impact. The message, as I read it, is to look beyond the individual task and see the whole workflow, not just bolt AI onto processes that were designed for a different era.

And a nice pair of bookends to close out. Michael Lynch wrote How to Write an Effective Software Design Document, arguing that even in an AI world, a well-done design doc still matters, because it forces you to think through the hard decisions before you waste time on the wrong implementation. He walks through what belongs in a doc and, just as important, what doesn't, using the simple test of asking what the penalty is for being wrong.

And finally, Google Cloud shared a post on a Database Onboarding Agent and Skill that helps people move from choice paralysis to day-zero provisioning. The idea is that if we're going to empower agents to do work for us, or even just help humans choose between options, these kinds of decider skills are going to matter more and more.

The theme tying a lot of this together is context. Telling agents your priorities, not just your specs. Keeping documentation trustworthy because agents can't tell when it's stale. Designing new processes instead of automating old ones. And, on the human side, leaving ourselves enough empty space to actually think. Thanks for listening, and I'll see you next time.

Your signing session ended