Run a codebase-wide migration
Swap a library, rename an API, or change a pattern everywhere it appears. Sarvam Code finds every call site, edits them consistently, and keeps the build green as it goes.
› Migrate every call from the deprecated db.QueryRow to the new pool.QueryOne API across the repo
• I'll inventory the call sites first, then migrate in batches and run the build between each.
• Ran rg -n 'db.QueryRow\(' --type go | wc -l
└ 41
• 41 call sites across 12 packages. Starting with internal/orders (9 sites).
• Edited internal/orders/repo.go (+2 -2)
• Ran go build ./... && go test ./internal/orders
└ ok internal/orders 0.412s
Batch 1/6 green
• 9 sites migrated, build and orders tests pass. Continuing with the remaining 32 across 11 packages, and I'll flag anything ambiguous.
- 01Describe the migration: the old pattern, the new one, and any edge cases.
- 02The agent inventories every call site across the repo, not just the obvious ones.
- 03It works through them in batches, showing diffs and pausing at anything ambiguous.
- 04It runs the build and tests between batches so a broken state never piles up.
- 05You get one reviewable changeset with the migration done and the suite green.
A migration is the work everyone postpones: moving off a deprecated client, renaming a function that forty files import, or replacing a logging pattern project-wide. It is tedious, easy to do inconsistently, and risky to do by hand because one missed call site fails in production, not in review.
This is exactly where a coding agent earns its keep. Sarvam Code reads the whole repository to find every occurrence, including the indirect ones a grep would miss, then edits them to match. It works in batches and re-runs your build and tests between each, so the codebase is never left half-migrated. You stay at the gateway: every diff is shown, and anything genuinely ambiguous is surfaced for your call rather than guessed.
Because the agent reads far more than it writes here, a sprawling migration that would cost a fortune on a frontier model stays cheap on Sarvam. Long, mechanical, repo-wide work is the sweet spot for a low-cost default with the harness to keep it disciplined.
Curious what it costs to run work like this? See cost per task, or the full pricing.