Seroter's Daily Reading — #831 (July 23, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/4680db8501442975d79d69ac215a6d147ef8f805573db0fa58027f6cd53ee421.mpga

Episode 831 — July 23, 2026

Let's dig into today's batch. Got a good mix of enterprise AI strategy, developer experience, and some thoughtful pieces on how we actually work.

Starting with a piece on Where the real competition is in AI. Matt Asay over at InfoWorld makes a point that's easy to overlook in all the model-of-the-week announcements. He argues that the real battlefield isn't which foundation model you pick — it's where AI-assisted work actually happens. And that place, he says, is still controlled by incumbents like Oracle, Microsoft, SAP, and Salesforce. The interesting wrinkle is that open protocols like MCP actually strengthen that position rather than weaken it. If every model speaks the same language and every agent can interoperate through common standards, enterprises are free to pick whichever frontier technology looks best without rebuilding integrations from scratch. The protocol becomes interchangeable. Open standards reduce friction, but they rarely eliminate competitive advantage — they just move it. We saw this with Kubernetes: workloads became dramatically more portable, but that didn't make AWS, Azure, and Google Cloud interchangeable. The lesson holds. Standards are good. They're necessary. But don't mistake them for a leveling field.

Shifting to something that cuts closer to how we actually feel at work. Research-Driven Engineering Leadership published a piece this week on How does adopting AI tools change developer burnout?. This one draws on a study from Oregon State University that surveyed 442 professional developers across 56 open-source communities. The framing is the Job Demands-Resources model — basically, burnout comes from an imbalance between what work demands of you and what resources you have to meet it. The study found that AI adoption pushes on both sides at once. On the demand side, organizational pressure to adopt AI and the intensified workload from having to review and validate more AI-generated code both correlated strongly with burnout. One developer in the study put it plainly: "I move fast with AI and move mountains of work, but I am losing my passion for the work." On the resource side, autonomy and learning support pushed burnout back down. Developers who got to decide how they used AI, and who had real training to learn it, reported less strain. Interestingly, burnout showed up across the board regardless of role, seniority, or company size. This isn't a junior developer problem or a big company problem. It's a broadly shared experience. The application from the research is pretty clear: credit the verification work, not just the speed. Update your KPIs to account for the load of reviewing AI output. Protect autonomy over how AI gets used — top-down mandates were among the sharpest stressors. And fund learning instead of assuming people will figure it out on their own. Nearly a quarter of developers in the study reported getting no real learning support.

Speaking of security in AI-native development, Anthropic published a detailed look at How Anthropic secures its AI-native software development lifecycle. This is worth reading if you're shipping AI-assisted code at scale. The core insight is that security professionals in an AI-native org have a new lever: they can shape how code gets created, helping prevent vulnerabilities at the source. At Anthropic, security guidelines are encoded in CLAUDE.md files so the code follows best practices the minute it's generated. That's a closed loop — once an agent discovers a bug class, the relevant file gets updated to prevent it from recurring in future code. They also use automated security reviews that run while Claude generates the code, and they've moved developer coding to remote VMs with tight egress controls. This matters especially when agents are reading untrusted input that could carry prompt injection. The egress controls mean an injected instruction can't reach arbitrary destinations on the internet. On the review side, they've combined automated and deterministic reviews while reserving human review for regulated or truly critical code. The share of PRs getting substantive review comments has grown from 16 to 54 percent, and about a third of the bugs behind past incidents would have been caught by their automated processes. One striking detail: their incident response agent, after a model upgrade, actually reached out over Slack to another Claude instance on its own initiative and asked it to push a fix. It was caught at a human review gate as designed, but the lesson is important: draw the boundary around access and actions, not around what you believe a model can do.

Now for something that gets into the mechanics of GPU economics. O'Reilly published a piece on The Tokens You Can't Wait For — diffusion models and why they matter for latency-bound workloads. Here's the setup: somewhere in a Singapore data center, a bank is paying for eight H100s that spend most of the night waiting. They bought the hardware for good reasons — sovereignty, lock-in concerns — but the finance team is asking why these expensive machines run at a fraction of their capacity. The issue is a mismatch between how standard autoregressive models generate text and how enterprises actually use them. Standard models generate one token at a time, and the bottleneck is memory-bound: the chip has to stream the full set of weights for every single token, which leaves compute units idle. The escape hatch is batching, which amortizes the weight read across hundreds of tokens. That works great for overnight batch processing, but when a single request has to return in under a second — a developer doing code completion, a customer at the counter — you can't batch. Diffusion models attack exactly this problem. They refine a whole block of tokens in parallel, so they're compute-bound even at batch size one, saturating the GPU without the concurrency you don't have. The numbers are real. Inception Labs' Mercury reported over 1,100 tokens per second on H100s for code generation. Google showed the paradigm at frontier scale with Gemini Diffusion. So the headline is true in one specific place: for a latency-bound, single-stream request, diffusion can run an order of magnitude faster. But it's not a blanket upgrade. For offline batch, batching already solves most of the problem. The economic win appears when the token you would otherwise buy is expensive — frontier or reasoning output at five to fifteen dollars per million — where a saturated owned node comfortably undercuts the API. Or when data can't go to an external API at all. That's where diffusion earns its keep. The lesson is to know which tokens you're carrying: latency-bound, decode-heavy, low-value generation is the diffusion sweet spot, while high-value reasoning stays on frontier autoregressive models.

There's a piece from Riccardo Ural on Medium about How I built a skill to fan out 20 workers to fix my old Rails App on Antigravity. Unfortunately the full content is behind a security check, so I can't dig into specifics. But the pattern itself is interesting — parallel task execution using AI agents. We'll likely see more of this.

Then there's an article from The New Stack on Amazon, Microsoft, and Google are converging on the same enterprise agent architecture. Over the past nine months, each has introduced or renamed an enterprise agent platform, and all three now have the same core components: runtime, memory, tool gateway, identity, observability, and governance. The piece draws an instructive parallel to Cloud Foundry and the evolution of platform as a service. Between 2011 and 2016, developers built applications from virtual machines, load balancers, message queues, and monitoring agents, each with its own API and operational model. Cloud Foundry unified those pieces around an application contract. The agent ecosystem is approaching a similar inflection point. What's striking is the table the piece draws mapping PaaS abstractions to agent platform equivalents — application source maps to agent code, buildpacks map to framework detection, backing services map to models and memory providers, service bindings map to authenticated tool attachments. The convergence is rational behavior rather than a conspiracy. Infrastructure companies build vertically integrated platforms because integration is where the margin lives. The consequence lands on customers rather than vendors. But there are differences. AWS gets close with its harness export path that preserves the model, prompt, tools, memory wiring, and container environment in one command. The real question is governance: whether a project is controlled by a neutral foundation or by the vendor selling the managed version. The Linux Foundation's Agentic AI Foundation, with founding projects including MCP and A2A, is the most credible attempt at neutral governance so far.

On a related note, Guillaume Laforge wrote about the Open Reasoning Format: Building Self-Learning AI Coding Agents Without Server Infrastructure, a lightweight file-based specification that lets AI coding agents record and retrieve operational learnings across sessions. The problem it addresses is real: when an agent encounters a domain-specific trap in one session, that lesson is typically lost when the next session starts. With ORF, an agent that solves a tricky problem can record what broke and how it fixed it, and future runs can load those playbooks and skip dead ends. The architecture is simple: a small index file that categorizes experiences, playbook files with YAML frontmatter describing the trap and the validated path, and an agent skill backed by a Python helper script. The author tested this on SWE-bench scenarios and found roughly 50 percent reduction in step count. On one scenario, the cold run took 25 steps including four debugging loops, while the warm run with the playbook loaded passed on the first attempt in 12 steps. The constraint the author set was zero server infrastructure — everything lives in local files in the project repository that can be committed to version control. There's no vector database, no embedding API, no sidecar. The file-based approach works because it uses progressive disclosure: the agent reads a small index first, then frontmatter descriptions, then only the specific playbook relevant to its current task, keeping prompt overhead minimal.

Moving to the business side. Battery Ventures published some data on Measuring AI ROI: The Next Big Conundrum for Enterprises., and the numbers are striking. Ninety-eight percent of enterprise technology leaders are increasing AI spend over the next twelve months. But only 6 percent have a well-defined measurement framework tracking ROI consistently across the organization. Fifty-three percent say they're seeing clear ROI from some area, but only 16 percent report that more than half of their AI projects are delivering measurable returns. Fourteen percent say none of their AI projects have delivered measurable ROI yet. The areas where returns are clearest are software development and engineering productivity — coding assistants and automated QA — followed by internal operations and customer support. The metrics skew toward cost and efficiency. Seventy-six percent measure cost savings or operational cost reduction. Seventy-three percent measure employee productivity or time saved. But revenue-based metrics lag behind — only 38 percent are tracking revenue generated or attributed to AI. As budgets scale and reallocation becomes more visible in budget reviews, the ROI conversation will intensify. Organizations that build consistent measurement frameworks now, before the scrutiny arrives, will be in a far stronger position.

Over at the Google Testing Blog, there's a post on Prefactoring: Clear the Way for Your New Feature. — preparatory refactoring done before implementing a new feature. The idea is straightforward: instead of forcing a new feature into existing code that wasn't written for it, you rework the codebase first to make the change natural. Kent Beck is quoted as saying "first make the change easy, then make the easy change." The benefits are cleaner implementation, easier reviews since the refactoring and feature are separate changes, fewer bugs from isolating cleanups from functional logic, and easier rollback since focused changes are simpler to revert.

Then there's a piece on That You Must Suffer for Greatness is a Dangerous Lie. The argument is that while hard work is absolutely necessary to achieve anything great — that's not a dangerous lie, it's supported by decades of research on deliberate practice — hard work is not the same as suffering. The grindslop that fills the internet, the performative hustle culture that touts suffering as a badge of honor, makes people think that if they're not miserable they're not working hard enough. But elite performers who sustain greatness over the long haul tend to enjoy the work. The piece quotes Erling Haaland as an example: fierce and intense on the pitch, and also a total goofball who smiles and cracks jokes after matches. He's not suffering for greatness — he's having fun. The real lesson: find fit first, then apply grit. Before doubling down on hard work, you need a good match between your innate talents and what you're doing. Without fit, hard work is tedious and painful. With fit, it's meaningful, satisfying, and enjoyable.

There was also a piece on Medium from Google Cloud about the The hidden cost of Skills in AI Coding Agents., but the full content is behind a security wall.

Finally, Redis published a useful guide on Model Context Protocol (MCP) vs. Agent2Agent (A2A): which protocol do you need?., sorting out which protocol does what. The core distinction: MCP connects an agent to its tools and data, while A2A connects independent agents to each other. MCP is hierarchical — an agent calls down to a passive server that answers and waits. A2A is peer-to-peer, built for communication between independent agents owned by different teams, vendors, or companies. The useful question isn't how many agents you have, but whether they cross a real boundary. Several agents built by the same team, sharing the same permissions, rarely need a formal protocol between them. A2A earns its place when an agent brings its own identity and permissions that another agent has to respect — not simply when there's more than one agent in play. The piece also notes what neither protocol fully addresses: correlating state across a workflow, observability across multiple agents, and a common interface for agent memory itself. Both protocols carry messages; they don't manage the state, visibility, or memory underneath. That's left as an exercise for the builder.

That's the batch for July 23. A few threads stand out: the tension between vendor lock-in and portability keeps showing up in different forms — open protocols, diffusion models, neutral agent platforms. And there's a consistent theme around the human side of AI adoption: burnout risks, skill costs, and the importance of making hard work feel worthwhile rather than painful. See you next time.

No Nostr signer detected