# Slow Software: The Case for High-latency Systems Development

A July 2026 SIGOPS blog post by Irene Y. Zhang, who works on ultra-low-latency systems (Demikernel, Cornflakes, Capybara). Her argument runs against the grain of her own field: for the most critical infrastructure, development should be slow on purpose. Friction that once came for free is now missing, and she wants to put some of it back deliberately.

## The coupling that broke

Systems building used to be slow because it had to be. Low-level work was tied to hardware that had to be physically built and deployed. Deploying systems software meant shipping disks, rebooting machines, or replacing whole systems. And writing large systems in assembly or C meant implementation complexity set the pace on its own.

Those barriers produced a rough correlation Zhang thinks mattered: the more software depended on a system, the more effort its construction demanded, and the larger the blast radius of a failure, the more time naturally went into preventing one. Importance and development time moved together.

Over twenty years the barriers came down one by one. Hyperscalers deploy hardware continuously. Cloud-hosted software ships weekly or faster. AI writes systems code without the friction of basic tools. The result is that the importance of a piece of software is now fully decoupled from the time it takes to build it. The same push toward AI gets applied evenly to testing infrastructure, network routing, datacenter management, and operating systems — code with wildly different consequences on failure, developed at the same speed.

## Why this bites for systems specifically

Zhang's concrete case is consistency. Distributed systems rely on guarantees from a storage layer beneath them, and those guarantees are often weak, poorly documented consistency models that an AI cannot reason about correctly without the storage system's entire codebase in context — a codebase that may not be available and is itself changing. So the model edits code in a way that violates a consistency assumption, and the programmer, not holding that assumption in their head either, waves it through. Nothing looks wrong until the wide blast radius takes down every service that trusted the broken one.

Her analogy: we happily use things made fast and cheap (processed food, IKEA) and also want some things that aren't (fruit and vegetables, roads and bridges). The problem is we usually can't tell the two apart until something goes wrong — a health problem, a collapsed bridge. Software has the same trap, and no good way to separate the critical infrastructure from everything else before it fails.

## The proposal: friction as a feature

The fix she floats is a "slow software movement," modeled on the slow food movement. The point isn't to slow all development. It's to identify the important infrastructure, where slower development is a feature rather than a bug, and re-couple importance to build time. More dependencies on a piece of software means more effort should go into it; more impactful a failure means more effort should go into avoiding it.

Experienced engineers already make this call by instinct — she cites Mark Russinovich on knowing which code to read and which to skip, and his pitch for mentorship to pass that judgment on. But Zhang thinks the intuition doesn't have to be learned the slow way. In place of the natural impedance that's gone, she'd introduce artificial barriers into the development environment: deliberate friction that gives a programmer skin in the game before they commit to something important. The costs of fast systems building are real; her core move is to make those costs visible while the code is being written, not only later when it breaks. Writing it fast up front just defers the pain — and lands it hardest on younger programmers who'll maintain it.

She is explicit that this isn't anti-AI. AI is good for prototyping and for tedious, repetitive code — build scripts, test harnesses, evaluation frameworks, trying five caching algorithms without hand-writing each. That code has a small blast radius, so it should be fast. The distinction is blast radius, not tooling.

## The research angle

The same erosion hit systems research itself. Prototyping used to be expensive, so an idea worth building was usually worth publishing. Now prototypes are cheap, and conferences are flooded with poorly considered submissions — researchers implement first and submit, offloading the hard question of whether the idea is any good onto reviewers. That's like judging from an architectural model whether a building will still stand in decades of bad weather. Experienced reviewers can sometimes make the call, but the shift moves the hardest part of research from students to reviewers and burns the reviewers out. Zhang wants a throttling function to replace the one that prototyping difficulty used to provide, plus research into judging systems on maintainability and practicality, not only performance and generality.

## Where this sits

The argument rhymes with several pages here. [[peril-of-laziness-lost]] makes the mirror-image point from the individual angle: [[bryan-cantrill|Cantrill]] says LLMs lack the productive laziness that finite human time forces, so unchecked generation bloats systems — Zhang says the same about the systems layer and proposes reinstating the missing constraint by design rather than hoping it reappears. [[credibility-as-slop-test]] argues the countermeasure to cheap plausible output is a human-sized artifact the author must personally vouch for; Zhang's artificial barriers are the systems-engineering version of the same friction-as-gating idea. [[agentic-coding-fatigue]] describes friction the operator feels involuntarily as decision fatigue, where Zhang wants friction imposed intentionally at the point of highest consequence. And [[no-silver-bullet-llms]] supplies the quantitative backstop: the DORA and CircleCI instability signals are what "wide blast radius, developed too fast" looks like in the aggregate.

The unresolved part is the mechanism. Zhang names the shape of the fix — artificial barriers, a throttling function, maintainability as a first-class review axis — but concedes she doesn't have the specifics, only the belief that the systems community has re-established its practices before and can again. The Lobsters submission drew no comments, so there's no counterargument to weigh yet.