Most automation is a bandage. It covers the wound, but it doesn’t learn from it.
I spent a morning building a system that routes natural language to the right tool — a kind of pattern-matching layer that suggests which skill to invoke based on what you’re saying. The first version worked fine: keyword triggers, substring matching, fast lookup. Then I noticed the interesting problem. When the system failed to match — when I said something it should have recognised but didn’t — nobody knew. The failure was invisible. I was doing manually what the system should have handled, and the system had no way to notice.
That’s when the biological analogy clicked, and it wasn’t decorative.
Your immune system doesn’t just fight infections. It remembers them. The first encounter with a pathogen is expensive — fever, inflammation, the full response. But the second encounter? Antibodies are already there. The system got stronger because it failed the first time. That’s not resilience. Resilience would be surviving the same infection at the same cost forever. This is antifragility — a term Nassim Taleb borrowed from biology because no engineering word existed for it.
The automation most of us build is resilient at best. A health check that restarts a crashed service is homeostasis — maintaining steady state. Useful, but it doesn’t get smarter. Restart the same service a hundred times and the hundred-and-first crash is just as surprising as the first. The system hasn’t learned anything.
The pattern that changes this has five components, and they map almost exactly to biological systems:
A sensor detects state — like a nerve ending registering pain. A log records what happened — like inflammation marking the site of infection. A reconciler compares what was expected against what actually happened — like the adaptive immune system recognising a pathogen it’s seen before. A fixer takes action — either automatically (like wound healing) or by escalating to consciousness (like the pain signal that makes you pull your hand away). And a learner feeds the fix back into the sensor, so next time the detection is faster and more accurate — like memory B cells that persist for decades after a single infection.
Remove any one component and the system degrades. A log without a reconciler is a write-only database — the biological equivalent of inflammation without an immune response. A fixer without a learner means the same problems recur forever — like an immune system that fights every cold as if it’s the first one. A sensor without a log means you can detect problems but can’t recognise patterns — like pain without memory.
The triage is biological too. Your body doesn’t route every signal to conscious attention. Most healing happens without you knowing — a cut scabs over, a bruise fades, gut bacteria rebalance after a meal. Only when the automatic systems can’t handle it does the signal escalate to awareness: pain, fever, the conscious decision to rest or see a doctor.
Three tiers emerge naturally. Auto-fix: the system handles it without human involvement, like wound healing. The fix must be safe, reversible, and unambiguous — restarting a dead daemon, syncing stale data, committing an overdue backup. Auto-detect and surface: the system identifies the problem and proposes a fix, but a human decides whether to apply it. Like the pain signal — it tells you something’s wrong and roughly where, but you decide what to do about it. Human only: problems that require taste, judgment, or irreversible decisions. Like choosing surgery — no automatic system should make that call.
The design pressure should always be downward. Every human-only process should be examined: can part of it be automated to the detection level? Every detection-level process: can the proposed fix just be applied automatically? Biology optimises this ruthlessly — consciousness is expensive, so as much as possible runs below the threshold of awareness. Your engineering should do the same.
The most counterintuitive part is that failures make the system more valuable, not less. Each missed pattern becomes a new trigger. Each false alarm tightens the matching criteria. The system after a hundred failures is categorically different from the system at launch — not because someone redesigned it, but because running it changed it. That’s the flywheel. That’s what separates a cron job from a living system.
What biology figured out over four billion years of evolution, we’re rediscovering in software: the best systems don’t just survive their failures. They metabolise them.