What is continuous maintenance?
Updated November 8, 2026
On this page
CI, CD and CM
Continuous integration and continuous delivery both start from a change you made. Continuous maintenance starts from a change someone else made: a release, a deprecation notice, a shutdown date. Your code didn't change, and it still breaks.
| Step | Starts from | Does |
|---|---|---|
| Continuous integration | A commit or pull request | Builds and tests the code you changed |
| Continuous delivery | A merge to the main branch | Ships the tested code |
| Continuous maintenance | A change outside your code | Finds the code it hits and opens the fix for review |
Why it needs its own step
Dependencies change on their own schedule. A package removes a function in a major release. A provider sunsets an API version. A cloud platform stops patching a runtime. None of these touch your repository, so CI has nothing to run and CD has nothing to ship.
AI models make the gap sharper. Providers retire model IDs on fixed dates, often a different date on each platform that serves the model, and a request that names a retired model fails. The retirement calendar lists each date with its source.
Coding agents widen it again. An agent learned its packages and models when it was trained, so it writes against versions and model IDs that may have changed since, unless something tells it what changed.
What continuous maintenance covers
- Breaking releases: a function, class or option removed, renamed or given a new signature.
- API deprecations and sunsets: an endpoint, field or version a provider is turning off.
- AI model retirements, matched to the platform your code calls: the provider's own API, Azure, Amazon Bedrock or Google Vertex AI.
- Runtime and CI image end of life: language versions, base images and hosted runners.
- Security advisories on the versions your lockfile pins.
How to practice it
- Know what your code uses: the manifests and lockfiles, plus the model IDs, API calls and runtime versions written in code and config.
- Follow the sources: package registries, provider deprecation pages and end of life schedules, read as they change.
- Match each change to the lines it hits, on the platform the code actually calls.
- Fix before the date: a pull request with the change, tested by your CI and reviewed by a person.
- Tell your coding agents what changed since they were trained, so new code doesn't bring back what is retiring.
What it looks like this season
Each of these is a change outside your code that breaks code nobody touched. Each guide shows where the change hides in a codebase and what to move to.
- OpenAI turning off the GPT-5 family and o3 on its API: the shutdown and its replacements.
- Claude Sonnet 4.5 retiring, with its undated alias: how to move off it.
- Newer Claude models refusing temperature and top_p in the same request: the parameter change.
- .NET 8 and .NET 9 leaving support: the move to .NET 10.
- PostgreSQL 14 reaching end of life: what changes and when.
How to tell it's working
- Changes are found while there is still notice left, not after something fails in production.
- Fixes arrive as reviewed pull requests, so nobody patches a shutdown in a hurry.
- New code from people and agents stops naming models and versions that are already retiring.
- The gap between a change being announced and the fix being merged gets shorter.
Agentic maintenance
Agentic maintenance is continuous maintenance done with coding agents. The agent asks what changed since it was trained before it writes, checks the code it touches, and fixes arrive as pull requests a person reviews.
Since.dev gives agents three tools for it over MCP: whats_changed, check_code and fix_code. The MCP reference shows how to connect one.
Where Since.dev fits
Since.dev does continuous maintenance. It tracks packages, AI models, APIs and runtimes as they change, each change with its source, finds the exact lines a change breaks in your code, and opens the pull request that fixes it, for a person to review. Nothing merges or deploys. Try it on any public repository with the free scan.
Questions
Is continuous maintenance the same as Dependabot?
No. Dependabot opens pull requests for newer versions and known vulnerabilities. Continuous maintenance also covers changes that aren't a version bump, such as an API sunset, an AI model's shutdown date or a runtime's end of life, and the code changes a breaking release needs. Many teams run both.
Does continuous maintenance replace CI?
No. It runs beside CI and CD. Its fixes arrive as pull requests, and your CI tests them like any other change before a person merges.
What is agentic maintenance?
Continuous maintenance done with coding agents: they ask what changed since they were trained before they write, and fixes arrive as pull requests a person reviews.
Related guides
Comparisons
- How to know when an AI model you use is retiringEach provider, and Azure, Bedrock and Google Cloud, sets its own model retirement dates. Where to find them, how to script a check, how to find model IDs.
- Dependabot alternative for breaking changesDependabot keeps versions current for free. It won't say which lines an update breaks, or when a model, API or runtime you use retires. What to add.
How-to
- How to track breaking changes and deprecations in your dependenciesDependabot flags vulnerable and outdated versions, not announced breaking changes. Where deprecation and end-of-life notices appear, and how to catch them.
Put your code on continuous maintenance.
Scan a public repository now, or give your agent one line.
See how out of date your code is.
Tell your agent what changed since it was trained.
claude mcp add --transport http since https://api.since.dev/mcpCodex, Cursor and any MCP client use https://api.since.dev/mcp.