Skip to main content

Posts

AEGIS-CHAOS: From 'Vibe Coding' to Closed-Loop SRE

Aegis-Chaos · Post 1 of 1 · → View on GitHub From “Vibe Coding” to Closed-Loop SRE How zero-trust policies, Git isolation, and math-based budget guardrails let an autonomous agent say “no” — and mean it. Aegis-Chaos: An autonomous SRE control plane with real-time zero-trust guardrails. Most AI coding assistants today operate on trust. You prompt, they generate, and you ship. That works—until it doesn’t. A single destructive command, an uncaught runaway loop, or a stale approval can turn an autonomous agent into a production incident. Project Aegis-Chaos was built to answer a simple question: what happens when the AI says “no”? This post walks through the zero-trust architecture, parallel isolation strategy, math-based budget guardrails, and end-to-end visual verification pipeline that make up our closed-loop SRE control plane—designed for the Google Developer Expert Sprint and built on the Antigravity SDK. The Decla...
Post a Comment
Read more
Recent posts

The Throughput Trap: Benchmarking vLLM on OpenXLA and the Reality of Production LLM Serving

vLLM Systems · DevLab 2026, Deep Dive I was recently invited by the Google TPU team to speak at the OpenXLA Summer DevLab 2026 . This post breaks down our deep-dive evaluation of the matured vLLM + OpenXLA stack, the fundamental engineering mismatches between CUDA and XLA serving paths, and why traditional capacity metrics are lying to you. If you are operating large language models at enterprise scale right now, your platform architecture team is likely staring at a massive infrastructure crossroads: Should we migrate our core serving workloads from GPUs to TPUs? Historically, NVIDIA's CUDA ecosystem was the only serious option for user-facing, low-latency LLM generation. But here in 2026, the economics and infrastructure options have transformed. Google TPUs are highly available, cheaper per chip, and the open-source serving stack built around vLLM and OpenXLA has officially achieved absolute production readiness. Yet, when our infrast...
Post a Comment
Read more

Splitting the Brain to Beat the Clock

Racecraft · Part 3 of 5 · ← Prologue Splitting the Brain to Beat the Clock How a "brake!" lands in 5 milliseconds while a cloud model thinks for five seconds — in the same app, on the same frame, without ever colliding. Two posts in, we have a coach that knows who's driving and what to say. This post is about the only thing that lets it say anything useful: structure. Specifically, the decision to give the system not one brain but three, each on its own clock, with an ironclad rule about which one is allowed to make the driver wait. I call it the Split-Brain engine , and the whole design collapses out of one observation. The three jobs a coach does — react, strategize, prepare — have wildly different deadlines. Trying to serve all three from one code path means the fastest job inherits the latency of the slowest. That's the original sin of every cloud-first coaching app. So I refused to let them share a path. The Spli...
Post a Comment
Read more

Teaching the Coach to Read the Driver

Racecraft · Part 2 of 5 · ← Prologue Teaching the Coach to Read the Driver The best instructors don't coach the car. They coach you , and they figure out who you are in about two laps. Here's how we taught software to do the same. In Part 1 I argued that trust is the only metric that matters, and that it's mostly a latency problem. That's true , but there's a second half I glossed over. The same sentence, delivered at the exact same millisecond, can build trust or destroy it depending on who's listening. Tell a nervous first-timer "brake spike detected, modulate your input" and you've just handed them a stack trace mid-corner. Tell a fast amateur "squeeze the brakes, don't stab" for the tenth time and they'll mute you out of sheer irritation. The words have to match the driver. So before Racecraft can say anything, it has to answer a question a human coach answers instinctively: how good is this person, rig...
Post a Comment
Read more