Seroter's Daily Reading — #764 (April 15, 2026) — Seroter's Daily Reading

Listen: https://blossom.nostr.xyz/b19489491bc18b0d1294876c04170e2a3bc3acb8b52199ba1a9d01bfc0d2e62b.mpga

Episode 764, April 15, 2026. Here's what caught my eye today.

Let's start with something near and dear to every developer who has ever shipped an API: documentation. A piece from Ibrahim Diallo on the idiallo blog asks the question most of us dance around: How Do We Get Developers to Read the Docs His argument lands hard: most documentation fails because it tries to serve two completely different audiences at once. There are the consumers of your API who want to scan it like a menu, find what they need, copy the example, and leave. Then there are the maintainers who need to understand why you made every weird decision, why that field is nullable, why you make two calls to get orders. These are fundamentally different jobs and mixing them into one document serves neither. His fix is elegant: write in layers. Use collapsible sections so consumers get the surface level, the quick answer, while maintainers can drill into the implementation notes and historical context behind a toggle. Think of it like a good error message. A great one doesn't lead with the stack trace. It tells you what went wrong first, then offers the details for those who need to dig. The goal isn't completeness. It's transferring the right information to the right person at the right moment.

Here's something a little unsettling. Reporting from AI discovers bugs faster than teams can respond covers the fact that AI is now discovering security bugs faster than development teams can respond to them. AI models are scanning codebases and in some cases generating working exploits in less than a day. One example that jumps out: a vulnerability in OpenBSD that sat undiscovered for twenty-seven years, now found by AI tools. The Wall Street Journal has been covering this angle and the concern among security folks is real. The same tools that help defenders find flaws lower the barrier for attackers too. Open-source projects with small maintainer teams are feeling the pressure most. The volume of AI-generated reports is hard to manage, false positives add to the burden, and user expectations have shifted. When bugs are found faster, users expect fixes faster, and that's not always realistic for volunteer-driven projects. The result is a growing gap between the rate of discovery and the rate of response, what some are calling security debt. The answer clearly can't be to slow down bug discovery. It has to be responding better.

On the Google blog, a new text-to-speech model called Gemini 3.1 Flash TTS is making noise. It's their latest TTS model delivering what they claim is improved controllability and expressivity, their most natural and expressive model yet according to the press materials. On the Artificial Analysis TTS leaderboard, which captures thousands of blind human preferences, 3.1 Flash TTS pulled an impressive Elo score of 1,211. It's rolling out in preview for developers via the Gemini API and Google AI Studio, for enterprises on Vertex AI, and for Workspace users through Google Vids. I'm thinking about what better AI voice generation means for learning experiences. Imagine being able to consume content in your language and vibe of choice, not just what the voice actor recorded.

A wonderfully geeky piece on Passive-Aggressive Events in event modeling from event-driven.io. Yes, you read that right. The author draws a parallel to how we communicate in real life. When someone says "the milk ran out" or "heads up, the coffee machine is empty," the formal communication says they're reporting a fact. But the real intention is to trigger an action. It's passive-aggressive and toxic in human communication, and the same anti-pattern shows up in event-driven systems. The problem is when you publish an event and you always expect a single consumer to take a specific next step and send back a particular response. That's not an event, that's a command. Events are for broadcasting information you don't know who will consume. Commands are for when you want something specific done and you expect it to be accepted or rejected. If you have an ordering system that publishes an OrderConfirmed event and expects payment to happen, inventory to start, and notification to go out all as a predictable sequence, you're not doing event-driven architecture. You're doing passive-aggressive architecture. The fix is to be explicit. Use commands like RecordPayment or InitiateShipment for your critical path and save events for the parts that should happen but don't block everything if they fail. A good coordinator or saga pattern makes this explicit. Treat your messages as a communication contract and model their flow in a way that shapes your actual organizational communication. Ask yourself next time, should this event really be a command?

Chrome Skills: Getting Started with Google Cloud examples is a feature I keep seeing mentioned and a piece from Romin Irani on Google's cloud blog gives a solid walkthrough. The idea is you can save custom instructions for the browser to follow whenever you need a hand. Think of a Skill as a tiny specialized tool you build once and use on any web page that's too long, too confusing, or too cluttered. You access it through the Gemini side panel in Chrome, type a forward slash, and pick your skill. Chrome automatically looks at the page you're on and does the work. Romin walks through creating a Google Codelab Analyzer skill that summarizes codelab content into executive summary, tech stack requirements, learning outcomes, and complexity check. He also shows a GCP Release Notes Timeline Tracker skill for digesting release notes into key updates and product trends. You can create skills from scratch, save prompts that work well as reusable skills, or add from the existing registry. Skills save to your Chrome account so they sync across your devices. This makes a lot of sense to me. Persistent, reusable AI assistance that adapts to your browsing context rather than generic prompting.

A piece from Andreessen Horowitz on AI pricing wars that had some counterintuitive insights. The core argument is that competing on price isn't actually necessary for most AI app companies. Large enterprise buyers are typically already deploying multiple AI tools for the same use case. Not because they can't decide, but by design. Redundancy is policy. They don't want to rely on a single vendor for critical workflows. AI apps are still maturing, performance fluctuates, hallucinations happen, outages occur. So they hedge. This means the buyer you're worried about losing to a cheaper competitor may have already preferred you because you're better, and they probably have a budget for both of you. The winning tool is rarely the cheapest. It's the one they can't imagine removing. The piece also has sharp advice on pricing units. Per-outcome models make price comparisons much harder because you're not being compared on cost per seat but on cost per result. And their fifth insight hit me: the real long-term price war isn't with competitors, it's with your customer's engineering team. As inference costs drop and model APIs become easier to integrate, the internal cost of building a custom solution approaches the cost of a third-party subscription. At that point, the conversation changes. The defense is differentiation that's genuinely expensive to replicate internally: deep workflow integration, continuous model improvement, domain-specific training data, dedicated customer success. Scale buys time. That depth earns loyalty.

Speaking of agentic AI, Google's developer blog announced subagents in Gemini CLI. This is a feature that lets you delegate complex tasks to specialized expert agents that operate in their own separate context windows with custom system instructions and curated tools. Your main session stays fast and focused while intermediate work goes to subagents. Gemini CLI ships with several built-in ones including a generalist, a CLI help expert, and a codebase investigator for exploring codebases, mapping architecture, and root-cause analysis. You can also create custom subagents using simple markdown files with YAML frontmatter where you define the name, description, tools, and model. One powerful capability is parallel execution. If you need to research five different topics or refactor several distinct components, Gemini CLI can dispatch multiple agents in parallel. You invoke them explicitly using the at-agent syntax in your prompts. The whole point is keeping the primary agent focused on overall goals and decision making while subagents handle the specialized work without cluttering your main context.

And finally, a piece from Stephane Moreau on blog4ems about why great teams can't be copied. His insight cuts through the noise: most engineering managers carry around a ghost team. The team they worked on five or ten years ago where everything clicked, no ego, blameless retros, decisions made in ten minutes that now take three meetings. They've spent every job since trying to get back there and it never quite works. The reason has nothing to do with new people being worse or the company being too big. It's that the kanban board, the lack of standups, the open Slack channels were outputs of trust, not inputs. Copy the outputs onto a team that hasn't earned the trust yet and you get the cargo cult version. It looks the same from the outside and feels nothing like it from the inside. Process is scaffolding for trust you don't have yet. When trust is there, you can take the scaffolding down and the building still stands. When it isn't, the scaffolding is all you've got. Building great teams isn't about adopting the rituals of ones you've admired. It's about doing the slow, unglamorous work of building trust from scratch.

That's today's batch. See you tomorrow.