Buy vs. build: The stack behind a fleet-wide code maintenance platform

Most enterprise software maintenance is categorized by why the work matters: security, compliance, modernization, reliability, performance, developer velocity.

That is a useful taxonomy for leadership. It is the wrong one for the people who have to do the work.

A React migration can be security, lifecycle, performance, and developer velocity at the same time. Replacing an abandoned dependency can improve security, bundle size, reliability, and maintainability together. The driver says why a change matters. It says almost nothing about the machinery required to find, change, verify, and roll that change out.

For platform teams responsible for thousands of repositories, those are two different lenses: drivers for prioritization, and categories for execution.

The type of change determines the machinery, even when one opportunity serves several goals.

The work itself falls into seven categories:

These categories are operationally distinct in a way the drivers are not. Dependency maintenance needs package metadata, lockfiles, vulnerability feeds, and API migrations. Infrastructure maintenance needs YAML, HCL, containers, cloud resources, and deployment validation. Architecture work needs a model of symbols, modules, services, repositories, and teams.

The same maintenance opportunity can serve several business goals, but the machinery required to execute it is mostly determined by the type of change.

Every category needs the same stack, and at fleet scale the hard parts are prioritization and coordination.

Across those categories, the projects we see keep depending on the same building blocks.

Understand the fleet: inventory and ownership, parsing, a code graph, knowledge feeds, and runtime signals. Decide what matters: detection and prioritization. Act on it: transformation, verification, and orchestration.

Finding 50,000 issues is not useful if a platform team still has to decide by hand what deserves attention.

Changing one repository is a coding problem. Changing 2,000 repositories owned by 150 teams is a distributed systems and organizational coordination problem.

The missing infrastructure marries a cross-language, dependency-aware code graph with the systems of record you already have.

Building a maintenance platform does not mean rebuilding every piece of this stack.

Most large organizations already have systems of record for ownership, vulnerabilities, observability, CI, and work tracking. Those systems should stay.

The missing piece is the layer that connects them.

A scanner can find a vulnerable dependency. That finding does not say whether the vulnerable API is reachable, who owns the affected repositories, what a safe upgrade looks like, or how the change should roll out. Remediation needs context, a transformation, verification, ownership, and orchestration.

Categories require different machinery. That machinery converges on the same primitives. The sources of truth already exist. The missing abstraction is a maintenance control plane: shared context and orchestration across the scanners, CI systems, catalogs, and agents an organization already runs.

Each class of maintenance reaches its own level of autonomy, and mixed levels are healthy.

Autonomy is not one organization-wide slider. It is a matrix across classes of maintenance.

A patch upgrade of a well-understood package is a different problem from a framework major version. Removing a stale feature flag is a different problem from decomposing a monolith.

At L5, that class of maintenance has effectively become invisible.

An organization might be L5 for patch dependency upgrades, L4 for feature-flag cleanup, L3 for major framework migrations, and L2 for architectural modernization. That is not a failure of autonomy. It is what a healthy system looks like.

Maintenance runs continuously, and people spend their time on the exceptions.

If these pieces work, the experience becomes much simpler than the infrastructure underneath it.

That last stage is what we mean by making maintenance invisible.

Not that maintenance stops. It happens continuously, and people spend their time on the exceptions.

Dependencies remain current. Deprecated APIs disappear before deadlines. Internal platforms get adopted. Known anti-patterns stop spreading. Security findings get remediated. Repositories stay inside organizational standards.

The engineering organization stops needing large periodic cleanup programs to make those things happen.

Codemod is the agent-agnostic control plane that makes maintenance a continuous infrastructure function.

This framework is also how we are building Codemod.

Grep and Insights understand the fleet. Campaigns and Automations carry out the change. Codemod Agent and MCP are the interfaces for doing that work, whether the actor is a person or another agent. Integrations keep the existing sources of truth in place. Parsing, the code graph, and the transformation engine are the core underneath.

Enterprise maintenance infrastructure is not a codemod runner. It is not a scanner. It is not an agent connected to GitHub. And it is not a dashboard full of technical debt.

Software maintenance becomes a continuous infrastructure function rather than a recurring engineering project. Codemod's role is the agent-agnostic control plane that makes that possible.