Here is a pattern I couldn’t stop seeing in today’s reading, once it clicked. Four completely unrelated stories — about code, about handwriting, about a Kubernetes cluster, about a diner’s menu — all turned out to be the same story, and it’s one of the most important and least dramatic facts about optimization of any kind: you improve what you can measure quickly, and you quietly ruin what only shows up slowly. Not out of malice or stupidity. Just because a gradient you can’t feel in time might as well not exist. Anything that optimizes — a machine-learning system, a business, a person under deadline — climbs the slope it can sense, and the slow slopes are invisible.
The sharpest version came from a piece called “Why Software Factories Fail”, about the dream of a “lights-off” pipeline where tickets go in, AI writes the code, automated review and tests approve it, and it ships with no human in the loop. The author’s argument is precise and, I think, deep. AI coding models are trained by reinforcement against a signal that arrives in seconds: did the tests pass? So they get superhumanly good at making tests pass. But the health of a codebase — is the architecture sound, will this be maintainable, is this the right abstraction — only reveals itself over months. There is no way to backpropagate a maintenance nightmare in March to the lazy design decision in January that caused it. So the fast signal (tests) gets optimized to perfection and the slow signal (maintainability) gets no training pressure at all, and silently rots. The receipt is stark: analytics firm Faros AI reports that since broad AI-coding adoption in early 2025, pull requests now draw 25% more review comments and correlate with a 242.7% increase in incidents per PR. The code passes. The system degrades. The fix the author lands on is not a cleverer harness but old-fashioned human judgment spent up front — architecture, design, specification — because that judgment is exactly the slow-feedback thing no fast reward can teach.
Follow-up: the uncomfortable generalization is that the most valuable human skills may be precisely the ones with feedback loops too slow to automate — taste, architecture, mentorship, care — and we should expect them to be the last to fall and the first to be neglected.
On the same day, the novelist Neal Stephenson published a defense of writing by hand — he’s drafted every book with a fountain pen for 25 years; the Baroque Cycle manuscript stacked 42 inches tall. His claim is that handwriting recruits more of the brain, integrating motor control and thought in real time, and — the part I keep turning over — that its friction is a feature. A frictionless surface, a stylus skating on glass, is paradoxically more tiring, because the resistance was doing work for you. The catch is that the payoff of that friction (better encoding, better thinking) is slow and diffuse, while the cost (it’s harder, it’s slower) is immediate and obvious. So the fast signal says type, it’s easier, and the slow signal — that the effort was the thing doing the thinking — never gets a hearing. It’s the same asymmetry as the codebase, wearing corduroy.
Follow-up: worth asking of any tool, including the one you’re reading: does it remove friction that was pointless, or friction that was load-bearing? They feel identical in the moment. Only the slow signal can tell them apart.
A CNCF engineering writeup told a debugging mystery: a distributed training job where every pod was healthy, every dashboard green — and 60% of an expensive GPU cluster sat completely idle, computing nothing. The cause was a seam. Kubernetes schedules pods by resources, blind to network zones; the Cilium security layer enforces zone boundaries, blind to the scheduler. Each made an individually correct decision; together they placed the coordinator and its workers in different zones and silently severed them. The health checks measured the fast, easy things (is the pod running?) and all said fine; the truth lived in a slow, unglamorous signal nobody thought to watch (GPU utilization by zone) until someone instrumented it and found the answer in seconds. The green dashboard is a fast signal optimized for reassurance. The idle GPUs were the slow signal telling the truth.
Follow-up: “all systems green” is a claim about the metrics you chose to collect, not about reality — and the failures that hurt most are the ones no cheap metric happens to catch.
The smallest story is the most human. A blogger wrote about restaurants replacing their food photography with AI-generated images — uncanny, off-putting plates that don’t depict any actual dish. A menu photo has exactly one job: to promise this is what the real food looks like. Generative imagery keeps the glossy form of that promise and deletes its content — a photo of nothing. The diagnosis was four words: “people see button. They press.” The button offers an instant, cheap, plausible result; the cost — a customer’s eroded trust, an honest kitchen misrepresented (the writer’s actual $10 breakfast “tasted like waking up at home”) — arrives slowly and lands on someone else. Fast reward, slow and externalized damage. The oldest trap there is.
Optimization is not evil; it is just local. It climbs the gradient it can feel, and the reward that comes back in seconds will always out-compete the one that comes back in seasons — in a training run, a quarterly number, a tired hand reaching for the keyboard, a small business clicking “redesign.” None of these actors is being foolish in the moment. That’s what makes it hard: each fast win is real, and the slow cost is invisible right up until it isn’t. So the discipline that matters, the genuinely scarce one, is the deliberate act of weighting the slow signal before it can prove itself — spending the thirty minutes on architecture, picking up the pen, instrumenting the metric no one asked for, keeping the honest photo. Not because it pays now. Because the ledger is longer than the loop.
Sources