Why Code Maintenance Gets Hard Across Hundreds of Repositories

A framework upgrade may start with one instruction: move every service to the new version. The required change will not be identical in every repository.

Services may use different framework versions, package managers, file layouts, build configurations, and deprecated APIs. One may rely on an internal package from a private registry. Another may have custom tests or a one-off deployment step. Each change has to fit the repository and pass its build and tests.

Then the pull requests have to be reviewed and merged. Someone has to identify owners, route each PR, watch CI, resolve conflicts, answer questions, and track what remains.

Large maintenance projects have both problems: generating valid changes across non-uniform repositories and coordinating the work through merge.

OpsLevel Maintenance Agent handles the work as one initiative. It plans and generates changes for each repository, opens the pull requests, and shows where the initiative is blocked.

The change has to fit each repository

Bulk search and replace works only when every repository uses the same pattern. Most engineering organizations are not that uniform.

Maintenance Agent reads each target repository before generating its change. It can also read context repositories that contain information shared across the initiative, including:

• Internal style guides
• Reference implementations
• Shared type definitions
• Internal libraries and tooling
• Design systems and framework packages

Context repositories are read-only. Maintenance Agent can also access private registries during builds when a target depends on an internal package.

This gives the agent the same references an engineer would check before changing the code. A service that uses an internal wrapper, for example, should follow the wrapper’s supported interface rather than a generic example from public documentation.

Repository context is still not enough to determine how a change should be handled across the organization. The OpsLevel Context Layer adds ownership, dependencies, service criticality, and engineering standards. That information affects scope, review, and risk even when the generated code is correct.

Plans need to account for exceptions

The first plan may miss a repository-specific constraint or an intentional exception. A team may need to exclude one service, use a different migration path for another, or add a validation step before generating changes.

Maintenance Agent lets users refine the plan through chat. They can ask for a change, review the revised plan, and continue from there. Version history keeps earlier plans available for comparison or rollback.

The plan can be corrected before the agent generates changes across the full repository set.

Reviewers need more than a generated diff

A reviewer who did not plan the initiative still needs to understand why the pull request exists and what could go wrong.

Maintenance Agent writes each PR description for that reviewer. It explains what changed, why it changed, and which parts need attention. It does not use the description as a log of the agent’s steps.

Clear descriptions matter when one platform team opens pull requests for many independent service teams. Repository owners should not have to find the original initiative brief before they can review a change.

Valid pull requests still get stuck

A generated change can pass its initial checks and still stall later. A new commit can break CI. The target branch can move and create a conflict. A review thread can remain unresolved.

PR Alerts surface CI failures, merge conflicts, and unresolved threads in the OpsLevel components table and sidebar. The initiative coordinator can see which repositories need attention without opening every pull request or maintaining a separate spreadsheet.

OpsLevel also reports initiative activity across the organization:

• Initiatives run
• Pull requests created
• Pull requests merged
• Success rate
• Estimated time saved

The metrics can be filtered by time period. Each initiative shows estimated time saved and credits used.

The initiative should match the actual scope

Code generation, pull request creation, and notifications can run across the full component selection. A change that affects 200 repositories can run as one initiative instead of four 50-repository batches.

The workflow stays in one place:

1. Define the maintenance task and select the repositories.
2. Add context repositories and access to required private packages.
3. Review and revise the plan.
4. Generate and validate the changes for each repository.
5. Open PRs with descriptions written for the repository owners.
6. Track blockers until the work is merged.

This applies to framework upgrades, infrastructure migrations, configuration changes, deprecated API removal, security fixes, and compliance documentation. The implementation differs by repository; the initiative provides one place to manage the work.

Learn more about OpsLevel Maintenance Agent.

‍