Start with the work nobody is typing.
The first useful agent tasks in a big codebase are rarely the exciting ones. They are the jobs with a clear definition of done and a test that can prove it — which is exactly the shape a verification gate can stand behind.
- 01
Alert triage
An error fires at 02:00 and a run starts before anyone wakes up.
The agent reproduces the failure in a sandbox, finds the cause, and either proposes a fix that passes verification or hands over a diagnosis with the evidence attached. The on-call engineer wakes up to a reviewed starting point instead of a stack trace.
Where it doesn’t workAlert payloads are untrusted input. They are treated as data for an agent that runs in an isolated copy with granted capabilities — not as instructions with production access.
- 02
Ticket to pull request
The backlog items nobody schedules because they are individually too small to plan.
A ticket becomes a task, a task becomes a run, and the run either produces a verified pull request or stops with a reason. The value is not that an agent writes the change; it is that the change arrives already tested and already explained.
Where it doesn’t workA vague ticket produces a vague change. The gate proves the code works, not that the ticket was right.
- 03
Dependency and migration work
The long tail of version bumps, deprecations and codemods across many repositories.
Mechanical, repetitive, well-specified by a test suite — the closest thing to an ideal agent task, and the work most likely to be deferred indefinitely by humans. Each repository gets its own sandbox and its own verified pull request.
Where it doesn’t workBreadth is bounded by what your tests actually cover. Where coverage is thin, the gate is thin, and we will say so rather than quietly widening the claim.
- 04
Test coverage
Raising the floor under everything else.
Coverage work is the compounding case: every test an agent adds makes the next agent run more verifiable. It is also the safest place to start, because a failed attempt costs nothing and a successful one is easy to review.
Where it doesn’t workTests written to satisfy a coverage number are worse than none. Review them.
Bring the case you actually have
We would rather tell you a use case is a poor fit during the first call than discover it together in month two. Beta teams are onboarded with an engineer from our side on the first runs.