Fleet 1.13:Teams are now shipping 5x more PRs with autonomous pipelines.See what's new →
FleetFleet
Use case

AI Agents for Tech Debt

Tech debt does not go away on its own. Teams acknowledge it, add it to a backlog, and then continue shipping features because the debt items are never urgent enough to displace the current sprint's priorities. Over time the debt grows until it starts visibly slowing feature development — at which point it is much harder to address.

The challenge with tech debt is that it is hard to make continuous progress on it when sprints are focused on new features. Small amounts of debt remediation done consistently are more effective than large-scale refactoring sprints scheduled annually. But small amounts of anything are hard to prioritize.

How it works with an agent fleet

Agents work on tech debt tickets in parallel with feature development, using available capacity between feature assignments.

# Tag tech debt items in GitHub with a label so they enter the ready queue

# Check current agent utilization
fleet status

# Manually assign a specific debt item when capacity is clear
fleet task assign backend-dev "Remove deprecated v1 API handlers (see issue #103)"

Tech debt items are filed as GitHub issues with a ready label. When a developer agent is idle, the watcher can dispatch it to the next tech debt ticket in the queue.

The fleet pattern

Tech debt is addressed in the background. Developer agents pick up debt tickets when they are not assigned feature work. Each debt item becomes a small, reviewable PR. A tech-lead reviews for correctness and to ensure the change does not introduce new problems. The accumulated effect is a codebase that improves continuously without a dedicated refactoring sprint.

Guardrails that matter here

  • Tech debt tickets require the same spec quality as feature tickets — agents need clear scope and acceptance criteria
  • All changes go through tech-lead review; debt remediation that alters public interfaces requires additional scrutiny
  • Agent prompt distinguishes between safe cleanup (dead code removal, formatting) and riskier changes (interface modifications) with different escalation thresholds

Who this is for

Engineering teams with a growing tech debt backlog and limited capacity to address it during feature sprints. Works best when debt items are sized small enough for a single PR — large architectural changes still require human-led planning.

Frequently asked questions

How do you prevent agents from creating new tech debt while fixing old debt?

The tech-lead review catches new debt introduced in debt-remediation PRs. You can also configure the tech-lead prompt to be particularly strict on code quality for PRs tagged as debt remediation.

Can agents identify tech debt, or do humans need to file the tickets?

In the standard configuration, humans file the tickets. You can write an analysis agent that scans the codebase for specific patterns (TODO comments, deprecated function calls, complexity metrics above a threshold) and creates tickets automatically — but that analysis agent requires human review of its findings before tickets are acted on.

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.