since.dev No paid content found

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.

Repository impact analysis is the step between "a dependency changed" and "here is the code that needs to change." It maps an external change — an API move, an SDK update, a deprecation, a provider change — to the specific call sites in your repository that depend on the old behavior. You need it when a dependency you don't control ships a change, because your code didn't change but everything under it did. The output is not a fix; it's a scoped list of affected code plus the evidence to justify each item.

Impact analysis vs. monitoring vs. repair

These three get conflated, and the confusion causes teams to either over-trust a dashboard or skip straight to a patch they can't verify.

Monitoring without impact analysis produces alerts nobody acts on. Repair without impact analysis produces patches you can't defend in review. Impact analysis is the layer that makes both useful.

How to trace a dependency change to affected code

The workflow below follows the sequence Since.dev describes: connect a repository, see what changed, find the affected code, review a supported repair. The first three steps are impact analysis proper.

1. Detect the change and pin it to a version

You need the change as a discrete, dated fact, not a vague sense that something moved. In Since.dev's illustrative example, a scheduled check finds a release and its official migration guide:

• Previously observed: 19.0.0 at 09:00
• Latest observed: 20.0.0 at 10:15
• Migration guide: send → messages.create

The version pair and the timestamp are what make the finding checkable later. Without them you're reasoning about "the latest SDK," which is a moving target.

2. Locate the call sites that use the changed surface

This is the core of impact analysis: connecting a documented change to the calls that use it. For an endpoint move like /v1/messages → /v2/messages, you're looking for every place your code references the old path or the old method name — for example src/integrations/messages.ts.

Two things make this tractable rather than a grep exercise:

• Typed changes. When the change is expressed as a typed difference (a method renamed, a field removed, a signature changed), you can match it against your code's usage rather than guessing from prose release notes.
• A documented source. A change tied to an official migration guide gives you a defined before/after to search for. An undocumented behavior shift gives you nothing to match on.

3. Assess the blast radius

Not every affected call site carries the same risk. Sort what you found:

• Direct callers of the changed API — these break or behave differently.
• Transitive users — code that consumes the output of a direct caller, which may need adjustment even though it never touches the dependency.
• Test and fixture code — often the largest count and the lowest risk, but it will fail CI if ignored.

The blast radius is what tells you whether this is a one-line patch or a migration with a plan.

4. Keep the evidence with the finding

Impact analysis that can't be re-checked is just an assertion. The evidence to retain:

• The version pair (previously observed → latest observed) and the observation time.
• The upstream source — the migration guide, changelog, or contract that documents the change.
• The observation's health — when it was recorded and whether the source is still valid.

Since.dev's verification model reads recorded evidence rather than performing a fresh fetch, which means a check returns the observation as it was captured, not a live re-query. That distinction matters: it tells you whether you're looking at current world state or a snapshot, and it lets an agent check its assumptions against the latest recorded observation before acting.

Common failure points

Stale observations. If the recorded version is 19.0.0 but upstream is at 20.0.0, your impact analysis is describing a world that no longer exists. Always confirm the observation time against the change you're analyzing.

Untyped changes. A prose release note saying "improved messaging" gives you nothing to match against your code. Impact analysis degrades to manual reading, and false negatives (missed call sites) become likely.

False positives. A rename that matches a string in an unrelated file, or a deprecated endpoint still used intentionally behind a feature flag, will show up as affected when it isn't. This is why the output is a review list, not an automatic edit — the affected-code list is a hypothesis your review confirms or rejects.

Confusing "affected" with "broken." A deprecation notice means the code still works today. Impact analysis tells you what will need attention, which is different from what is failing now.

How impact analysis feeds into a repair

Once you have the affected call sites and the evidence, the repair step is small by design: a focused patch that traces the supported upstream change to the affected code, with the upstream evidence staying attached to the repair. In Since.dev's workflow, that becomes a draft PR that runs your existing CI, and revisions happen on the same PR — you request a revision and review the updated patch.

The division of labor is the point: Since.dev prepares supported patches and draft PRs, tests run in your repository, and your CI makes the final call. Impact analysis is what makes that handoff reviewable instead of a black box — you can see which code was flagged, why, and against which version.

What to check before you trust an impact analysis

• Is the observed version current, and when was it recorded?
• Is the change backed by a documented source (migration guide, contract, changelog)?
• Are the affected call sites listed with file-level specificity?
• Does the blast radius distinguish direct callers from transitive and test code?
• Can you re-run the check and get the same evidence?

If all five hold, you have an impact analysis you can act on. If any are missing, you have a notification — useful, but not yet a decision.

GitHub maintenance is the ongoing work of keeping a repository healthy as everything around your code changes — not just editing your own files. The practical core is a four-step loop: detect an external change (API, SDK, package, or model), find the code it affects, prepare a small supported fix, and review it through your existing CI. Since.dev describes exactly this loop: it turns supported API, SDK, and model changes into repair PRs, on the premise that "your code didn't change. Everything under it did."

Why unchanged code breaks

Your repository depends on things you don't control. When those things move, your code can stop working even though no one touched it:

• An API endpoint is deprecated or moved (the site's example: /v1/messages → /v2/messages).
• An SDK ships a new major version with a changed call signature (illustrated as send → messages.create).
• A package release changes behavior, or a provider changes a contract.

Because the break originates outside your repo, the maintenance work isn't "write new features" — it's "notice the external change, trace it to the affected code, and apply a focused fix."

The detect → impact → repair → review workflow

Since.dev lays this out as a four-stage path from outside change to inside fix:

1. Detect — a scheduled check finds a release and its official migration guide. The site's illustrative example shows a previously observed version 19.0.0 at 09:00 and a latest observed 20.0.0 at 10:15.
2. Impact — find the code the change touches (e.g. src/integrations/messages.ts).
3. Repair — prepare a small, supported fix as a draft PR.
4. Review — your CI runs, and you make the final call.

The output is deliberately narrow: "a small, supported fix," not a rewrite. The site frames the result as "small patch. Clear evidence."

What a repair PR actually contains

A repair PR is a draft pull request that carries the fix plus the reasoning behind it. Two properties matter for maintenance:

• It uses your existing CI. Draft PRs run through the checks you already have in place, so a repair is validated the same way any other change is.
• The evidence travels with the fix. Upstream evidence — the migration guide, the observed version change — stays attached to the repair, so a reviewer can see why the patch exists.

If the first attempt isn't right, you can request a revision on the same PR and review the updated patch, rather than opening a new one.

Verifying external facts before you act

A maintenance decision is only as good as the fact behind it. Since.dev's verification angle is "world state": external facts, versions, and provider conditions that an agent or a person can check before acting.

The mechanism is worth noting: verification reads recorded evidence, without a fresh fetch. So a check like example-sdk.version = 19.0.0 can come back valid, changed (the observation differs — e.g. now 20.0.0), or unknown. When it returns changed, you get evidence to review rather than a silent assumption. When it returns unknown, treat that as a gap to resolve, not a pass.

What to check when a dependency change breaks your build

Use this as a triage list:

Where this fits in GitHub maintenance

Traditional maintenance covers your own code, issues, and PRs. Dependency-driven maintenance adds a second track: watching the APIs, SDKs, packages, and models underneath you, and turning their changes into reviewable repairs. Since.dev's supported sources span npm, GitHub, PyPI, Rust, OpenAPI, and RubyGems, and its stated goal is "less chasing changes, more moving forward."

The division of labor is explicit: the tool detects, traces, and prepares; your CI and your final call decide what merges. That keeps maintenance reviewable and keeps the judgment with your team.

A software repair PR is a draft pull request that patches code affected by an upstream change — an API, SDK, or model update — rather than by anything you edited yourself. Since.dev describes the trigger plainly: "Your code didn't change. Everything under it did." The tool watches supported dependencies, traces a detected change to the code that uses it, and prepares a focused patch that runs through your existing CI. It applies when the change is one of the supported sources and the affected code can be traced to a call site; unsupported changes or indirect usages that the trace misses still need a human.

The workflow, step by step

Since.dev lays out four stages in its illustrative workflow:

1. Spot the external change. A scheduled check finds a release and its official migration guide. The example shows a package observed at 19.0.0 at 09:00 and 20.0.0 at 10:15, with a migration guide noting send → messages.create.
2. Find the impact. The tool locates the code the change touches — for instance, an endpoint moving from /v1/messages to /v2/messages and the call in src/integrations/messages.ts.
3. Prepare a repair. A small, supported fix is drafted as a patch.
4. Review. The draft PR runs your checks; the final call is yours.

The output is a draft PR, not a merge. Your CI runs in your repository, and you review the patch before anything lands.

What a repair PR contains

Since.dev states that "upstream evidence stays with the repair," so the reason for the patch is visible alongside it rather than in a separate ticket.

What to verify before merging

• Affected call sites. Confirm the patch covers every place the changed API, SDK, or model is used — including indirect usages the trace may not have caught.
• Test results. The draft PR uses your CI, so treat a green run as necessary but not sufficient; check that the tests actually exercise the changed path.
• Whether the change still holds. Since.dev's verification reads recorded evidence without a fresh fetch, so an observation can be stale. Its example shows a version check returning valid, changed, or unknown — if the observation differs from what your agent or code assumes, review the evidence before acting.

Common failure modes

• Unsupported changes. Only supported sources produce repair PRs; anything outside that set needs manual work.
• Stale observations. Verification reads recorded evidence, so a check can reflect an older state than the live one.
• Missed indirect usages. A patch scoped to traced call sites may not cover code that reaches the dependency through another path.
• Assumption drift in agents. If an agent acts on a version or provider condition that has since changed, the repair PR is not the fix — the assumption is.

The practical test for whether a repair PR is worth adopting: if your maintenance load comes from dependencies changing under stable code, and those changes fall within supported sources, a draft PR with evidence and your own CI is a reviewable starting point rather than a blank page.

OpenAPI-generated API documentation is reference documentation that is produced automatically from an OpenAPI description file rather than written by hand. You write (or generate) a machine-readable specification of your API — endpoints, parameters, request bodies, responses, schemas, and auth — and a documentation tool reads that file and renders a browsable, often interactive reference site. The spec becomes the single source of truth; the docs become a build artifact.

This differs from manually written docs in one fundamental way: with hand-written docs, the prose is the source of truth and the API is described separately. With spec-driven docs, the API description is the source, and every page, table, and code sample is derived from it.

How the workflow actually runs

A typical spec-driven documentation pipeline has five stages:

1. Author or generate the spec. You either write an OpenAPI document by hand (YAML or JSON), or generate it from code annotations, framework metadata, or a design-first editor. Design-first means the spec is written before implementation; code-first means it is extracted from existing code.
2. Validate and lint. The spec is checked against the OpenAPI schema and against style rules — consistent naming, required descriptions, no undocumented 4xx responses, no orphaned schemas.
3. Bundle and transform. Multi-file specs are combined, $ref pointers are resolved, and the document is optionally split into per-tag or per-version outputs.
4. Render. A documentation tool converts the spec into HTML: an endpoint list, a sidebar of operations, parameter tables, response schemas, and a "try it" console.
5. Publish and version. The rendered site is deployed, and each API version gets its own snapshot so consumers can read docs matching the version they call.

Steps 2 through 5 are usually automated in CI. If the spec fails validation, the docs build fails — which is the point.

Spec-driven vs. hand-written documentation

The practical conclusion most teams reach: generate the reference, write the guides. Reference material is repetitive and mechanical, which is exactly what generation is good at. Conceptual explanations, migration notes, and tutorials carry judgment that a spec cannot express.

What you get out of the box

Generated reference pages commonly include:

• An operation list grouped by tag or path, with HTTP method and path.
• Parameter tables showing name, location (path, query, header, cookie), type, required flag, and description.
• Request and response schemas rendered as expandable trees, including nested objects and arrays.
• Authentication details pulled from the securitySchemes section.
• Interactive request consoles that let a reader send a real call from the browser.
• Generated code samples in several languages, derived from the same schemas.
• Multiple output formats, such as a static site, a single HTML file, or a mock server.

Because all of these come from one document, changing a field name in the spec updates the parameter table, the schema tree, and every code sample at once.

Where spec-driven documentation breaks down

Generation is not free. The trade-offs are real:

Spec quality becomes documentation quality. A field with no description produces a table row with an empty cell. A vague summary produces a vague heading. Tools can enforce presence of descriptions via linting, but they cannot enforce that the description is useful.

Customization has limits. If you need a page that does not map to an OpenAPI concept — a conceptual overview, a pricing explanation, a comparison of two endpoints — you write it outside the generator and link to it.

Not everything is expressible. Webhooks, streaming responses, long-polling behavior, and complex multi-step flows are awkward or impossible to describe fully in OpenAPI. Those need prose.

The spec can go stale. If the spec is maintained separately from the implementation, it drifts just like hand-written docs. The mitigation is to generate the spec from code, or to test the implementation against the spec in CI.

Interactive consoles need care. A "try it" button that hits a production API with real credentials is a security and rate-limit problem. Point it at a sandbox, or disable it.

Deciding whether to adopt it

Adopt spec-driven reference documentation if most of these are true:

• Your API has more than a handful of endpoints, or changes frequently.
• You ship client SDKs or code samples in more than one language.
• Multiple teams consume the API and need a consistent, always-current reference.
• You already have, or are willing to maintain, an OpenAPI description.

Stay with hand-written docs, or a hybrid, if:

• Your API is small and stable, and the reference fits on one page.
• Your documentation is mostly conceptual and contains little endpoint-level detail.
• You cannot commit to keeping the spec in sync with the implementation.

A reasonable middle path: generate the reference from the spec, and hand-write the getting-started guide, authentication walkthrough, and error-handling page. Link the two directions so readers can move from concept to endpoint and back.

A minimal starting checklist

1. Produce one valid OpenAPI document for a single API version.
2. Add a linter with rules for descriptions, operation IDs, and error responses.
3. Wire the docs build into CI so a failing spec fails the build.
4. Render the reference and review it as a reader, not as the author.
5. Write the two or three conceptual pages the generator cannot produce.
6. Version the published docs alongside the API version.

The core idea is simple: describe the API once, in a format both machines and humans can read, and let the reference documentation fall out of that description. Everything else — tooling, hosting, interactivity — is a detail on top of that decision.