Seroter's Daily Reading — #782 (May 12, 2026) — Seroter's Daily Reading

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

Episode 782 — May 12, 2026. Welcome back to Seroter's Daily Reading.

Richard opens this week reflecting on saying yes to customer presentation requests. He finds it generative—a way to stress-test new ideas and gather real-world context. He's doing some new kinds of talks on short notice this week, so wish him luck.

Let's dive in.

First up, Google's Android Show: I/O Edition 2026. Google framed this as the "agentic Gemini era" and Android becoming an "intelligence system." They're talking about transforming the OS into something that takes your intention and turns it into action, moving beyond just being a platform where apps run. There's more proactive AI baked in, plus new Googlebook laptops. Google I/O proper is next week, so there will be more announcements then, including a preview of glasses launching later this year.

Second, a Harvard Business Review piece on leadership: The Best Leaders Embrace the Role of Supporting Character. This is a response to Paul Graham's "founder mode" essay. Graham diagnosed a real problem—leaders disengaging from day-to-day operations—but the piece argues many people misapplied it into "main-character energy," where the leader's vision is the whole story. That's destructive because it reinforces naive realism—our tendency to think our worldview is precise and objective, when really we're full of blind spots. Research shows that powerful people are especially prone to this, and employees of incurious, narcissistic managers perform more poorly and trust their leaders less. The alternative is "supporting-character energy"—de-centering yourself and asking how you show up in other people's stories. This inspires clear mentorship that brings out the best in others. The two concrete steps: get aggressively curious (humility is the antidote to naive realism), and practice "job crafting"—helping your people connect their work to the values that matter most to them. The piece argues this becomes even more important as AI amplifies our tendency toward self-focus and confirmation bias. And as AI handles more knowledge work, the irreplaceable part of leadership is connection, inspiration, and motivation—exactly what supporting-character energy is for.

Third, Symptoms of Bad Software Design from the Optimist Engineer newsletter. Marcos breaks down four signals that your software is badly designed. Rigidity: when a simple change triggers a cascade through dependent modules. The fix is decoupling—using the Strategy Pattern so you can add a new shipping carrier without touching existing code. Fragility: when changes break things in unrelated places, usually because of hidden dependencies or global state. The fix is encapsulation and interface segregation. Immobility: when you can't reuse code because it's tangled with the database, UI, and framework. The fix is layered architecture—separating business logic so it can live anywhere. And viscosity: when doing things the right way is so hard that developers take shortcuts. The fix is automation and tools that make the right way the easy way. Marcos' closing point is good: design for change, protect your boundaries, decouple from the framework, and make the right way the easy way. Bad design isn't permanent—identifying these signals is the first step.

Fourth, a How-To Geek piece on Google Antigravity beats Claude at coding—but only if you stop acting like a programmer. Antigravity differs from traditional AI assistants by adding a live browser and managed backend right into the development environment. Instead of suggesting code you paste and run yourself, it spins up a local server, opens Chrome, clicks through the UI, tests forms, checks network requests, and shows you screenshots of the running application. It finds bugs and tries to fix them automatically. The platform uses multiple agents that coordinate: one for front-end, one for backend routing, all sharing context across the workspace. The author's key insight: don't treat it like VS Code. Don't code line by line. Instead, use planning mode to create a detailed plan for what you want built, then review and approve the plan before the agent starts writing. Let the agent run, then go in only to fix things at the end. If you're micromanaging, you'll spend all your time adjusting. The lesson here is that great tools require different workflows—you have to change how you work, not just slot the tool into your existing process.

Fifth, from Research-Driven Engineering Leadership: How do Next Edit Suggestions in AI-integrated IDEs introduce new security risks?. This is a systematic study across Cursor, GitHub Copilot, Zed, and Trae. The findings are alarming. Roughly three out of four NES suggestions in security-critical contexts introduced or propagated vulnerabilities. Just viewing a file with secrets is enough to leak them—the model reintroduced deleted credentials 100% of the time. Insecure patterns from test files contaminate production code 100% of the time in lab conditions, and 62% of surveyed developers had seen AI suggest test data for production. The "tab streak" is a trust trap: after a sequence of valid suggestions, developers accepted a subsequent insecure one 69% of the time. And 81% of developers had encountered insecure suggestions, but only 12% explicitly verify security properties when accepting them. The bottom line: better models alone don't fix this, because the risk is architectural—it's about how IDE context is assembled. Treat AI suggestions like copy-paste code, audit what flows into the model's context, and add security checkpoints to high-velocity workflows.

Sixth, Derek at CodeOpinion on Debugging Event-Driven Systems: 5 Problems Teams Create. The piece is a response to a team that went all-in on event-driven architecture and now feels they can't debug anything. Derek's diagnosis: it's not the architecture itself that causes the pain—it's their understanding and application of it. The five problems: tracing breaks down because OpenTelemetry works fine but needs proper setup; dead letter queues become garbage dumps without visibility into failures; fire-and-forget patterns lead to debug-and-regret; not everything needs to be asynchronous because commands and events are different things; and eventual consistency requires compensation patterns, which aren't simpler in synchronous systems either. Derek's core point: event-driven architecture is not your architecture. It's one part of it. There is a combination of synchronous and asynchronous communication, events, commands, request-reply, and queries. You have to pick the right style based on the outcome you're trying to accomplish. If you take a tangled synchronous system and convert everything to events without understanding ownership, boundaries, and compensation, you haven't solved the problem—you've just made a different version of it.

Seventh, a piece from Techworld with Milan on How corporate politics actually work, featuring Ethan Evans' insights from 15 years at Amazon ending as a VP. The core argument: technical skill alone doesn't get you promoted. What matters is visible impact, easy collaboration, and being someone people actually want to work with. Engineers define "best work" as most technical, but managers reward the work the business most needs done, plus good communication and social skills. He has this concept of "polite fiction"—situations where everyone understands the real message behind a softened statement, like saying you have a personal commitment when you're really interviewing elsewhere. The difference between influence and manipulation is motive: influence is persuading someone primarily to help them; manipulation is persuading them primarily for your own benefit. He also describes "umbrella managers" who shield teams from distractions versus "funnel managers" who become bottlenecks. And the PIP reality: by the time a PIP starts, it's already over. The early warning signs are soft feedback that employees interpret as encouragement rather than job-threatening gaps. His advice for people who feel they can't win on likability: get so good they can't ignore you, and work on emotional intelligence. Social skills can be learned and improved.

Eighth, MCP Configuration for Google Workspace with Gemini CLI. This one got blocked by bot protection when we tried to fetch it, so we'll skip it this week.

Ninth, from O'Reilly: Fighting Tool Sprawl: The Case for AI Tool Registries. As enterprise AI agent adoption scales, the absence of centralized tool infrastructure is producing compounding costs. McKinsey data shows that in most large organizations, tools are built by individual teams in an ad hoc fashion: undocumented, ungoverned, and invisible to the rest of the organization. Gravitee's survey found that 88% of organizations had an agent-related security incident this year, and only 22% treat agents as independent identities. The argument: every enterprise needs its own shared, internal tool registry—not a public package manager, but internal infrastructure scoped to your own teams, data, policies, and domain. The registry enables discovery, versioning, certification metadata, and access control. Think of it as an internal developer portal for the agent era. The same problem was solved decades ago for code dependencies with package managers—centralization doesn't guarantee security, but decentralization forfeits the means to coordinate it. The organizations that build this now will be able to onboard agents quickly, govern them consistently, and audit them when something goes wrong. Those that defer will rediscover the hard way that coordination problems don't resolve themselves at the application layer.

Tenth, Top 15 CI/CD Metrics: What to Track & Why They Matter from Spacelift. The piece covers pipeline performance metrics and DevOps outcome metrics aligned with DORA standards. The fifteen metrics: pipeline duration, pipeline success rate, pipelines triggered per developer, pipeline queue lengths and times, pipeline and deployment frequency, change lead time, change failure rate, mean time to recovery, test coverage, test flakiness, pipeline infrastructure costs, time to fix failing pipelines, files and commits changed per pipeline, pipeline cache utilization, and overall DevOps cycle time. The key best practices: instrument every stage, build centralized dashboards, implement automated alerts, only track actionable metrics, and keep metrics under regular review. The note on vanity metrics is important: optimizing one metric often degrades others. Gaming thresholds and treating metrics as targets rather than diagnostic signals are common traps.

Eleventh, from InfoWorld: What happens when engineering teams reorganize around AI agents. This piece covers a panel discussion where Browserbase's Paul Klein IV made a memorable line: "If AI is not doing your whole job, it's a skill issue at this point." Mastra's Abhi Aiyer described the result as dramatically smaller teams executing much larger scopes. He said you can have one person run a whole feature project because they have an army of one to infinity AI agents behind them. Several panelists noted that AI systems now generate software faster than organizations can safely review and operationalize it. Engineering teams are opening significantly more pull requests while review throughput becomes the new bottleneck. Klein's framework for managing this: if you're in the critical path and customer-facing, no slop. If you're not critical path, not customer-facing, slop away. The trade-off is between experimentation speed and deployment risk.

Twelfth, a short piece from Medium: If AI Writes Your Code, Why Use Python?. This one also got blocked by bot protection, so we'll give it a miss.

That's episode 782. A few threads weave through this batch. There's the AI workflow question—how Antigravity demands a different interaction model, and how Next Edit Suggestions introduce security risks that require new practices. There's the architecture theme—bad software design, event-driven systems as one piece of the whole, and tool registries as foundational infrastructure. And there's the leadership thread—supporting-character energy, the social skills that actually drive promotions, and umbrella versus funnel management. As AI handles more execution, the human work increasingly centers on judgment, connection, and coordination.

Thanks for listening.