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.

What changed in 2026 is that the payoff stopped being an argument from principle and became a number on an invoice. Giles Edwards-Alexander's "The Economic Benefit of Refactoring" (martinfowler.com, July 30) ran the same representative feature request against a codebase at 15 successive refactoring stages, using a fresh agent each time to eliminate learning bias - a controlled experiment that was simply not possible before agents, because no human forgets a codebase on demand. Breaking a 17,155-line single Rust file into 19 files took the input tokens required for that feature from 159,564 to 27,360, an 83% reduction, or roughly $0.40 per change at Sonnet 5 pricing. The per-change figure is small. The structure of it is not: that reduction applies to every future modification of that code, by every agent, forever, which makes refactoring a compounding investment with an observable rate of return rather than a hygiene argument engineers lose to roadmap pressure. The honest caveat is that the cost of performing the refactor itself, an upper bound of roughly five million tokens, was not precisely tracked.

This gives continuous modernization a second metric alongside items closed: the input-token cost of a representative change to each area of the codebase. Measure it before the agent works an area and after. Unlike debt-item counts, it is denominated in the same units as your bill, and it makes the case to a CFO without translation.

• 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.

August 2026 put a production-scale price on that inflow for the first time. A study of 3.52M code changes tracked from April 2025 to April 2026 in a single large enterprise brownfield C++ codebase with full production observability (arXiv 2608.06640) found AI-generated code carrying a higher interface and coupling burden, more copy and allocation overhead, and explicit loops where an optimised standard API existed. Downstream, that showed up as a 5-8% increase in compute resource consumption, plus increased review effort. This is the first number that moves AI code quality from the maintainability ledger, where it can be deferred indefinitely, onto the cloud bill, where it cannot. The same study points at the remedy: targeted, taxonomy-informed feedback to the model cut the targeted static-analysis warnings by 11.1%, which is to say the inflow is steerable if you characterise it first. A separate August study of 441 repositories found a cheaper lever still - repositories without committed AI configuration showed roughly twice the cognitive-complexity increase, 53% against 27%, and 1.7 times the static-analysis warnings, while 73.8% of AI config files were committed once and never touched again.

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.
7. Baseline the token cost of a representative change per area - Before the agent works an area, pick one representative change and record the input tokens an agent needs to make it. Record it again afterwards. This is the metric that turns refactoring from a hygiene argument into an investment case, and it compounds: the reduction applies to every future modification of that code. In the controlled experiment behind this practice, decomposing a single 17,155-line file into 19 files cut the input tokens for the same feature request by 83%.

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.

Measuring only the debt you are clearing, never the debt arriving. An agent working the backlog produces a satisfying downward line while a second line climbs out of frame. The August 2026 C++ study is the reason to instrument both: AI-generated changes in a large brownfield codebase carried enough interface, coupling and allocation overhead to raise compute resource consumption by 5-8%, which is a cost that shows up on the infrastructure invoice rather than in a code-quality dashboard. Characterise the inflow the way that study did - name the specific recurring patterns - because targeted feedback to the model cut the targeted warnings by 11.1%, and an inflow you have not characterised is one you can only clean up after.

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.