Hand Off Scoped Tasks to Background Agents
What it is
Why it works
Agents are strongest on bounded, verifiable work and weakest on open-ended 'make it better' asks. A clear scope plus a way to check success (tests pass, a script runs) lets the agent self-correct, and turns your job into reviewing a diff rather than typing every edit.
When to use it
Mechanical-but-spread-out tasks: rename a concept across the repo, add a field end-to-end, migrate a deprecated API, wire up a new route following an existing one.
When not to use it
Ambiguous design work or anything where 'done' can't be checked. If you can't state the success condition, the agent can't know when to stop — do that thinking first.
Prompt
"Task: add a `deletedAt` soft-delete field to the Order model, end to end.
Scope: model, migration, repository, and the two queries that list orders.
Done when: `npm test` passes and listing excludes soft-deleted orders.
Follow the pattern already used for `archivedAt`. Show me a plan before editing."Example
Asked to migrate 30 call sites from a deprecated fetchUser() to getUser(), the agent finds them via the index, edits each, runs the tests, fixes the two that break, and hands you a clean diff to review — a 40-minute chore done in one pass.
Advanced version
Point the agent at an existing reference implementation ('follow the pattern used for archivedAt') so it matches your conventions, and require a plan before edits so you can correct course cheaply. Combine with strong rules so its output already fits the codebase.
Common mistakes
- Giving an unscoped task with no success condition, so the agent wanders and over-edits.
- Not asking for a plan first, then discovering a wrong approach after 20 files changed.
- Rubber-stamping the diff — always review agent output; scope makes it checkable, not infallible.