select navigate esc close

Seroter's Daily Reading — #781 (May 11, 2026)

Seroter's Daily Reading·

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

Source: Seroter's Original Post


Seroter's Daily Reading episode 781, recorded May 11, 2026.

Seroter kicks things off this week noting he spent part of his weekend fighting the urge to just jump in and build something with AI. Instead, he actually read the Dart documentation and used AI to clarify things he didn't understand. He calls it a better way to learn. That's a good instinct worth cultivating.

Let's dig in.

Starting with a piece from O'Reilly on The Best Risk Mitigation Strategy in Data? A Single Source of Truth. The argument is straightforward: organizations accumulate data risk in three main ways. First, accuracy gets compromised when the same metric is defined differently across Tableau, Power BI, Python notebooks, and whatever else is in the stack. Revenue looks different depending on which dashboard you open. Second, governance becomes a nightmare when access controls are scattered across a warehouse, three BI platforms, shared drives, and cloud storage buckets, each with its own permission model. Third, change management fails silently when a metric definition changes but only some of the places that reference it actually get updated. The CFO says to exclude trial customers from ARR. Three months later, someone discovers the Excel file still has the old logic. The piece argues the semantic layer addresses all three by centralizing metric definitions in one place. When ARR is defined once, it's defined everywhere. Governance moves from the dozens of systems to the semantic layer itself. And when change happens, it propagates automatically. The key insight is that the semantic layer doesn't eliminate risk, it shrinks the surface area that needs managing. For AI-driven analytics, this matters even more, since AI tools need governed, contextualized data to produce trusted outputs.

Speaking of data governance at scale, there's an uncomfortable piece from Google Threat Intelligence on GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access. This one is worth reading slowly. The GTIG report covers several vectors. On mobile, a malware family called PROMPTSPY can capture biometric data to replay authentication gestures, then uses invisible overlays to block the victim from uninstalling the app. The malware can even receive commands via Firebase Cloud Messaging to relaunch itself if the device goes inactive. Beyond that, threat actors are using LLMs to perform reconnaissance at scale, generating organizational hierarchies for phishing targets, identifying hardware and software environments before crafting tailored exploits. More sophisticated actors are deploying agentic frameworks, autonomous tools that can run multi-stage security tasks like vulnerability scanning and subdomain enumeration without constant human oversight. On the information operations side, GTIG notes actors from Russia, Iran, China, and Saudi Arabia producing political content, with growing adoption of AI-generated voice cloning. The report doesn't show breakthrough capabilities yet, but the tooling and workflows are getting more mature. Seroter says to feel anxious reading this and then do something about it. Fair.

At the other end of the comfort spectrum, there's a profile of Yum Brands' tech chief on building its 'AI backbone.' from CIO Dive. Yum has been at this for a while, PizzaNet took the first online restaurant order thirty-two years ago, but the digital transformation really accelerated around 2019 when only 1% of Taco Bell sales were digital, compared to nearly 70% today. Dausch's point is simple: you cannot do AI stuff well if your fundamentals are busted. The company spent years consolidating a fragmented data estate, building Byte by Yum as an AI backbone behind ordering, point of sale, kitchen delivery, inventory, and other core systems. It now runs in more than 35,000 restaurants across 150 countries. Their internal AI strategy has three legs: drive innovation and productivity, grow customer acquisition and retention through AI, and simplify restaurant operations to improve unit economics for franchisees. Dausch's reminder is worth quoting: AI is just a tool. They focus on delivering great food at great value with great service. That's the business.

On the infrastructure side, Google announced Cloud Storage Rapid: Turbocharged object storage for AI and analytics, a turbocharged object storage offering aimed squarely at AI and analytics workloads. For training trillion-parameter models or running inference at global scale, storage can become the bottleneck. GPUs sit idle waiting on data reads. Checkpoint writes stall. You're paying for compute that isn't doing useful work. Rapid Bucket delivers up to 20 million queries per second with sub-millisecond latency, and 15 terabytes per second of aggregate read throughput from a single zonal bucket. Google claims 50% reduced blocked GPU time and 2.5 times faster data loading for multi-modal training runs, plus 5 times faster checkpoint restores and 3.2 times faster checkpoint writes compared to traditional object storage. These are the kind of performance numbers you should be demanding for AI workloads today.

Shifting to the human side of AI-assisted engineering, there's a presentation from InfoQ on Leadership in AI-Assisted Engineering by Justin Reock of DX on leadership strategies for this new reality. The data is noisier than you might expect. DORA research shows modest positive impacts from AI adoption: 7.5% improvement in documentation quality, 3.4% improvement in code quality, 3.1% faster code reviews. But when DX broke the data down per company, the results were all over the place. Some organizations saw more than 20% gains in developer confidence, while others saw more than 20% decreases. The average hides the full story. Reock points to clear AI policies and giving engineers time to learn as the two strongest predictors of positive outcomes. Top-down mandates, by contrast, correlate with decreased psychological safety and people gaming the system. The key insight is that AI adoption follows a learning curve: initial adoption actually decreases both quality and productivity before moderate to heavy use brings things back above baseline. Leaders need to manage for that dip. The message is to frame AI as a force multiplier, not a replacement, and to tie adoption to employee success and skill development.

Also on the tooling front, Google released a Ship code within minutes with the Gemini CLI DevOps Extension that aims to ship code to Google Cloud with a single natural language prompt. The three-tier system combines AI skills that instruct the agent how to think, a Model Context Protocol server that provides the hands to actually manipulate cloud resources, and a local RAG knowledge base for verified architecture patterns. The workflow includes a pre-deployment secret scan to catch leaked credentials before they reach the cloud, application analysis to automatically containerize if needed, and a conversational pause to clarify deployment parameters before pushing live. It's a concrete example of how CI/CD tooling is being abstracted as we offload more work to AI agents.

There's a Harvard Business Review piece on decision-making in fast-growing companies, but the full text wasn't available in the research.

On the incentive alignment front, there's a sharp piece from Engineer's Codex on Tokenmaxxing, Promomaxxing, and Misaligned Incentives in Tech. The term tokenmaxxing refers to the practice of maximizing the number of tokens consumed when working with AI, treating high usage as a proxy for productivity. The problem is that anything measured becomes a target, and smart engineers optimize for the measure rather than the outcome. Meta created an internal leaderboard tracking token consumption, and engineers predictably gamed it by running scripts that burned millions of tokens with zero productivity gain. The leaderboard was eventually shut down. The piece draws a parallel to what it calls promomaxxing at Google, where engineers manufacture complexity to justify promotions because the system rewards difficult work rather than simple, effective work. The real issue is the input-output-outcome chain. More input does not reliably produce more output, and more output does not reliably produce positive outcomes. Shipping a feature is output, but it may hurt retention if it just annoys users. The calculus has changed with AI, but the misalignment problem remains. The piece notes that tokenmaxxing is excellent for rapid exploration and throwaway work where the goal is knowledge. Running seven experiments instead of guessing at three is genuinely valuable. The lesson is to think carefully about whether you're measuring the right thing.

On the infrastructure reliability front, Gergely Orosz at the Pragmatic Engineer has a detailed breakdown of why The Pulse: AI load breaks GitHub – why not other vendors?. The short version: GitHub is experiencing around 85% uptime over the last ninety days, meaning parts of the service are down for two to three hours per day on average. There was a data integrity incident where squash merges produced incorrect commits when merge groups contained more than one PR, effectively losing commits in over two thousand affected pull requests. Mitchell Hashimoto of HashiCorp publicly quit GitHub, writing that almost every day recently has an X in his personal outage journal. GitHub's CTO attributed the problems to AI agents generating far more load than expected, and the company has had to redesign for 30 times today's scale rather than the 10 times it originally planned for. The uncomfortable question is why other vendors serving similar workloads are not experiencing comparable failures. Vercel, Linear, Railway, Sentry all keep up with record growth. GitHub is simultaneously migrating from its own data centers to Azure while dealing with eighteen years of accumulated tech debt and four thousand employees. It wasn't prepared for the load spike, and it shows.

On a related theme, there's a piece on Why Open Source Maintainers Are Done With AI Slop. The core argument is that open source ran on trust, not just code. The friction of creating a meaningful pull request used to signal that the contributor understood what they were submitting. AI removes that friction, and the work transfers to the maintainer. A low-quality AI pull request saves the contributor time but costs the maintainer hours of reviewing correctness, architecture, and intent. The piece documents several pressure points: GitHub's reliability problems are pushing projects like Ghostty to leave the platform. Godot maintainers were overwhelmed by AI-generated PRs earlier this year. Projects like curl and Node.js have had to gate their security bounty programs, with curl officially ending its program due to an explosion of AI-generated vulnerability reports. Node.js now requires a minimum reputation score for submissions. The point is not that open source is dying but that the old model of open contribution is breaking. Code can remain public while the contribution path becomes stricter. A project can let everyone read and fork while requiring maintainer-approved issues before accepting pull requests.

Finally, GitLab announced what it's calling GitLab Act 2, a restructuring and strategic repositioning for the agentic era. The company is reducing its country footprint by 30%, flattening management layers, reorganizing R&D into roughly sixty smaller teams with end-to-end ownership, and wiring internal processes with AI agents. The strategic thesis has three core beliefs: software will be built by machines directed by people, the agentic era multiplies demand for software as the cost of production collapses, and consequential engineering work remains with humans. On the architectural side, GitLab is betting on machine-scale infrastructure since agents open merge requests in parallel, trigger pipelines around the clock, and push commits at rates no human team ever did. Git itself wasn't designed for that load. They're reengineering the underlying infrastructure for agent-rate work as the default, with agent-specific APIs so machines can act as first-class users rather than bolted-on consumers of human-shaped interfaces.

Across all these pieces, a few themes surface. Data governance and semantic layers matter more as AI amplifies both the value and the risk of bad data. The incentive structures around AI adoption are fragile and easy to game if you're not careful about what you measure. Infrastructure built for human-scale workflows is straining under agent-scale load, and some platforms are handling it better than others. And open source, as a contribution model, is being forced to evolve because AI has disrupted the trust economics that once protected maintainer attention.


Sources

  1. The Best Risk Mitigation Strategy in Data? A Single Source of Truth
  2. A Cognitive Fitness routine for Software Engineers
  3. GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access
  4. Yum Brands' tech chief on building its 'AI backbone.'
  5. Cloud Storage Rapid: Turbocharged object storage for AI and analytics
  6. Leadership in AI-Assisted Engineering
  7. Ship code within minutes with the Gemini CLI DevOps Extension
  8. How Fast-Growing Companies Can Make Better Decisions
  9. Run your Gen AI Functions quicker and (up to 90%) cheaper in BigQuery with Gemini Context Caching
  10. Tokenmaxxing, Promomaxxing, and Misaligned Incentives in Tech
  11. The Pulse: AI load breaks GitHub – why not other vendors?
  12. Why Open Source Maintainers Are Done With AI Slop
  13. GitLab Act 2