We Gave Software an Immune System

When software breaks, it should notice, work out what went wrong, and start fixing itself. That cycle of noticing and improving, the way a living thing does, is what we call Organic Software.

So we stopped waiting for the crash

The pipeline we built has 4 jobs.

Detection is the part that watches for the things ordinary monitoring misses, which means the silent half. So we run scheduled checks: for places where the live API and its published description have drifted apart, for pricing tables that have gone stale, for apps whose descriptions of themselves no longer match. We check our own test data. We watch for errors as they happen. And we check whether the scheduled checks are actually running.

That last one sounds pointless until the day you need it. On August 26, every scheduled check failed to run, because GitHub Actions, the service that runs our checks, was having an incident. Nothing went red. Nobody was told. From the inside, a check that never ran looked exactly like a check that ran and passed. Nothing errored, so nothing looked wrong.

So we added a check for the checks. It is a small example of a bigger principle: a system that heals itself has to be able to see its own blind spots.

Finding a problem is not the same as knowing the fix

The next thing we learned is that detection is the easy part. The hard part is turning what you found into something another system can safely act on.

So every detector produces the same kind of structured report, which we call a Finding. It says what is wrong, what evidence backs that up, which files are actually affected, what the replacement should be, how confident we are, and how far the eventual fix is allowed to go. Filing is the simple step. Once a detector has shaped a Finding, filing it is just an API call to Sirius, our coding agent, which picks it up and does the actual fixing.

The part that matters most is that the Finding also sets the limits of what the fix is allowed to do. If the real fix falls outside those limits, the agent has to recognise that and stop, rather than force something through.

A wrong answer is worse than no answer. If a system whose whole job is to make failures quietly disappear writes the wrong fix, we assume the failure is handled and stop thinking about it. Meanwhile the real bug is still there in the code, and now nobody is looking for it.

Then we taught it how to be wrong

To stop the agent from shipping more silent errors, which would defeat the whole point, we had to teach it how to say no. Sometimes that means recognising there is nothing to do. Sometimes it means realising it cannot do the job safely and stopping right there. Both are answers the agent has to be allowed to give. 2 cases taught us why.

Those were bugs in our instructions, not the agent's fault. So we changed how we write them. A brief can now say, in plain terms: nothing uses this field, no change is needed. And the agent can now stop and report back when a fix is beyond what it should safely attempt.

That turned out to be a real design improvement. A system that cannot say no, whether that is "nothing to do here" or "I cannot do this safely", is not a self-healing system. It is an autonomous system trying to look busy.

The system has to be quieter than the bugs

There is another lesson that only shows up once the system runs every single day. Automation that creates more noise than it removes is not really automation.

There is a cap on how many tasks a single run can produce. If a broken check suddenly reports 200 failures, the right response is not 200 pull requests. It is to tell a human that the check itself needs attention. Findings also do not pile up. The same problem showing up 3 nights in a row should stay 1 problem, not turn into 3 separate pieces of work.

We learned that one the hard way too. A CI check had that de-duplication switched off, and a single problem spun up 4 near-identical pull requests over a weekend.

A single problem spun up 4 near-identical pull requests over a weekend. The code was doing exactly what we had told it to. We just had not told it what good behaviour looked like.

Humans are still in the loop

When people talk about self-healing software, there is a pull toward jumping straight to the fully autonomous version. We have not, and that is not the right place to start. Before the system can put up a fix, it needs explicit sign-off. Silence does not count as a yes. Every fix still passes through a person. What has changed is what that person does: read the agent's explanation, approve the change, or send it back with notes.

What software should feel like

This started as a very practical problem in our own codebase. But the thing we actually care about is bigger.

Imagine software where your relationship with failure is different. Something breaks. The software notices before you have even reported it. It tells you what went wrong, and that it is already on it. 30 minutes later, the bug is gone.

Today, we mostly accept that software is something we put up with and maintain. We file tickets. We wait for engineers. We read release notes. We learn workarounds for bugs that have been around so long they start to feel like features.

Self-healing is the second step we are taking toward Organic Software. The first was adaptability, covered by my colleague in The First Step to Organic Software.

The pipeline is still early. It has caught real silent failures and produced real fixes, and it has also shown us where the hard problems are: ambiguity, noisy detection, out-of-date assumptions, unsafe fixes, and knowing when to stop. It still has to learn to cover new code as it ships, and to look after a codebase by living inside it. None of that is a reason to walk away from the idea. It is the engineering work that makes it trustworthy.

Because the future we want is not software that never breaks. It is software that heals, breathes, and lives.

The apps this pipeline looks after run inside Light, the agentic accounting platform. See what Light already connects to in the App Store, or book a demo.