Continuous maintenance is keeping software current with every change in the packages, APIs, AI models and runtimes it depends on, as those changes ship.
It is the step after continuous integration and continuous delivery. CI tests the code you write. CD ships it. Continuous maintenance (CM) keeps it working while the things under it change.
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.
- November 10: .NET 8 and .NET 9 leave support. The move to .NET 10.
- November 12: PostgreSQL 14 reaches end of life. What changes and when.
- November 30: Claude Sonnet 4.5 retires, with its undated alias. How to move off it.
- December 11: OpenAI turns off the GPT-5 family and o3 on its API. The shutdown and its replacements.
- Already here: newer Claude models refuse
temperatureandtop_pin the same request. The parameter change.
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. One line connects Claude Code:
claude mcp add --transport http since https://api.since.dev/mcp Codex, Cursor and any other MCP client use https://api.since.dev/mcp. The MCP reference shows how to connect each 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 GitHub repository with the free scan. No sign-in.
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.
What was the last thing that broke in your code without anyone touching it? Tell me in the comments.
First published on since.dev.
