Throughput without hiring
Capacity for the work you would never justify a headcount for, priced by work done rather than per seat.
Use case
AI employees for backlog burn-down.
The dependency bumps, the flaky test, the deprecation warning, the docs that stopped matching the code two releases ago. None of it is hard. All of it is real. It simply never wins against the roadmap. An AI employee can own that stream continuously, in the background, with every change reviewed like any other pull request.
No credit card required.
The problem
Nobody disagrees that it should be done. It just never gets done.
Open your backlog and scroll past the top twenty items. Everything below that line has the same shape.
A test that fails about one run in fifteen, which everyone now reruns without looking. A library three major versions behind, still fine, until the day it is a security advisory. A deprecation warning that has been printing on every build since last spring. A bug that affects four customers a month and has a known one-line fix. A README that tells new joiners to run a command that no longer exists.
Every one of these is agreed to be worth doing. Every one of them loses sprint planning to something with a customer attached. That is not a failure of discipline — it is what prioritisation is for. A task worth two hours and no revenue will always sit below a task worth two weeks and a renewal, and it will sit there permanently.
Meanwhile the cost lands on the people you can least afford to spend on it. A senior engineer picks up the flaky test on a Friday afternoon because it finally annoyed them enough. The upgrade gets done in a rush during an incident, which is the worst possible time. And your best engineers spend their attention on work that any competent person could do, if any competent person had the hours.
This work isn’t difficult. It’s unprioritised — and it will stay unprioritised as long as doing it costs a person a day.
What changes
Give the stream a permanent owner instead of a slot in the sprint.
The fix is not better prioritisation. It is capacity that does not compete with the roadmap for the same hours.
Continuous, not scheduled
An AI employee with a defined role can hold this work as its actual job. It picks up the next item, does it, opens a pull request, and moves on — on a Tuesday afternoon, on a Sunday, during your release freeze if you let it. The queue drains in the background instead of waiting for a quarter where someone declares a “tech debt sprint.”
Memory is what stops it being noise
Small changes go wrong when the person making them lacks context. Why this dependency was pinned. Why this test is skipped on CI. Which module the last three regressions came from. Organizational memory holds that, so the tenth pull request is better informed than the first — and the reasoning behind each change is written down rather than living in one reviewer’s head.
Continuousthe queue drains between sprints, not during them
Reviewedevery change is a pull request against your rules
Scopedyou choose the repositories and the categories
Nothing about your process changes. The work arrives where all your other work arrives, in the same review queue, against the same CI and the same branch protection. What changes is that your senior engineers stop being the bottleneck for work that never needed them.
How it works in practice
One stream, running quietly.
-
1
Define the stream
You pick the repositories and the categories — dependency upgrades, flaky tests, deprecation warnings, small labelled bugs, doc drift. You set how much can be in flight at once, so review load stays something your team chose.
-
2
It takes the next item
From your Jira board, your GitHub issues, or a label you already use. There is no new tool and no new ritual — the backlog you already have is the queue, and you can still reprioritise it any time.
-
3
It does the whole task
Not just the change: the failing call sites the upgrade created, the test that now needs updating, the changelog entry. It runs your suite and opens a pull request explaining what it did and why — or stops and asks, if the ticket turns out to be ambiguous.
-
4
You review, then it repeats
Your reviewers approve, request changes, or close it. Feedback goes into organizational memory, so the same correction is not needed twice. Then it picks up the next item.
What stays under human control
Volume without oversight is just a bigger mess.
More throughput is only useful if every change still meets the bar you already set. Every action is logged.
AI executes
- Pick up the next item in the agreed stream
- Make the change and fix what it breaks
- Update or add tests
- Run the suite and the linters
- Open a pull request explaining the reasoning
- Respond to review comments and update docs
Humans approve
- Which repositories and categories are in scope
- How much work is in flight at once
- Every pull request, under your existing rules
- The merge
- Production deployments and releases
- Security-sensitive and infrastructure changes
What you get
Where the difference shows up.
Dependencies that stay current
Upgrades done continuously and in small steps, instead of one frightening jump under advisory pressure.
A CI signal you trust again
Flaky and slow tests treated as real work, so a red build starts meaning something once more.
Docs that match the code
READMEs, runbooks and onboarding notes corrected as the code they describe changes.
Seniors back on senior work
Your most experienced engineers stop being the route through which trivial work has to pass.
Scoped, least-privilege access
Only the repositories and environments you grant, with SSO, RBAC and a full audit trail.
What belongs to your engineers
This works because the tasks are well defined and cheap to verify. It stops working the moment the hard part is deciding what to do rather than doing it. Ambiguous tickets, contentious refactors, anything with a product judgement inside it, and anything where three engineers would produce three different reasonable answers — those still belong to your team, and an AI employee should be told to ask rather than guess. There is also a real review cost: every change still needs a human to read it. Start narrow, see what the review load actually feels like, and widen from there.
FAQ
What teams want to know before pointing it at a repo.
What kind of backlog work is a good fit?
Work that is well defined, verifiable, and small: dependency and framework upgrades, deprecation warnings, flaky and slow tests, small well-specified bugs, lint and type errors, dead code removal, log noise, and documentation that no longer matches the code. The test is whether a reviewer could tell in a few minutes if the change is correct.
What is a bad fit?
Anything where the hard part is deciding what to do rather than doing it. Ambiguous tickets, product judgement, contentious refactors and architectural change belong with your engineers. A ticket that three people would interpret three different ways is not backlog burn-down, it is a design conversation wearing a ticket.
Won’t this just flood us with pull requests to review?
It would if you let it. You set the scope and the rate — which repositories, which categories of work, and how much is in flight at once. Most teams start with one narrow stream in one repository, see what the review load actually feels like, and widen from there.
Does the code still go through review?
Yes, exactly like any other change. It arrives as a pull request in your repository, against your branch protection rules, your CI and your reviewers. Nothing merges or deploys to production without a human approving it, and every action is logged. See the security page.
How is this different from a bot that opens dependency upgrade pull requests?
An upgrade bot opens the pull request and stops. It cannot tell you why the build broke, fix the three call sites the new major version changed, or remember that this library was pinned deliberately last year. An AI employee has organizational memory and owns the task to completion, including the follow-up work the bump creates. See how it compares.
How do we start without disrupting the team?
Pick one repository and one category — flaky tests, say, or deprecation warnings. Run it on the Free plan with a single AI employee and see the pull requests for yourself. If the changes are not worth reviewing, you have lost a morning and no credit card was involved.
Get started
Pick one repository. Pick one category. See what comes back.
One AI employee, one narrow stream of work, reviewed exactly the way you review everything else.
No credit card required.