What Is Self-Healing Software and How Does It Repair Dependency Changes?

Self-healing software, as Since.dev describes it, watches the dependencies behind your code and turns supported upstream changes into repair pull requests. The premise is stated plainly: "Your code didn't change. Everything under it did." So the repair targets the layer beneath your code — an API that moved, an SDK that released a new major version, a deprecated endpoint — rather than your application logic.

This is not autonomous production mutation. The output is a draft PR that runs through your existing CI, with a human making the final call. If you're looking for a system that silently rewrites and deploys code, that's a different category. If you want the detection and the first draft of the fix handled for you, this is the shape of it.

The detect → impact → repair → review loop

Since.dev's own workflow illustration breaks into four steps:

1. Spot the external change. A scheduled check finds a release — the example shows a package moving from 19.0.0 to 20.0.0 — along with its official migration guide.
2. Find the code it touches. The system traces the change to the affected code in your repository (the example points at src/integrations/messages.ts).
3. Prepare a small, supported fix. A focused patch is drafted, not a broad rewrite.
4. Review. Your CI runs, and you decide whether to merge.

The key word in step 3 is supported. A repair is tied to upstream evidence — a migration guide, a documented API change, a recorded observation — rather than generated from a model's general sense of what looks right.

What "supported" means in practice

The example in the source material is concrete: an endpoint moves from /v1/messages to /v2/messages, and the migration guide says send becomes messages.create. The repair connects that documented change to the calls that use it. The evidence stays attached to the repair, so a reviewer can check the reasoning rather than trust it.

That's the main distinction from generic AI code generation. A generic model might produce a plausible-looking patch with no traceable source. A supported repair carries the upstream change that justifies it.

What gets monitored

Since.dev lists the dependency surfaces it watches:

The scope is "supported sources" — the platform is explicit that coverage is bounded, not universal. Anything outside that set won't produce a repair.

The verification layer for AI agents

A separate piece of the model is aimed at agents rather than repositories. Before an agent acts, it can check its assumptions against the latest recorded observation — what Since.dev calls "world state": external facts, versions, and provider conditions.

The illustration is a version check:

• example-sdk.version = 19.0.0 → valid
• The recorded observation changes to 20.0.0 → changed
• The agent gets evidence to review rather than acting on a stale assumption

One detail worth noting: verification reads recorded evidence, without a fresh fetch. That means the check is fast and consistent, but its accuracy depends on how recently the observation was recorded. A stale record produces a confident but outdated answer.

Practical limits and failure points

• Unsupported sources produce nothing. If a dependency isn't in the supported set, there's no detection and no repair.
• Stale observations mislead. Both the repair path and the agent verification path depend on recorded observations being current. The source itself flags "check observation time and source health" as part of verification.
• Patches still need review. The draft PR is a starting point. Your CI and your judgment are the gate — the source describes the final call as yours.
• Small patches, by design. The repairs are described as "small" and "focused." A change that requires restructuring your integration rather than adjusting a call may fall outside what a supported patch can do.

How to decide if this fits

Self-healing software in this sense is worth evaluating if your maintenance burden comes from upstream drift — SDK majors, endpoint deprecations, provider changes — rather than from your own feature work. The value is in the detection and the first draft, not in removing review.

It's a poor fit if your dependencies are mostly unsupported sources, if you need changes deployed without human review, or if your integration changes tend to be architectural rather than call-level.

The honest test is to connect a repository and watch one real change go through the loop: does the detected change match what you'd have found yourself, does the patch land where you'd have written it, and does the attached evidence let you review it quickly? That tells you more than any description of the category.