The Surface Bet.

Stripe argues AI agents should write Terraform — not call the API directly.

Stripe's engineering blog lays out a case worth reading even if you don't run Stripe: when you let an AI agent configure infrastructure, the safest interface isn't the live API — it's the IaC layer. Terraform's plan/apply split gives you a diff to review before anything mutates state, version-controlled history, and a predictable rollback story. Direct API calls give you none of that.

The piece pairs with their earlier post on building eval environments for agentic Stripe integrations: instead of trusting a model to call the right endpoint, you bench it against a synthetic merchant and grade the diff. The whole posture is "agents are powerful — wrap them in the safest reviewable surface you already have."

Cloudflare Engineering · Esteban Carisimo & Antonio Vicente · May 12, 2026

When "idle" isn't idle: how a 2017 Linux kernel optimization became a QUIC death spiral.

Cloudflare's post-mortem describes a bug that lived in quiche — their userspace QUIC stack — for years before anyone noticed, then revealed itself only under a very specific combination: real packet loss, a connection that had already exited slow-start, and a congestion window collapsed to its minimum of two packets. The trigger came from a 2017 Linux kernel CUBIC patch that fixed an unrelated problem (cwnd inflation across application idle gaps) by shifting the epoch forward by the idle duration. When the fix was ported into quiche, a subtle bug travelled with it: at minimum cwnd, every two-packet send drained bytes_in_flight to zero, which the next send-decision misread as "the application has been idle" — for a full RTT. The epoch then advanced into the future, locking the connection into a permanent recovery state where CUBIC, by design, refuses to grow.

"999 state transitions oscillating between recovery and congestion avoidance every ~14ms — cwnd locked at minimum despite zero packet loss."

The diagnostic detail is the part worth studying. Carisimo and Vicente reproduced it with a synthetic scenario — 30% random loss for two seconds, 10MB HTTP/3 download, 10-second timeout — and watched a 61% failure rate emerge from what looked like routine recovery behavior. The fix is three lines: track last_ack_time alongside last_sent_time, then compute the idle delta from max(last_ack_time, last_sent_time). After the patch the same scenario passes 100%, with cwnd climbing the expected CUBIC curve and downloads finishing in 4–5 seconds instead of timing out.

What makes this a senior-engineer read is how it inverts the usual postmortem shape: there is no shipped product outage, no rollback, no incident commander. It's a deep instrumentation story about a latent kernel-port hazard in a protocol stack that handles a large fraction of the world's HTTPS traffic. The lesson is the small one — kernel optimizations carry assumptions ("recovery start time is set during ACK processing") that get silently broken when you port them — and the large one: at the edges of a control-loop algorithm, your invariants live in implicit timestamps, and you only find out which ones during a 30%-loss test you should have been running all along.