Seroter's Daily Reading — #775 (May 1, 2026) — Seroter's Daily Reading

Listen: https://blossom.nostr.xyz/2f1524cdbfa3af519b2903a0786b0ce1acf230633e351e1ada800ae148acc422.mpga

Seroter's Daily Reading, Episode 775, May 1, 2026.

Happy May! I'm expecting another exciting month of tech updates and real-world stories of people learning the best ways to do modern work. Buckle up.

Let's start with something that hits close to home for anyone building data-backed systems. Arpit Bhayani has a piece titled Databases Were Not Designed For This, and it's one of those articles that names an intuition you've probably had but never articulated. The core argument is that traditional database architecture rests on a set of unspoken assumptions that agentic AI workloads systematically violate. These assumptions include: the caller is deterministic, writes are intentional, connections are brief, failures are loud, and the schema is a contract with engineers who speak the same language.

Agents break all of that. They reason their way to queries you've never seen. They hold connections open while they think. They retry in loops. They can write thousands of rows before you get a Slack notification. Bhayani's piece is practical and specific: he lays out concrete patterns for defensively designing your data layer. Use statement timeouts at the role level. Soft deletes everywhere an agent can write, with a deleted_by column so you know exactly which agent deleted what. Append-only event logs for high-stakes writes with idempotency keys so retries don't create duplicates. A dedicated connection pool for agent workloads, sized independently from your human-facing traffic. And here's the one that jumped out at me: role-per-agent-type access, where each agent type gets minimum necessary privileges enforced at the database level, not assumed by the application layer. It's a good read if you're anywhere near production agent deployments.

Speaking of agents and tools, Phil Schmid has a piece on How to correctly use MCP servers with your AI Agents, and the framing is useful. MCP servers aren't dead, but blindly enabling them bloats your context, which means higher cost and worse performance. Schmid lays out two patterns. The first is explicit MCP servers, where you use an @mention in the prompt and the agent resolves, fetches, and injects just those tools for that specific request. Think of it as opt-in. The second is subagent MCP servers, where MCP servers are declared in a subagent's definition and are automatically available at runtime alongside native tools. This is the always-on approach for agents that always need the same tools, like a code reviewer that always needs GitHub access. Schmid also introduces the allowed_tools scoping option, which lets you restrict each agent to just the specific tools it actually needs. Good for least-privilege tool access.

And then we have Lessons on Building MCP Servers from Rui Carmo, who takes a different angle. He's been building MCP servers for a while, and he writes with the kind of grounded frustration that usually means the lessons are hard-won. His central insight is that models don't plan. They look at the conversation, scan the tool list, and grab whatever looks most probable. That's it. So if you want chains that finish somewhere sensible, the server has to make the next call blindingly obvious at every step. Carmo describes several tactics: use a small set of named core verbs and funnel models toward them through get_instructions(). Use consistent naming prefixes so that a model that just called office_inspect naturally reaches for office_patch next. Embed forward breadcrumbs in every tool response, at minimum a next_tools array plus an exact usage string that the model can copy verbatim. Make a discovery tool that returns structured recommendations as data, not prose. And use anchors, not line numbers or byte offsets, because models lose the thread between calls.

There's more in the piece, including a checklist for MCP design that he open-sourced. Worth checking out if you're building toolchains.

Let's shift to product thinking. Marty Cagan and the SVPG team published a Build To Learn FAQ that answers common questions about the product model. If you haven't read the original Build To Learn versus Build To Earn piece, start there first. This FAQ is the follow-up that addresses pushback and confusion.

The piece covers several misunderstandings worth noting. First, the PM is not the decider. Think of a surgical team with multiple specialists, and you defer to whoever is best suited for the particular decision. Second, the PM is not the manager. The product manager is an individual contributor, just like engineers and designers. You are a builder, not a manager. Third, the PM's specific contribution is responsibility for the value and viability of proposed solutions, making sure customers will buy or use the product, and that the solution meets business constraints. The engineers bring deep knowledge of the technology. The designers bring deep knowledge of the users. The PM brings deep knowledge of the customers, the data, the industry, and the business. That's product sense.

One more thing on product: can AI accelerate discovery like it has accelerated delivery? Cagan says yes, but in different ways. In delivery, AI plays an automation and code generation role. In discovery, AI plays more of a prototyping and decision support role. He also notes that developing strong product sense still requires the PM to build judgment over time, and AI can help with that learning.

On the lighter side, the Google Testing Blog has a quick piece called One Map Key, One Lookup about a common efficiency waste in map usage. The pattern is: first checking if a key exists, then looking it up again. That double lookup has a cost, whether it's computing a hash and scanning buckets or performing a log-n traversal. The fix is to perform the lookup once and reuse the result. Bhayani's piece on database patterns earlier had something similar with idempotency keys. The blog covers language-specific idioms: Go's comma ok idiom, Python's defaultdict, C++'s operator bracket, Java's computeIfAbsent. Small waste, but you might be doing it in a tight loop, so worth fixing.

Now for the ROI piece. Research-Driven Engineering Leadership has a deep dive on How can engineering leaders calculate the return on their AI investments, drawing on the DORA team's 2026 ROI of AI-assisted Software Development report. There are several findings worth highlighting. First, AI is an amplifier, not a transformer. It magnifies existing strengths of effective teams and existing dysfunctions of struggling ones. Second, adoption follows a J-curve. Most organizations encounter a temporary productivity drop before exponential value, driven by the learning curve, the verification tax from reviewing AI output for hallucinations, and pipeline adaptation as downstream processes scale to higher code volume. Third, individual effectiveness rose the most in DORA's data, but software delivery instability also rose. Friction and burnout did not meaningfully decrease, suggesting that with AI, friction moves rather than disappears. Fourth, productivity gains are highly context-dependent. Research cited shows roughly 35 to 40 percent productivity gains on simple greenfield tasks but 10 percent or less on complex legacy brownfield code.

The piece includes a DORA sample calculator that yields a 39 percent first-year ROI and an eight-month payback, but only when the value side factors in reinvested headcount capacity offset by an instability tax, and the cost side explicitly budgets a 15 percent productivity drop across the first three months. The killer takeaway is this: AI investment is a systems decision, not a tooling decision. Buying licenses without investing in the surrounding platform, data, and governance simply accelerates the rate at which existing dysfunction shows up in production. That quote is worth sharing with your manager.

Forrester Research has a piece on Google Cloud Next 2026, titled The End Of The AI Pilot Era, and the opening is bold. Thomas Kurian declared the end of the AI pilot era and Sundar Pichai compared the enterprise refrain of last year, can we build an agent, to today's question, how do we manage thousands of them. Google Cloud's answer was a single product story: Gemini Enterprise Agent Platform. They collapsed Vertex AI's agent tooling, Agentspace, the Agent Development Kit, the standalone observability tools, the model registry, and half a dozen other agent-adjacent functions into one unified surface. This mirrors what NVIDIA did with GTC earlier this year, vertically integrated messaging. The compute portfolio expanded with new TPUs, TPU 8t for training and TPU 8i for inference with about 80 percent better price performance. Developer tooling unified around agent-centric workflows. Workspace repositioned around agent-driven intelligence with a unified semantic layer connecting meeting notes, emails, files, and chats into a single graph that agents can query. And an Agentic Data Cloud was introduced as an AI-native evolution of enterprise data platforms, shifting from passive systems of record into active systems of action designed for autonomous agents. Notably, the framing throughout was that agents worked alongside developers, not in place of them.

Gartner research covered by CIO Dive finds that 80 percent of CEOs expect AI to force meaningful overhaul of their operational capabilities. Most CEOs said automation is currently limited to specific tasks, but only 13 percent expect to remain at that level by the end of 2028. One-third said their organizations will use self-learning AI tools in human decision-making, and more than a quarter plan to use AI primarily without human intervention. The shift could force executives to pursue recurring outcome-based revenue models, since agents could disrupt existing intermediated systems or price negotiation processes. The piece quotes a Gartner analyst asking the question many organizations will need to answer: what is the specialty stuff that is left over after we get rid of the drudgery?

On Cloudflare, InfoWorld reports that Stripe Projects now allows AI agents to provision multiple cloud services and manage credentials from a CLI. An agent gets an initial 100 dollars to spend per month per provider, can build and deploy a site, and register the domain. The headline is provocative, agents given the keys to the cloud, but it's a constrained environment with spend limits and OAuth flows. Once guardrails are truly in place, this likely becomes more acceptable and more common.

On the community side, Google announced the 2026 Google Summer of Code contributors. Over 1,100 contributors matched with 184 mentoring organizations from a record-breaking 23,000 plus proposals. The official coding period begins May 25. It's good to see this program still going strong, especially as AI changes the open source landscape.

Harvard Business Review has a piece on The Psychological Costs of Adopting AI that adds an important dimension to the AI ROI conversation. Companies are focused on efficiency and productivity, but there's growing evidence that AI can have negative psychological consequences for employee motivation, which may even cancel out the benefits of AI. This puts already embattled ROI models under even more scrutiny. It's worth reading this alongside the DORA ROI piece from earlier. You can build the financial model, but if you're not attending to the human side of adoption, you might be undermining your own investment.

And finally, Google Developers Blog has a piece on Building with Gemini Embedding 2: Agentic multimodal RAG and beyond. Gemini Embedding 2 is now generally available, and it's the first embedding model in the Gemini API that maps text, images, video, audio, and documents into a single embedding space, supporting over 100 languages. One model handles up to 8,000 text tokens, 6 images, 120 seconds of video, and 180 seconds of audio in a single call. This enables agentic RAG pipelines where an agent can scan hundreds of files or cross-reference disparate PDFs with improved understanding and accuracy. Nuuly, the clothing rental company, used this for an in-house visual search tool that matches photos of untagged garments against their catalog and pushed their match accuracy from 60 percent to nearly 87 percent. That's a significant improvement. The model also supports task prefixes that optimize embeddings for specific use cases like question answering, fact checking, code retrieval, and search results. Supermemory, a vector database for memory, achieved a 40 percent increase in search recall accuracy after integrating the model. Regardless of your media type, you can now use a single embeddings model across your entire retrieval pipeline.

That's episode 775. A lot of AI in depth this week, from defensive database design to MCP server patterns to multimodal embeddings, plus the human and organizational dimensions of AI adoption. See you next time.

Sources

Databases Were Not Designed For This — Arpit Bhayani
How to correctly use MCP servers with your AI Agents — Phil Schmid
Lessons on Building MCP Servers — Rui Carmo
Build To Learn FAQ — SVPG / Marty Cagan
One Map Key, One Lookup — Google Testing Blog
How can engineering leaders calculate the return on their AI investments? — Research-Driven Engineering Leadership
The End Of The AI Pilot Era — Forrester Research
AI agents are forcing enterprises to overhaul their operations — CIO Dive / Gartner
Are we ready to give AI agents the keys to the cloud? — InfoWorld
The Journey Begins: Meet the 2026 GSoC Contributors! — Google Open Source Blog
The Psychological Costs of Adopting AI — Harvard Business Review
Building with Gemini Embedding 2: Agentic multimodal RAG and beyond — Google Developers Blog