Seroter's Daily Reading — #784 (May 14, 2026) — Seroter's Daily Reading

Listen: https://blossom.nostr.xyz/537f50cdf8b9f985da7072e1b97e7e8d426fa40bb864ec74ead824ab48bf5a70.mpga

Seroter's Daily Reading, episode 784, May 14, 2026.

Today's list feels a bit more cynical, or maybe just more pragmatic, about AI than usual. That's fine. It's important to see the full range of perspectives.

Starting with a piece from Michael Nygard called The Road More Traveled. It's a look back at what microservices were actually for, and a sharp critique of what happens when you layer AI coding agents on top of an architecture that was designed for an entirely different scaling problem. Nygard reminds us that microservices were never really about technology. They were an organizational solution to a people problem. The whole two-pizza team concept, the goal of keeping coordination costs linear while the team grows exponentially, that was about shipping faster than your competitors. Fast forward to today, and everyone has mandated AI coding agents for their developers. PR volume goes through the roof. Lines of code changed look incredible. Small features ship fast. But here's the thing Nygard identifies: the big things still aren't moving. New markets, new products, cross-cutting features that need multiple teams to coordinate, those are still slow. Because the architecture that was optimized for scaling out a dev organization isn't the architecture you need when you want to scale down. When you want each developer plus their swarm of AI agents to own larger units of code. Nobody's going to volunteer to eliminate their own service. And so instead you get organizational gridlock dressed up in beautiful AI-generated documentation. Nygard closes with a list of forces he thinks will reshape architecture going forward. We need safer shipping. Governance mechanisms rebuilt for AI-scale change. Access control that doesn't fall apart when agents can spin up their own Vercel accounts. Larger ownership scopes per developer. Validation that goes beyond tests in the same repo. And externalized API specifications so agents stop breaking interfaces other services depend on. Worth a full read.

Next up, a tutorial from Google's developer blog on building long-running AI agents with the Agent Development Kit (ADK). Most agent tutorials stop at a stateless chatbot. You have a conversation, the container restarts, everything is gone. Real enterprise workflows don't work that way. HR onboarding takes two weeks. Invoice disputes stall for days. Sales sequences stretch across a month of touchpoints. This post walks through building a new hire onboarding coordinator agent that can pause for days waiting on a document signature, delegate IT provisioning to a sub-agent, wait again for hardware delivery, and then pick right back up without losing any context. The three key architectural shifts the post covers are durable memory schemas instead of dumping raw JSON into a vector store, event-driven dormancy gates instead of active polling or blocked threads, and multi-agent delegation instead of one giant system prompt. The state machine approach is elegant. You define explicit checkpoints like START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, and COMPLETED. Tools advance the state atomically. If the container crashes mid-onboarding, it restarts and reads the current step from persistent session storage, picking up exactly where it left off. And when you need to wait for an external event, like an employee signing their contract, the agent sleeps. A webhook fires, the session is hydrated from SQLite, and the agent wakes up with a state delta that transitions the checkpoint before the next inference call. The whole thing is on GitHub if you want to dig into the code.

Then we have a piece from InfoWorld titled Tokenmaxxing is Super Dumb. The subtitle says it all. This is about gaming metrics around AI token consumption. The author traces the pattern through companies like Klarna and Shopify, where teams are optimizing for tokens spent or lines of code produced, then wondering why the metrics improve but the software doesn't. Managing developers was already hard because measuring the process of writing software is nearly impossible. We tried lines of code, story points, hours in the seat. None of those worked, and they all got gamed. Now we have a new metric that's even easier to game. Tokenmaxxing is just the latest chapter in an age-old battle, and the author's take is that it's a really bad idea. This one is short, punchy, and worth sharing with anyone who runs an engineering team.

Moving on to a piece from The New Stack on the topic of AI creating developers who can't debug their own code. This is one of those articles where the headline is the whole thesis. The setup is that juniors are now completing tasks up to 55 percent faster with AI assistance, and 73 percent of organizations have reduced junior hiring over the past two years. The seniors with AI model, where one experienced developer plus AI replaces an entire entry-level cohort, has gone from theory to default operating assumption in a single year. The productivity numbers are real. They're also misleading. AI made producing code faster. It did not make understanding code any faster. For seniors with a decade of architectural context, that gap is manageable. For juniors, it's the entire problem. The author quotes Ivan Krnic from CROZ saying that the lack of experience that makes juniors fast and willing AI adopters also makes them less reliable to evaluate AI's output. The new expert beginner is not arrogant. They're fast, conscientious, and produce clean code that passes review. They just cannot tell you why any of it works. The piece also flags the structural damage to the talent pipeline. Entry-level tech job postings dropped 67 percent between 2023 and 2024. UK graduate roles dropped 46 percent, with another 53 percent drop forecasted for 2026. And here's the thing that makes this cycle different from prior contractions. In the dot-com bust or post-pandemic slowdown, the nature of the work hadn't changed. Juniors still learned by building, breaking, and deeply understanding why failures occurred. AI reduces that process to a prompt and a confirmation. The two questions the author leaves you with are sharp. Can your juniors explain the code they ship? Can they find a bug without AI? If the answer to either is no, the issue isn't that the role is being reshaped. The issue is that the engineers replacing your seniors are being trained to ship code they can't read.

Next up, an article from O'Reilly on Burnout and Cognitive Debt. This piece draws on work by Steve Yegge on AI vampire burnout and Margaret Storey on cognitive debt. Yegge's point is that programming with agentic AI is fast and fun, but keeping up with your agents is mentally exhausting. He recommends no more than four or five hours a day. Storey's point is different and important. Agents are great at creating software that works but that you don't quite understand. They can generate spaghetti code, convoluted structures that are really what happens in the absence of architecture. And while that technical debt is accumulating, developers are losing track of the design, the structure, the architecture. Storey calls that cognitive debt. The code has problems, and those problems are harder to find and fix because you're unclear on the structure of what you're working with. Other voices pile on. Sonarsource writes about AI reshaping technical debt. Wes McKinney links burnout to accidental complexity and agent scope creep. Tim O'Brien writes that scope creep isn't new, but AI supersized it. Addy Osmani writes about finding your parallel agent limit, coming to grips with what you're capable of accomplishing without compromising your work or your life. The author's point is that cognitive debt accumulates much more quickly when you're burned out. Agents may not be subject to burnout, but the humans who control them are. And velocity without understanding is not sustainable, not for humans, not for machines.

Then a piece from matklad on Learning Software Architecture. This is written as a reply to a researcher physicist asking about how to develop software design skills. The first meta observation is that software design is best learned by doing. Formal courses are mostly make-believe. What really teaches design is being in a position where design is your problem. The second meta observation is the bad news, and it's Conway's Law. Software genesis repeats the social architecture of the organization producing it. Or as matklad quotes from neugierig, we talk about programming like it's about writing code, but the code ends up being less important than the architecture, and the architecture ends up being less important than social issues. The difference between industrial and scientific software, matklad suggests, is not so much about knowledge but about incentives. Something like my PhD needs to publish a paper in three months is a significant explainer. The post closes with concrete recommendations. Gary Bernhardt's Boundaries talk. The ZeroMQ guide and writings by Pieter Hintjens for Conway's Law thinking. Software Engineering at Google and Ousterhout's Philosophy of Software Design as books worth reading. This one is a good companion piece to the Nygard article since both are really about the intersection of architecture and organization.

Next, a post from Google's testing blog on Code Review Responses. The gist is say more. When you respond to a code review comment, a one-word reply like Done or Fixed can leave the reviewer guessing about how you actually addressed the issue. The post walks through four scenarios where extra context adds a lot of clarity. When the code change doesn't fully explain the solution. When you made a design trade-off that isn't self-evident. When an offline discussion influenced the outcome. And when there are multiple ways to address the comment and you chose one over others. The recommendation is simple. Ask yourself whether it's completely obvious from the code change and comment thread how you addressed the comment. If not, add a brief note about the why or how. Creates a cleaner historical record, and reviewers will thank you.

Finally, an article from Nordic APIs comparing MCP versus CLI for Agentic AI. The piece sets up Peter Steinberger's claim that the best tool for AI agents has been on their desktop for 50 years, referring to the CLI. But then it benchmarks the two approaches side by side. According to a Smithery study running 756 benchmark tests, native MCP had a 91.7 percent success rate calling the GitHub REST API versus 83.3 percent for CLI. MCP used 28.8k tokens compared to 82.9k for CLI. Median latency was 10.4 seconds versus 24.9 seconds. The key finding is that MCP is great for efficiently performing complex tasks where the agent needs to find and use the correct tool. CLI can approach MCP-level performance when the agent is provided with API descriptions and a search tool. And for local tools like git, docker, or ffmpeg, CLI is the native surface and MCP has no business replacing it. But for remote services, especially large internal APIs with zero training data, or for security-sensitive workflows, a typed agent contract beats forcing every model through raw shell syntax. The conclusion is yes and, not either or. Both have their place depending on the use case.

That's episode 784. A few threads connect across today's articles. The tension between speed and understanding shows up in several pieces, from cognitive debt to the juniors who can ship but not explain. The question of architecture and how org incentives shape it runs through both Nygard and matklad. And underneath a lot of it is the simple idea that metrics are dangerous, whether it's token counts, lines of code, or PR volume. Easy to game, hard to align with actual value.

We'll be back with more tomorrow.

The Road More Traveled — Michael Nygard
Build Long-running AI agents that pause, resume, and never lose context with ADK — Google Developer Blog
Tokenmaxxing is super dumb — InfoWorld
AI is creating a generation of developers who can't debug their own code — The New Stack
Burnout and Cognitive Debt — O'Reilly
Learning Software Architecture — matklad
Code Review Responses: Add Context When It Counts — Google Testing Blog
MCP vs. CLI: Which Is Better for Agentic AI? — Nordic APIs