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 infrastruct
- ·Continuous modernization: agents work on tech debt reduction in background (non-blocking to feature work)
- ·Library version bumps and dependency upgrades are automated via agent PRs
- ·OpenRewrite + agent combination is used for systematic refactoring campaigns
- ·Agent tech debt PRs follow the same review process as feature PRs
- ·Dependency freshness score is tracked (% of dependencies within N versions of latest)
Evidence
- ·Agent-authored tech debt reduction PRs in git history
- ·Automated dependency upgrade configuration (Renovate + agent, Dependabot + agent)
- ·OpenRewrite recipe configuration with agent integration
What It Is
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.
Why It Matters
- 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.
Getting Started
6 steps to get from here to the next level
Common Pitfalls
Mistakes teams actually make at this stage - and how to avoid them
How Different Roles See It
Bob has been running continuous modernization for six weeks. The agent has generated 34 PRs: 28 have been merged, 4 are in review, and 2 were closed because they touched code areas that were in active feature development. The merged PRs have addressed 14 items from the debt inventory - more progress than the team made in the previous year through manual effort. Bob is converting from skeptic to advocate.
The next challenge for Bob is organizational: other teams have heard about this and want to adopt it, but they do not have a structured debt inventory, and their test suites are less reliable than his team's. Bob should create a "continuous modernization readiness checklist" - the prerequisites that teams must meet before enabling an agent-based migration workflow. The checklist is: structured debt inventory with 20+ items, test coverage above 70% in the areas to be migrated, and a designated PR reviewer who commits to the 48-hour SLA. Teams that meet the checklist get access to the shared agent configuration. Teams that do not have a clear improvement path to readiness.
Sarah now has the data she has been waiting for: a clear before-and-after comparison for debt reduction velocity. Before continuous modernization: the team addressed 2 debt items per quarter through manual effort. After continuous modernization: the team is addressing 14 items in six weeks. The engineering time per item has dropped from approximately 40 hours (manual) to approximately 2 hours (review only). That is a 20x productivity improvement on debt reduction specifically.
Sarah should publish this comparison as a case study. It is the clearest possible demonstration of AI maturity ROI, and it will be more persuasive to other teams and to leadership than any abstract argument. She should also start tracking "debt backlog age" - the average age of items in the inventory - as a leading indicator of organizational technical health. As continuous modernization runs, this metric should decline. If it does not, the agent's output rate is not keeping up with new debt creation, which is itself a useful signal.
Victor is the one who configured the agent, wrote the task specifications for the debt inventory items, and is the primary reviewer of agent-generated PRs. He has developed a strong sense for the difference between agent output that is clearly safe to merge quickly and agent output that needs careful review. Dependency bumps with green tests: quick merge. API migration in a module with low test coverage: careful review. Framework upgrade touching 300 files: line-by-line review of a sample, test run in staging.
Victor should codify this review heuristic as a written protocol - the "agent PR review guide" for his team. The guide specifies: for each category of agent-generated PR, what is the appropriate review depth? Which categories can be merged by any developer? Which require Victor's review? Which require staging deployment before merge? This protocol scales Victor's knowledge to the entire team and means that when Victor is on vacation, the agent's output does not pile up unreviewed. The protocol is also the foundation for the higher-autonomy configuration at L4, where the lowest-risk categories move from "requires review" to "auto-merge on green CI."
Further Reading
5 resources worth reading - hand-picked, not scraped
From the Field
Recent releases, projects, and discussions relevant to this maturity level.
Tech Debt & Modernization