OpsLevel's Maintenance Agent: The Last Mile of Code Maintenance, Automated

OpsLevel's Maintenance Agent: The Last Mile of Code Maintenance, Automated

We built OpsLevel to give platform teams the leverage they need to operate at scale. The service catalog, scorecards, checks, self-service actions - all of it exists so that a small platform team can set standards and drive change across an engineering org of hundreds without becoming a bottleneck.

Campaigns extended that further. For the first time, platform teams could define a maintenance initiative, target the right services, and track progress across dozens or hundreds of teams in one place instead of juggling spreadsheets and Slack threads.

But we kept hearing the same thing from customers: "Campaigns show us exactly what needs to happen. The problem is getting 30 teams to actually do it."

Today we're solving that problem.

The work nobody plans for (but everybody does)

There's a category of engineering work that doesn't fit neatly into any team's sprint. Dependency upgrades, security patches, library migrations, config standardization, framework version bumps. It's not product work. It's not tech debt in the traditional sense. It's the operational cost of running software at scale - and after a decade working alongside more than 100 platform engineering teams, we've seen it consistently consume 20-50% of engineering capacity.

The frustrating part isn't that it exists. It's that it's almost entirely undifferentiated. Upgrading a dependency from v3 to v4 across 200 services doesn't require creative problem-solving. It requires someone to sit down, understand each repo's quirks, make the change, get it through CI, and open a PR. Then do it 199 more times.

Engineering leaders know this math. They know their best engineers, the people they fought hardest to hire, are spending real time on work that will never show up in a product demo. But the alternative - deferring it - just compounds the problem. Outdated dependencies slow teams down. Unpatched vulnerabilities become audit emergencies. The maintenance surface only grows.

Campaigns got us halfway there

When we launched Campaigns, we were solving the coordination layer. And it worked. Which services needed the change, who owned them, what was done, what was stuck - all in one place. But more than just visibility, it changed who carried the burden. Before Campaigns, platform teams were the ones chasing: asking individual teams what state their services were in because they couldn't see it directly, filing tickets across 30 Jira boards, writing Slack messages to team leads, building spreadsheets to track who'd done what. The platform team carried the entire coordination burden, and it didn't scale.

Campaigns inverted that. Define the initiative once - what needs to change, which services are affected, and why - and every owning team sees exactly what's expected of them, in context, without the platform team having to ask. Progress rolls up automatically. The information flows outward instead of the platform team pulling it inward.

That was a genuine unlock. But coordination and execution are two different problems. Campaigns could tell every team precisely what they needed to do. What it couldn't do was make it happen without each of those engineers context-switching away from feature work, figuring out how the change applied to their specific repo, and pushing a PR through review.

That last mile, the actual hands-on-keyboard work, was still competing with everything else on every team's plate. Initiatives that should have taken weeks dragged on for months. Not because of poor planning or lack of visibility. Because the bottleneck had moved downstream, to execution.

Closing the loop with Maintenance Agent

OpsLevel's Maintenance Agent brings AI-powered code generation into the workflow that Campaigns already orchestrates. The platform team defines the change once. The agent does the work across every targeted repo. Your engineers review and merge instead of writing boilerplate from scratch.

It starts with the initiative definition - what needs to change and why. The agent then analyzes each targeted repository individually. It doesn't apply a generic template. It generates changes that respect the reality of each repo, the way a careful engineer would if they had unlimited time.

Before anything reaches your teams, you review it. This is a deliberate design choice. You can inspect the agent's work on a few example repos, provide feedback, iterate, and regenerate. When you're happy, start generating code for everything. When pull requests finally land in front of service owners, they're ready to merge - not rough drafts that create more work. One customer described the distinction well: it's the difference between delegating and dumping.

From there, the agent tracks everything to completion. PR comments, merge progress, blockers - all visible in one place. Platform teams focus on exceptions and nudges rather than manually checking 200 PRs in GitHub.

And because this is built into OpsLevel, the agent already knows your service catalog, your ownership data, and your standards. There's no separate setup or mapping exercise. It plugs into the context you've already built.

What we're hearing from customers

The teams using Maintenance Agent are the ones who felt the last-mile problem most acutely - large orgs with hundreds of services where even well-coordinated initiatives could stall at the execution stage.

One engineering manager told us that a cross-org initiative that would have meant months of negotiating priorities across 30-plus teams was handled almost entirely by the agent. Teams just verified and merged. Nearly 500 PRs closed.

A head of security engineering said the per-PR time savings were significant - at least 70% - but the bigger win was eliminating the coordination overhead. No spreadsheets, no chasing, everything in one place.

A staff SRE described it as a shift in how cross-cutting work gets done. Instead of asking dozens of teams to prioritize something they'd rather defer, the agent lowers the barrier to the point where merging is the path of least resistance.

The pattern across all of them: initiatives that used to take a quarter now finish in weeks or days.

The full loop

If you've been using OpsLevel, this is the piece that completes the picture. The service catalog gives you a source of truth about what you have. Scorecards and checks define what good looks like. Campaigns coordinate the initiative. And now Maintenance Agent does the work.

It's the progression we've been building toward for years: know, define, plan, execute. All without burning your teams' capacity on undifferentiated labor.

One more thing

Maintenance Agent has been working so well with our customers that we've decided to also make it available as its own standalone product: Tidra.

Tidra brings the same AI-powered, large-scale code maintenance capabilities to any engineering organization - whether or not they use OpsLevel. If you know someone sitting on a maintenance backlog that never shrinks, point them to tidra.ai.

For OpsLevel customers, Maintenance Agent is available now within your environment. Reach out to your account team to get started.