Coding agents are changing the economics of technical debt

Most teams have a list of migrations they understand perfectly well and keep putting off, like a package upgrade or a deprecated API swap. They stay postponed because the manual cost is bigger than the business value anyone can see, and most of that cost used to be engineering time spent making the same kind of change across a lot of files. Coding agents can take a good chunk of that away. You can't just divide the old estimate by the number of agents, though, because the team still pays for preparation, review, integration and fixing mistakes.

So I'd split the estimate up. "Reduce technical debt" is too loose to estimate or hand to anyone, so break it into changes with edges you can see. One package migration might mean updating imports, replacing deprecated calls, regenerating fixtures and passing a defined test suite. Another might touch behaviour with no reliable test, which means someone comparing results by hand. For each task I'd estimate the agent's run separately from the human work around it, including writing acceptance criteria up front, reading the diff and rebasing at the end. A mechanical change across well-tested modules might get much cheaper. A short change in a fragile subsystem might barely move, because most of the effort there is understanding and checking it.

Test quality moves the numbers more than anything else. A passing suite only helps if it covers the behaviour the migration touches, and snapshot churn or broad mocks can let a wrong implementation through. Before launching anything in parallel, I'd map each task to the check that shows it worked. Where coverage is weak, the first bit of debt work might just be adding characterisation tests or a repeatable comparison (worth having anyway, since reviewers get something to check against).

Running several agents at once shortens elapsed time when their tasks don't fight over the same files or assumptions. Split along packages, endpoints or independent batches, and give each worker its own workspace and a work order covering the objective, permitted paths, relevant conventions, acceptance checks, expected output and when to stop and report a blocker. Lockfiles, central exports and generated schemas attract changes from every branch, so hand those to one integration task. I'd also run one or two representative tasks first and read the diffs, since a flawed instruction gets copied into every worker and it's much cheaper to fix after one branch than across the whole repo.

The other limit is review. Generated branches can turn up faster than anyone can read them, and a queue of unreviewed work brings rebases and pressure to approve big batches. I'd cap active agent tasks at the review capacity you actually have and keep formatting, generated output and behaviour changes in separate branches so the important lines are easy to find. If the change affects runtime behaviour, feature flags, compatibility layers or reversible schema changes belong in the estimate too, because a code revert won't undo data the new path has already transformed.

So coding agents do change the economics of technical debt, mostly by making the repeated edits across a lot of files cheap, while preparation, review, integration and fixing mistakes still cost the team real time. That's why I'd test the new maths on the migration you've been putting off before trusting it: write a one-page work order, run a representative slice and measure agent time, preparation, review, integration and rework. If the slice passes the same checks the full migration would use, those numbers can back a new estimate. If it can't be checked cleanly, fix that before you multiply the work across a batch of agents.