Seroter's Daily Reading — #837 (August 3, 2026) · Seroter's Daily Reading

Listen: https://blossom.buildtall.systems/75cc367dd2918d561b12f7bef2f4eb0e8ce10035a77d620e4fec2f7440bcd922.mpga

Episode 837 for August 3, 2026.

Let's dive in.

First up, Google has a substantial piece on Batten Down Your Packages: Mitigation Guidance for Supply Chain Compromise. The post catalogs notable incidents from 2025 and early 2026 and lays out a comprehensive set of defensive measures. The headline finding is that traditional software supply chain compromise remains rare compared to what's observed in the open source ecosystem, but the incidents that do occur are increasingly consequential, with the ByBit cryptocurrency theft at $1.4 billion being the standout example. What's valuable here is the actionable framework Google provides. It covers cataloging assets and maintaining a Software Bill of Materials, but goes further into what it calls an Action Bill of Materials, or ABOM, which inventories every third-party pipeline vendor and development utility linked to your container image inventory. The post also covers moving away from static long-lived tokens toward GitHub Apps and short-lived OIDC tokens, enforcing cooldown controls on newly published packages, disabling install scripts by default, and deploying tools like Google's OSV Scanner to continuously monitor dependencies. The post also highlights newer native platform protections that have shipped recently: Dependabot's three-day cooldown on version updates, PyPI's server-side immutability that rejects new uploads to releases older than 14 days, and npm v12 disabling lifecycle scripts by default. These represent a meaningful shift in how the major registries are hardening themselves against supply chain attacks.

This episode's second piece is a related one from RedMonk's Kyle Holterhoff, making the case that modern software registries are no longer just distribution systems, they're trust services in Modern Software Registries are a Trust Service. The post traces a year of supply chain incidents across npm, PyPI, RubyGems, crates.io, and others, and finds something interesting: all of these registries converged on the same security primitives, trusted publishing, short-lived credentials, provenance, essentially at the same time, because they were responding to the same real attacks. PyPI alone processed over 2,000 malware reports in 2025, with two-thirds handled within four hours. But Holterhoff draws a sharp distinction that I think is the key insight here: trusted publishing answers the question, did this artifact come from the pipeline authorized to publish it? It does not answer, is the thing my pipeline built actually safe to run? Shai-Hulud and Mini Shai-Hulud carried valid provenance because the attackers had taken over the CI workflows themselves. The registry's short-lived credentials were issued correctly to a build system that was already hostile. The xz-utils backdoor predates every mechanism discussed in this post, and Jia Tan signed the poisoned releases himself. Identity can be compromised upstream of the signing step, which means provenance can launder malicious output rather than catching it. That's the gap between attribution and assurance, and it's where registries are still working.

Let's shift gears. A piece from Zapier profiling Damian Guzman, a solo lawyer in Oakland who rebuilt his practice around Claude and Zapier MCP in What happens to a lawyer's business model when AI makes him 5x faster. He's now producing five times the output. The workflow runs hourly, scanning Gmail, logging tasks in his system of record, and drafting NDAs and contract reviews before he even opens his inbox. By the time he sits down, roughly half the work is already done. Over the past 90 days alone, he ran nearly 11,000 MCP tasks. But here's the obvious problem: if a task that used to take five hours now takes one, and you bill by the hour, your revenue on that work drops by 80%. He's wrestling with flat-rate pricing, taking on more clients, and leaning into consulting, and he's also watching in-house legal teams get more efficient and need him less. He raised a question he didn't pretend to have an answer to: if AI is doing the research memos and first-draft contracts that used to be how junior lawyers learned the job, where does the next generation of lawyers get trained? That's not a Zapier question, but it's the honest version of what five times productivity costs an industry that trains people by having them do the slow version first.

Martin Fowler has an article on the economic benefit of refactoring that speaks directly to the agentic era in The Economic Benefit of Refactoring. He ran an experiment on a 150,000-line Rust application written entirely by coding agents. The data access layer alone grew to over 17,000 lines in a single Rust file. His experimental method was elegant: he had a fresh agent make an identical change to the codebase at each stage of refactoring, measuring token costs to isolate the effect of the refactoring itself. The results were striking. Input tokens dropped from roughly 160,000 to about 27,000, an 83% reduction, because the agent could now read only the relevant subset of files rather than the entire monolithic layer. The counterintuitive point Fowler makes is that refactoring didn't shrink the total codebase much, but it shrunk what the agent needed to read to do future work. The agent was able to successfully identify the smallest subset of files necessary. Randomly cutting a file into smaller pieces wouldn't help as much; even if each file were smaller, the agent would read through many files looking for the relevant code. The ability to find the right files at the right scope is what made the difference. Fowler notes that the refactoring process itself was not smooth. He had to write Python scripts with grep and sed for the mechanical work, the AI was poor at applying refactorings correctly, and it took about eight hours to complete the experiment with one six-hour-forty-minute detour when the agent skipped a step.

A piece from bharath.sh on agent skills caught my eye in the one line 95% of agent skills are missing. He scanned 200 public SKILL.md files and found that 95% of them are missing the "Use when…" activation line. The description field in a skill is what the agent reads to decide whether to load that skill. Most skills describe what the skill is, a helper for writing tests, rather than when it should activate, use when the user adds tests, is looking at a failing test, or mentions coverage. A narrow description misses relevant prompts. A broad description intercepts unrelated work. Both failures produce no error. There's no compiler, no lint check, no editor warning, so this blind spot persists at scale. The Agent Skills specification has been adopted by over 30 tools including Codex CLI, Gemini CLI, VS Code, and Cursor, with around 90,000 skills now available. But without the activation signal, all that scale is undermined by a routing problem.

Amanda Lewis has a piece on building a multi-agent application that ties several threads together in From 'Write a Python Script' to Multi-Agent Mastery: My Journey to Becoming an AI Builder. She built the DORA Songsmith, an application that takes an event description and generates a custom three-minute lyric video. She describes hitting the wall twice before the breakthrough. First, a monolithic Python script approach failed because she had no background in audio-visual application development. Second, she tried to script her way past the temporal limits of early generative media models: Lyria clips that lost harmonic continuity across API calls, Veo clips that produced visual jars with no continuity between clips, and serverless scripts that couldn't handle state persistence across a multi-step render pipeline. The breakthrough came from shifting from writing a script to writing a system manifest, and moving to a multi-agent model where separate agents handled audio consistency, visual continuity, and human-in-the-loop checkpoints, orchestrated through Google's Agent Development Kit. Her advice at the end is to revisit your shelved impossible idea. She waited months on the first attempt; the second attempt took her through the holidays. By the time she got to a working MVP, weeks had become the new years.

HBR has a research piece on how AI agents broaden the scope of knowledge work in Research: How AI Agents Broaden the Scope of Knowledge Work, and the framing is useful. It distinguishes between an AI tool that hands you information to act on versus one that hands you completed work. One returns a tidy summary and a list of links. The other returns twenty minutes later with the spreadsheet built, the chart drawn, and a draft memo attached. The distinction matters because it's not just about doing current work faster, it's about doing different work.

Google has a detailed post on how they build, test, and scale Google Agent Skills in Behind the scenes: How we build, test, and scale Google Agent Skills. The guiding principle is to prefer remote MCP tools whenever possible, falling back to CLI or API calls only when necessary. Remote MCP servers offer tools while also providing built-in auth and IAM governance. Skills are built and evaluated internally first, then exported to public repos through automated rules that strip out internal assets. The CI/CD pipeline validates frontmatter metadata, runs link checkers on every URL, and uses AI-assisted checklists to verify structural patterns. Authors must supply evaluation prompt suites and scoring rubrics, and every new skill is evaluated against a 2x2 matrix measuring accuracy and efficiency. The continuous evaluation runs weekly against the full library to catch regressions, and authors must provide multiple evaluation test cases with prompts and expected outcomes. The key design principle throughout is that every skill must demonstrate a measurable accuracy and efficiency uplift.

Battery Ventures has a thorough piece on how agentic coding is reshaping the software development lifecycle in How Agentic Coding Is Reshaping the Software Development Lifecycle. The core observation is that human-written code acted as a natural rate limiter on the rest of the SDLC. Coding agents remove that bottleneck, and now planning, testing, security, code storage, all of it is fraying at the seams trying to keep up with agentic code velocity. The piece maps this across five areas. On planning, a new class of tools like Linear, Modem, and Intent Lab is emerging to help teams prioritize and scope at AI speed. On build and review, enterprises like Ramp, Stripe, and Coinbase are already building their own internal software factories to orchestrate coding agents. On security, the volume of AI-generated code is outpacing human review capacity, making AI-assisted security review necessary rather than optional. On CI/CD, sandboxes have become essential, and companies like Modal, Daytona, and E2B are building for agent-driven build pipelines. On code storage, GitHub's infrastructure was designed for human commit velocity, and companies like Pierre Computer Company and East River Source Control are building version control primitives that match agentic velocity. We're in the first innings, most code is still written by hand, but the direction is clear.

Google has a piece on GKE Agent Sandbox that shows how to dramatically increase agent density per node in Do more with less: How GKE can reduce your cost per agent by 75%. Running OpenClaw agents in microVMs on a standard GKE node hit a wall at 61 agents before reliability dropped. Migrating to GKE Agent Sandbox with gVisor instead of heavy guest operating systems pushed that to 88 agents, a 44% improvement. Adding GKE Pod Snapshots to checkpoint idle agents to persistent storage, freeing CPU and memory, pushed it further to 274 agents on the same node. The cost-per-agent reduction was over 75%. The caveat is that different agents have different latency requirements, so oversubscription requires understanding your workload patterns.

Sean Goedecke has a piece on giving and taking credit in big tech companies in Giving and taking credit in big tech companies. The counterintuitive point is that sharing credit is often the best way to accumulate it. In large organizations, managers can't assess technical performance themselves, so they quietly ask trusted engineers. Those engineers are spread across layers, and they quietly and informally judge the value of your work. When you give other people credit on your projects, those people become invested in your success and naturally talk the project up. A project you jealously guarded reflects well on nobody. The same logic applies to blame. Competent engineers can assign blame pretty much wherever they want when complex failures occur. A project where the credit is concentrated in one person is automatically blamed for complex problems, because nobody is incentivized to defend it.

Google has a post on the borderless Lakehouse, which is about enabling AI agents to query data across clouds without moving it in The borderless Lakehouse: Bring AWS, Databricks and Snowflake data to your AI agents. Built on the Iceberg REST catalog, it connects AWS Glue, Databricks Unity Catalog, and Snowflake Horizon so that BigQuery and Managed Spark can query data in place. For AI agents, the important piece is the Knowledge Catalog semantic layer, which translates raw schemas into business terminology, so agents understand what data means rather than just what it contains. Google reports that customers using BigQuery's built-in AI functions are seeing 230x reductions in token consumption, because precise business context delivered through the catalog prevents unnecessary reasoning loops.

Google also has a post on Chrome security in the AI era in Stronger with every update: How we're making Chrome and the web safer in the AI Era. Memory safety is the central focus, with expansion of MiraclePtr to neutralize use-after-free vulnerabilities and spanification, which migrates legacy C++ pointer-and-size constructs to compiler-enforced std::span types. Chrome is 97% of the way toward compiling cleanly with strict unsafe-buffer warnings. For the long term, Chrome is deploying Rust strategically to replace high-bug-density components like parsers, codecs, and font stacks, and exploring writing the browser's top-level UI in HTML, CSS, and TypeScript. The Chrome commit queue also runs continuous LLM-powered semantic analysis to catch compound security risks that traditional static analysis misses before code lands.

RedMonk's Stephen O'Grady has a piece analyzing whether AI is writing open source code in Who's Writing Open Source Code?. He examined commits across 15 critical open source projects and found that less than 1% of surveyed code was demonstrably written by AI. The robots have not taken over. The distribution was highly uneven: two projects accounted for 73% of AI-marked commits, and roughly half of the projects had no AI commits at all. The growth signal is real, but adoption is asymmetric, driven by localized factors like maintainer enthusiasm, tooling, and project policy. The transparency question looms large. As the cost of generating code drops and barriers to contribution fall, the incentive to submit AI-generated code without disclosure grows. O'Grady's takeaway is that transparency into code origin should become more important culturally and as etiquette in open source communities.

Google's Open Source Programs Office has a retrospective on how open source practices are adapting to an AI-first world in Adapting open source practices to an AI-first world: A retrospective on 2025. Roughly 10% of Alphabet's full-time workforce actively contributed to open source in 2025, a ratio that has held steady for five years and scales with headcount. Google's top projects by contributor activity include community-led projects like LLVM, vLLM, Envoy, and Rust alongside Google-initiated projects like Kubernetes and gRPC. On security, Google launched CodeMender, an AI agent for vulnerability patching that upstreamed 72 security fixes in its first six months, and OSS Rebuild, which verifies build provenance by rebuilding packages and semantically comparing results against upstream artifacts. The overall posture is worth noting: Google describes itself as a participant in open source ecosystems it depends on, not as a steward or savior.

Finally, TypeScript 7 shipped with a Go-based native compiler delivering roughly 10x performance improvements on real codebases in TypeScript Just Got 10x Faster by Not Being TypeScript. VS Code went from 125 seconds to under 11 seconds for a full build. Sentry dropped from roughly 140 seconds to under 16. The gains come from native execution eliminating JavaScript's startup and JIT overhead, and from Go's parallel processing allowing parsing, binding, and type checking to run concurrently. The interesting question is whether a language can be made faster by no longer being written in that language. The answer appears to be yes, when the underlying execution environment is the bottleneck rather than the semantics. Go fit because it is procedural, garbage collected, supports cyclic data structures, and its programming style aligned closely with how the existing TypeScript compiler was already structured. Anders Hejlsberg noted that a Rust rewrite might have been possible, but faithfully porting the existing design in Rust's ownership model was not practical. The TypeScript language, syntax, and type system are unchanged. The engine running underneath is different, and that is fine.

That is episode 837. A big reading list this week. The threads connecting most of these pieces are supply chain integrity, the economics of agentic work, and the ongoing tension between identity and assurance, between attribution and actual safety. I will be back with more on Thursday.

No Nostr signer detected