Seroter's Daily Reading — #832 (July 24, 2026)
Follow into
Save into
Source: Seroter's Original Post
Seroter's Daily Reading episode 832, July 24, 2026. Richard is heading to the horse races tomorrow at the Del Mar Fairgrounds, so naturally he's asked Gemini to help him pick winners. For science. Let's get into the list.
First up, a piece from O'Reilly on The Right Amount of Spec for Agentic Development. This is one of those posts that lands because it doesn't do the usual thing of either worshipping agents or dismissing them. It starts from the real trade-off: zero spec looks cheap on the front end because it gets implementation started right away, but then you pay for it in correction loops, clarification rounds, and review sessions where someone has to act as the oracle deciding whether the output actually matches the goal. The argument is that this oracle problem doesn't go away just because the implementation is cheap. Tests, by contrast, check the same condition every time without getting tired or optimistic before lunch. The post makes the point that for most agentic work, the right answer is somewhere in the middle: enough structure to constrain the work, enough examples to make intent concrete, and enough executable checks that review doesn't turn into guessing. There's a sharp observation about multi-agent systems in particular: once one agent's output becomes another agent's input, interpretive drift compounds. Agent B doesn't know Agent A misunderstood something by ten percent. It just treats the output as ground truth and keeps going. By the time a human sees the result, the original mistake is buried under several layers of competent-looking work. So the spec becomes a contract, and that contract needs schemas, invariants, validation rules, and explicit failure behavior, not just paragraphs of intent. The piece also has a useful riff on context rot: the more design prose, examples, and old acceptance criteria you stuff into the context window, the less obvious it becomes which parts are instructions and which are artifacts. A design document is useful early because the code doesn't exist yet. Later, it needs to shrink. The overall frame is that as implementation gets cheaper, more of the difficulty moves into deciding what correct means and checking it reliably. That framing is worth carrying into every agentic project.
Next, a post from Casey West on Governed Growth, Part 1: Better Together, Governed Apart. This one is about something I don't think gets enough attention: the trust boundary a model's server-side capability crosses is a separate decision from the model itself. Casey puts it plainly: approving a model is not the same as approving that model's web search. A modern model is a base model plus a set of server-side capabilities the vendor runs on your behalf, and those capabilities can cross a completely different trust boundary. The clearest example is web search. When a model answers from its own weights, your prompt goes to the vendor under the vendor's model terms. When that same model runs server-side web search, your prompt is now fanning out to a search provider under different terms, and those terms are sometimes carved out explicitly. With Google Search grounding enabled, Google keeps short-lived debug logs you can't opt out of, with a retention window currently around three days. That isn't your prompts and output, but it's queries derived from them, and the exact clause is worth reading because the terms move. Casey walks through how this plays out with Anthropic's Business Associate Agreement coverage and with third-party MCP connectors, which send your data to a destination the model vendor never sees and cannot govern. The post has an open-source grounding server companion piece that encodes the capability-versus-model split in running code, which is the practical version of the argument. The broader point is that governed growth means you scale capability access up and the guardrails scale with you, and that starts with reading the terms per capability rather than per model.
From InfoWorld, a piece on Determining the ROI of AI requires data that most companies lack. The cloud analogy is useful here. Cloud taught a generation of CFOs that billing without business context is noise, so they stitched cost data plus business data together to get ROI. But AI is harder because it requires three data sources: cost, business, and telemetry. You can have AI invoices and customer revenue, but you have no way to connect them to business value. The token count on an OpenAI invoice doesn't specify which customer triggered which call, which feature it served, or whether the prompt produced a business outcome. That data doesn't exist in the provider's billing, and the piece makes the case that AI providers are not in the business of attributing an enterprise's costs to that enterprise's customers. They are in the business of selling tokens. The granularity they expose is the granularity their billing systems require, not the granularity a CFO requires. Until companies build out their own telemetry layer that bridges from AI spend to business outcome, the ROI story will remain incomplete.
From TechCrunch, Google justifies its massive AI spending with a booming cloud business. Google Cloud revenue spiked eighty-two percent year-over-year to twenty-four point eight billion dollars, well above what Wall Street analysts expected. Sundar Pichai said during the earnings call that the company's AI investments are redefining what's possible across every part of the business and that there is exciting momentum. The backlog of cloud contracting work has climbed to five hundred fourteen billion dollars. Gemini currently has nine hundred fifty million monthly active users, up from seven hundred fifty million at the end of last year. Alphabet's capital expenditures are estimated at one hundred eighty to one hundred ninety billion dollars for the year, which analysts pressed on during the call. Pichai's answer was that he expects compute capacity investments to start paying off in 2027, and that long-term demand indicators look healthier than they did about a year ago. So the buildout continues.
A piece from Code Opinion on 5 Software Architecture Mistakes That Make Systems Hard to Change. The common thread across all five is making expensive decisions before you truly understand the business or the problems you're trying to solve. The first mistake is choosing architecture before understanding the domain. If a project conversation starts with microservices and Kubernetes but nobody can explain the business processes or workflows, it's backwards. Every architectural pattern comes with tradeoffs and added complexity, and the conversation should start with the forces acting against your system, not with the solution pattern. The second mistake is building entity services driven by CRUD, where the system is driven by its data model rather than its behavior. There's a sharp distinction between an operation called UpdateOrder, where you change properties on an order, and an operation called CancelOrder, where you explicitly communicate business intent. When everything is treated as a generic update, you lose that intent and the natural place where business rules and workflow decisions should live. The third mistake is using the database schema as an integration point, which creates shared storage with no explicit contract and no clear ownership of who controls how data is written. The fourth mistake is creating abstractions before you know what varies. If you only have one implementation of an abstraction, you probably don't have an abstraction, you have a hid interface. And the fifth mistake is building for scale you don't have yet, paying all the upfront complexity to build for a level or type of scale you may never reach. The overall message is that architecture should not start with patterns or frameworks. It should start with understanding the business, the workflows, the constraints, and the actual problems the system needs to solve.
Anthropic dropped a big announcement this week: Introducing Claude Opus 5. The headline is that it comes close to the frontier intelligence of Claude Fable 5 at roughly half the price. On Frontier-Bench and CursorBench, Opus 5 is the new state of the art on coding and knowledge work evaluations. On CursorBench at max effort, it performs within half a percent of Fable 5's peak score at half the cost per task. On ARC-AGI 3, a benchmark where the model has to solve novel problems, Opus 5's score is three times as high as the next best model. On Zapier AutomationBench, which measures whether models can complete business tasks end to end, Opus 5's pass rate is around one and a half times the next best model for the same cost, and even at its lowest effort setting it passes more tasks than any other model. There's a useful pattern in the early access testimonials too. Multiple users report that Opus 5 is steadier run to run, which is meaningful because variance is the thing that makes agents unreliable in production. On safety and alignment, Opus 5 scores lowest of any recent model on overall misaligned behavior. It's the most aligned model Anthropic has shipped to date, and it remains behind Mythos 5 on cybersecurity exploitation and biology-related risks. It's available on all platforms at the same price as Opus 4.8.
From DX, the State of AI Impact in Engineering: Q2 2026 report. Some headline numbers: over fifty percent of code is now generated by AI, up from thirty-four percent in Q1, so that steep trajectory is continuing. Median pull request sizes have nearly doubled during the same period, which is an early indicator of technical debt and potential for bugs. The Developer Experience Index dropped from sixty-seven to sixty-five over four quarters, which means AI is improving some aspects of the developer experience like documentation quality and onboarding speed, while creating new friction in others like larger PRs and slower reviews. The net effect is currently negative. There's a striking divergence in the data: Code Maintainability improved by three point eight percent, but Change Confidence decreased by six point one percent. Those two metrics have historically moved together, but this data reveals a new tension. AI helps developers understand code in front of them, but they exhibit less trust in the code they are pushing to production. On the ROI side, saved time is not converting into innovation. AI users are saving an estimated four to six hours per week, but the innovation ratio, the percentage of time spent on new features versus maintenance, has remained flat. Meanwhile, median quarterly AI spend climbed from around one thousand five hundred dollars to around forty-four thousand dollars over four quarters. Leaders who cannot connect that investment to downstream outcomes may face difficult budget conversations in the back half of the year.
And finally, a piece from Daniela Tastro on The Rise of the Subagents. This one's in the shorter format this week, but the topic is the architecture of subagents and what Daniela calls agent swarms. I'm glad to see more people thinking through this because the conversation usually stops at "use more agents" without much rigor about the coordination costs and the contract surfaces between them. Looking forward to a fuller treatment when the piece is fully available.
That's the list for episode 832. Richard will be back on Monday with more.
- The Right Amount of Spec for Agentic Development — O'Reilly Radar
- Governed Growth, Part 1: Better Together, Governed Apart — Casey West
- Determining the ROI of AI requires data that most companies lack — InfoWorld
- Google justifies its massive AI spending with a booming cloud business — TechCrunch
- 5 Software Architecture Mistakes That Make Systems Hard to Change — Code Opinion
- Introducing Claude Opus 5 — Anthropic
- The State of AI Impact in Engineering: Q2 2026 — DX
- The Rise of the Subagents — Daniela Tastro