Coding agents are changing the economics of technical debt

Some migrations remain postponed because their manual cost is larger than their visible business value. Parallel agents and fast verification can change that calculation, although only where the repository has clear conventions, reliable tests and a definition of done that a reviewer can check. This affects the backlog of repetitive upgrades, API replacements, test repairs and consistency work that teams understand but struggle to prioritise. The cost estimate used to be dominated by engineering time spent making similar changes across many files. An agent can reduce some of that effort. The team still pays for preparation, review, integration and mistakes, so the old estimate cannot simply be divided by the number of agents. "Reduce technical debt" is too loose for estimating or delegation. Break the proposal into changes with observable boundaries. One package migration might require updating imports, replacing deprecated calls, regenerating fixtures and passing a defined test suite. Another may involve behaviour that has no reliable test and needs manual comparison. For each task, I would estimate agent execution separately from human work. Preparation includes finding the relevant conventions, identifying affected paths and writing acceptance criteria. Review includes inspecting the diff, understanding behaviour changes and resolving uncertain cases. Integration includes rebasing, running broader checks and handling interactions with other work.

This produces a more honest comparison. A mechanical change across well-tested modules may become much cheaper. A short change in a fragile subsystem may remain expensive because most of the effort sits in understanding and verification. File count alone is a poor measure for both people and agents. Small pilot tasks can supply the missing estimates. Record elapsed agent time, reviewer time, failure types and rework. The point is to price the rest of the migration from observed work in that repository, without treating one successful run as a universal productivity figure. Coding agents depend on the information available inside the workspace. A repository with current setup instructions, predictable structure and focused tests gives an agent ways to proceed and check itself. An inconsistent repository pushes more interpretation onto the reviewer. Conventions should be executable where possible. Formatters, linters, type checks and test commands communicate expectations more precisely than a long prose guide. Prose still matters for architectural boundaries, generated files, areas with unusual deployment rules and work the agent must leave alone. Test quality changes the economics most sharply. A passing suite is useful only if it covers the behaviour touched by the migration. Snapshot churn or broad mocks can allow a wrong implementation to pass. Before launching parallel work, map each task to the check that demonstrates its result.

Where coverage is weak, the first piece of debt work may be adding characterisation tests or a repeatable comparison. That preparation has value beyond the agent run. It gives reviewers evidence and makes later maintenance less dependent on personal memory. Running several agents at once can shorten elapsed time when their tasks do not fight over the same files or assumptions. A useful partition may follow packages, adapters, endpoints or independent batches of the same migration. Each worker should have an isolated workspace and a bounded work order. The work order names the objective, permitted paths, relevant conventions, acceptance checks and expected output. It should also say when to stop and report a blocker. Otherwise several agents can make different guesses about one unclear rule and produce a larger reconciliation job. Shared files require deliberate handling. Lockfiles, central exports, generated schemas and global configuration often attract changes from every branch. Assign them to one integration task or sequence the work so workers do not repeatedly overwrite one another. Parallelism can also multiply a flawed instruction. Run one or two representative tasks first, inspect the diffs and update the work order. Only then expand the batch. This is slower than starting every worker immediately and usually cheaper than correcting the same mistake across the repository.

Generated changes can arrive faster than maintainers can understand them. A queue of unreviewed branches creates its own cost through rebases, stale assumptions and pressure to approve large batches quickly. I would limit active agent tasks to the review capacity available for that type of work. Reviewers need small diffs, a stated acceptance result and the agent's record of commands and unresolved concerns. Passing checks should be reproducible in the review environment. Diff size is a practical control. A migration split into reviewable units makes it easier to spot a repeated error before it spreads. It also lets the team merge verified work while a difficult part remains open. Combining formatting, generated output and behaviour changes in one branch makes the important lines harder to find. Some review can be automated, but the automated checks need the same scrutiny as the change. A script that confirms the old API name has disappeared cannot prove the replacement behaves correctly. Use it for that narrow claim and keep behavioural checks beside it. Agent work can fail through a wrong assumption, incomplete search, test weakness or conflict with a parallel branch. The estimate should include expected rework and the cost of detecting the problem. Cheap generation followed by expensive diagnosis may leave the total unchanged.

Release strategy matters for debt work that affects runtime behaviour. Feature flags, compatibility layers, staged deployment or reversible database changes can reduce the cost of a mistake. These mechanisms take time to build, so they belong in the migration estimate rather than appearing as an emergency response. Keep a baseline that can be restored and avoid mixing unrelated changes into the same rollout. For data or schema migrations, test recovery with representative fixtures before production use. A code revert may not reverse data already transformed by the new path. The best candidates have a bounded scope, repetitive implementation and strong checks. They also remove a real maintenance cost, security exposure or blocker for future work. Work selected only because an agent can edit it cheaply can add review activity without improving the product. For the next postponed migration, write a one-page work order and run a representative slice. Measure agent execution, human preparation, review, integration and rework. If the slice passes the same checks the full migration would use, those numbers can support a new estimate. If it cannot be checked cleanly, fix that condition before multiplying the work across parallel agents.