Seroter's Daily Reading — #796 (June 2, 2026) — Seroter's Daily Reading

Listen: https://blossom.nostr.xyz/49219745f115c08ce6c0ce6442ed21f5856251f0a90b382e472a368321e3ad14.mpga

Seroter's Daily Reading, episode 796. June 2nd, 2026.

Big news from Stockholm today — more customer conversations, and the team is in final rehearsal mode for a big event happening there tomorrow. Seroter also mentions wrapping up a five-hour dinner, and that their social battery is, quote, "sub-zero." That's very relatable. Anyway, let's get into it.

Starting off with a report from Wiz on the state of SDLC security in 2026. This one has a downloadable PDF full report behind it, so we'll link to it in the show notes. The core theme is how software reuse, automation, and AI are reshaping risk across the software development lifecycle. That's a big topic right now — every team is reusing more dependencies, automating more pipelines, and shoving AI agents into more parts of the process. And all three of those things introduce new attack surface in ways that aren't always obvious until something breaks. Worth a read if you're responsible for supply chain security or developer tooling.

Next up, a piece from TechCrunch on coders who are now refusing to work without AI tools. The headline frames it as something that could come back to bite them. And sure, there's a risk of over-reliance on any tool. But Seroter makes a good point in the comments — a few years ago, you would have refused to code without an IDE, or insisted on having a cloud server instead of a bare metal box. These are productivity tools, and once you've worked with them, going back is genuinely painful. That's a normal human response to better tooling, not a character flaw.

From Google, a look at how the Gemini team used the same AI tools they were announcing at I/O to actually build the event. They talk about moving faster than ever, prototyping in real time, blending human artistry with experimental technology. The showcase example is a short film called "Timmy TPU" — a creative project that would've been out of reach just a year ago. The takeaway Seroter highlights is that creative teams everywhere should be using these tools, applying their own ideas on top of them and producing output that would've seemed impossible recently. When it's done right, the output is amazing on its own, and as a viewer you stop thinking about how it was made. That's the shift — from "how did they do that?" to just "that's great." And that shift is the opportunity.

A geekier piece now from Chris Siebenmann's blog, looking at some impressive additions to the Go language server for code navigation. If you're deep in the Go ecosystem and you live in an LSP-enabled editor, there are some thoughtful new capabilities worth knowing about. Siebenmann walks through what's been added, and if Go tooling is part of your daily workflow, it's worth your time.

Then we've got an article from The New Stack that's really a sponsored piece from VMware Tanzu, but the underlying argument is solid. It's about the DIY platform trap — the idea that engineering teams, in their effort to reduce toil, end up building a mountain of automation. Scripts on top of blueprints on top of orchestration workflows, layered tooling, GitOps, infrastructure, and they call it a platform. But the piece argues this isn't actually a platform — it's complexity wearing a better outfit. And the real cost is that automation doesn't maintain itself. The team that wrote it moves on, context fades, nobody remembers the edge cases, and when something breaks, you're doing archaeological excavation of your own infrastructure to figure out what the original team was thinking. Trading one problem for another. The article's pitch is that a pre-engineered PaaS handles the integration, the opinions, the lifecycle management, and the operational model so you don't have to. Whether or not you buy the vendor pitch, the underlying observation about automation debt is real. And Seroter's takeaway is sharp — the rule of thumb is that you should only build things that are true differentiators for your business. Everything else, buy or inherit.

Moving on to Google Cloud, where they introduced a feature for GKE called standby buffers. The problem this solves: when you have a sudden traffic spike, your auto-scaling takes time to spin up new nodes, and meanwhile your pods are sitting unscheduled. Historically, you've had to either over-provision preemptively and pay for capacity you're not using, or accept slow scaling under load. Standby buffers are a third option — the system maintains warm nodes in an active buffer for immediate scheduling, and a separate standby buffer that refills from cold starts in the background. The claim is you can get pod scheduling latency down to around 30 seconds on resume, or even one second if you size your active buffer large enough to cover initial spikes. And it costs a fraction of full over-provisioning. Available for GKE clusters running version 1.36 and up.

Then from the Google Cloud blog, a piece on why test-driven development with agents is so helpful for security. This one is from Aron, and it was behind a Cloudflare challenge page when we tried to fetch it, so the full article text isn't available in the research. But the title and context tell you enough — can TDD be a security and stability gate for your AI coding agent? That's a genuinely interesting question as more teams hand off substantial coding tasks to autonomous agents. If the agent writes tests first, it forces a kind of explicit specification of expected behavior before code is generated, which is a natural constraint on what the agent will produce. It's the same principle as TDD for human developers, but with a twist — the agent can generate a lot of tests quickly, which means you need to think carefully about what you're actually specifying. Worth a deeper read if you can get past the bot protection.

Guillaume Laforge on his blog has a piece about iterating on frontend design using Google Stitch and Antigravity CLI. And Seroter calls this the biggest change that AI has made for their own work — suddenly being able to work on parts of the stack, like the frontend, that were previously inaccessible. Laforge walks through a real example: he used Stitch, Google's AI-powered UI design tool, to generate a new look for the Groovy Web Console starting from a screenshot of the existing design and a natural language prompt. After a few iterations, he had something that looked like a VS Code-like interface. He exported it as a zip, fed it into Antigravity CLI, and used that agent to integrate the new design into the project, update Cypress tests, and handle the Git merge. He describes it as working with a productive and knowledgeable co-worker. The key insight is that these tools are making frontend work accessible to people who aren't frontend engineers — which is a real unlock for solo developers or backend-focused teams.

Then a piece from O'Reilly Radar on getting a good return on AI investments. Seroter notes that there's a lot of anecdotal feedback floating around about AI in software teams, but this one brings receipts — meaning actual data, actual numbers. Worth reading for anyone trying to make the business case for AI tooling or trying to evaluate whether your current investment is paying off.

And finally, another Google Cloud piece — this one is a developer guide to Gemini Enterprise and A2UI integration. A2UI is an open protocol for agent-driven interfaces, and the core problem it solves is this: most agent frameworks return strings, which is fine for simple text answers but falls apart for anything with structure — multi-turn slot filling, picking from a list of options, spatial information. You end up with long bulleted lists that the user has to parse and copy back. The solution A2UI proposes is that instead of returning text or HTML, the agent returns a JSON payload describing a UI — a tree of components like Cards, Buttons, ChoicePickers — with the data model separated out. The key properties are that it's declarative, not executable, so a remote agent can't inject arbitrary code through the UI widget. It's streaming-friendly, because it's a flat list of small JSON messages that can be painted as they arrive. And it's framework-agnostic — the same payload renders through Lit, Angular, Flutter, or native mobile. In Gemini Enterprise specifically, the renderer is built in, so you just build your A2A endpoint and the A2UI cargo it emits, and GE handles the rest. It's a nice pattern for anyone building agentic applications where you want the agent to produce structured, interactive output without giving it direct access to the DOM.

That's episode 796. A couple of threads running through today's set — AI's role in creative and frontend work keeps coming up, and the idea that tooling doesn't just help you do what you were already doing faster, it changes what you're able to do at all. And the platform engineering piece ties into that too — automation is seductive, but it has a long-term cost that doesn't always show up in the original business case. Worth keeping in mind as you scale out your own stacks.