Continuous Modernization: agent pays off debt in background

Continuous modernization is the L3 shift from treating tech debt reduction as a project - something that competes with features for engineering time - to treating it as infrastructure that runs in the background, continuously, without consuming primary engineering capacity. At L3, an AI agent is configured to work through the prioritized debt inventory on an ongoing basis, producing PRs that engineers review rather than write.

The operational model is: the debt inventory (built at L2) serves as the agent's work queue. The agent takes items from the queue, executes the appropriate transformation (running an OpenRewrite recipe, updating a dependency version, replacing deprecated API usage), runs the test suite to validate the change, and opens a PR for human review. The engineer's role is to review and merge, not to write the migration code. The agent works asynchronously - it can run migrations overnight, on weekends, or during low-activity periods, consuming no engineering time during execution.

This is a fundamental economic shift. At L2, a migration that takes two weeks of engineering time consumes two weeks of capacity that cannot be used for features. At L3, the same migration produces a PR that takes two hours to review. The engineering cost of migration drops by an order of magnitude, and the migration backlog that seemed infinite at L1 becomes tractable. An organization running continuous modernization can address its entire multi-year backlog in months rather than years.

The "background" framing is important. Continuous modernization does not require a dedicated migration sprint, a separate migration team, or a freeze on feature development. It runs in parallel with normal feature work, using the same CI infrastructure and PR review process. The only additional capacity required is the review time - and review is inherently lighter than writing.

• Eliminates the project-vs-features tradeoff - When migrations do not consume engineering time to execute, they no longer compete with features for sprint capacity; the perennial "we'll fix the debt after the feature rush" excuse disappears
• Enables backlog clearance at scale - An agent running continuously can process more migration items per week than any human team; a backlog that would take humans three years can be cleared in months
• Maintains currency automatically - Rather than allowing dependency versions to drift for years and then executing a painful major migration, continuous modernization keeps the codebase near-current with incremental updates that are individually simple
• Creates a measurable debt reduction velocity - With an agent producing a consistent stream of debt-reduction PRs, debt velocity becomes a metric: items closed per week, backlog age reduction, lines of deprecated code remaining. This visibility was impossible at L1-L2.
• Compounds with code quality - A codebase that is continuously modernized accumulates fewer secondary debt issues; modern APIs are better tested, better documented, and have clearer deprecation paths than the legacy ones they replace

NOTE — AI also CREATES tech debt. Studies show a 30-41% increase in technical debt within six months of widespread AI tool adoption. PRs with AI-generated code have 1.7x more issues flagged during review, and 89.1% of issues in AI-authored commits are code smells. Continuous modernization must now account for AI-generated debt alongside legacy debt. The agent that pays off old debt must also clean up after other agents — monitoring new-debt inflow from AI-assisted development is as important as clearing the existing backlog.

1. Ensure the debt inventory is current and structured - The agent needs a machine-readable work queue. Confirm the debt inventory has items in a consistent format: type, description, target state, and the specific transformation to apply (recipe name, version target, or pattern to replace).
2. Establish the agent's toolchain - At minimum, the agent needs: repository access (read and write), the ability to run OpenRewrite recipes, the ability to run the test suite, and the ability to open PRs. Configure these permissions before the first run.
3. Start with one category of debt - Do not run all migration types simultaneously. Start with dependency version upgrades (the most mechanical, lowest-risk category). Let the agent process five dependency bumps, review the resulting PRs, and confirm the pattern works before expanding scope.
4. Define the PR review SLA - The bottleneck in continuous modernization is review throughput. Establish a norm: debt-reduction PRs (verified green by CI) are reviewed within 48 hours. Without this SLA, PRs pile up, the agent gets blocked, and the "continuous" part breaks down.
5. Monitor for false positives - In the first month, track how often agent-generated PRs require changes during review. A false positive rate above 20% means the agent's task specifications are too loose. Tighten the criteria and re-run.
6. Expand scope gradually - After dependency bumps are working, add API migration tasks. After API migration is working, add framework version upgrades. Expand the agent's mandate as confidence builds, not all at once.

Running the agent without a validated test suite. Continuous modernization depends on tests to validate that transformations are safe. If the test suite is unreliable (flaky tests, low coverage), agent-generated PRs will have unreliable green signals and the review burden rises dramatically. Fix the test suite before enabling continuous modernization.

Letting agent PRs pile up unreviewed. An agent that opens 20 PRs but has 0 merged is not delivering value - it is creating review debt. The review SLA is not optional. If the team cannot commit to 48-hour review of agent PRs, reduce the agent's output rate until the review capacity matches.

Not monitoring for agent drift. Over time, an agent given a broad mandate will start generating PRs that are outside the intended scope - optimizations that are not in the debt inventory, refactoring that changes behavior in subtle ways, or changes to code areas that were not meant to be touched. Review the agent's output pattern monthly; pull back the mandate if scope drift appears.

Applying migrations without canary testing. For high-traffic services, even a mechanically correct migration can have unexpected production behavior. Establish a canary deployment path for agent-generated PRs in critical services: deploy to 5% of traffic before full rollout.

Treating continuous modernization as a replacement for engineering judgment. The agent handles the mechanical work; engineers handle the judgment calls. Some debt items will be flagged by the agent but require human decisions - does this API change affect any downstream consumers? Should this deprecated pattern be replaced or removed entirely? These decisions should escalate to humans, not be made autonomously.