1 min lesson
Verify every change
Use "Verify every change" to explain each part and the role it plays.
Step 1 of 3
Verify every changethe gates that earn merge
- Compile / type-check
- The change must build and type-check before it’s eligible to merge.
- Tests
- Run the affected suite; a batch with new failures is blocked, not merged with a note.
- Diff review
- A human reads the batch diff - small batches make this real rather than rubber-stamped.
- Lint / format
- Enforce the repo’s style so the migration doesn’t add noise to every future diff.
Learn more
Full explanation
Rollback and blast-radius control
Rollback and blast-radius controlbe able to undo fast
- Keep each batch a separate, revertible commit or PR so a bad slice is one
git revertaway. - Where feasible, gate the new path behind a flag so you can disable it in production without a redeploy.
- Define the blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. before you start: how many files, which services, what’s the worst case if a batch is wrong.
A migration that merges failing changes with a TODO is how you hand the customer a slow-motion outage.
The gate is the product. If a batch can’t pass, it stays out until it can.
Learn more
Full explanation
Measuring success
Measuring successthe metrics a customer will trust
- Metric
- % migrated
- What it tells the customer
- Concrete progress against the total - the burn-down they can watch.
- Metric
- Defects introduced
- What it tells the customer
- Bugs or regressions traced to the migration - the honest cost.
- Metric
- Reviewer time saved
- What it tells the customer
- Hours the automation removed vs. doing it by hand - the ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition..
- Metric
- Rollbacks / reverts
- What it tells the customer
- How often a batch had to be undone - the stability signal.
| Metric | What it tells the customer |
|---|---|
| % migrated | Concrete progress against the total - the burn-down they can watch. |
| Defects introduced | Bugs or regressions traced to the migration - the honest cost. |
| Reviewer time saved | Hours the automation removed vs. doing it by hand - the ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition.. |
| Rollbacks / reverts | How often a batch had to be undone - the stability signal. |
Report these proactively. A customer trusts the engineer who shows defects introduced, not the one who hides them.
“I’d pilot the migration on one module to nail the recipe, encode it as agent instructions plus a rules entry, then roll out in 20-file batches. Every batch has to type-check, pass the affected tests and get a human diff review before merge and each is a separate revertible PR. I’d report percent migrated, defects introduced and reviewer hours saved each week, so the customer sees both the progress and the cost.”
What this looks like at real scalegrind mode and cloud agents on big repos
For the longest, hardest transformations, Cursor’s grind-until-done mode (in beta) lets a cloud agent grind for hours - or as long as needed - on work like a big migration or a from-scratch build. Most jobs don’t need it: toggling a cloud agent on and asking “implement this feature” already does well. Reserve grind mode for the genuinely long horizon, and don’t overuse it.
Dependency-manager migration run as one long autonomous job.
Mechanical and repo-wide - the kind of recipe you pilot once, then batch.
A library/version upgrade across the codebase.
AST-aware for the call/signature changes, model only where judgment is needed.
A researcher built a Chrome-level browser across thousands of commits in grind mode.
The from-scratch end of the long-horizon spectrum.
Demoed on Grafana - roughly 2 million-plus lines and 30,000 files - enabled by sub-agents and semantic indexing, so the agent never tries to read the whole tree at once.
Given only a ticket id (GRAPH-59) plus scope and acceptance criteria, the agent figured out how to test the feature itself and shipped in about an hour what an experienced engineer had estimated would take weeks. For slow repos like Grafana, save the built environment as a team snapshot so new agents start from it instead of rebuilding.