upgrade a dependency without breaking the build
A package jumped a major (or three minors piled up) and you need the diff that still compiles — not a changelog essay.
recs
| model | best when | avoid when | cost vibe |
|---|---|---|---|
| Sonnet-class | The upgrade crosses a major, touches types/auth/build, or the breakage is spread across files. | It’s a patch bump with a green lockfile and no api change. | $$$ |
| Faster / cheaper cloud | Mechanical bumps: rename an import, fix a type that moved, update a config key. | The failure is “tests pass, behavior changed” and you need to notice. | $ |
| Local mid | Private repo, and the upgrade is mostly search-and-replace you can review. | You need it to read a long migration guide and apply only the parts that match this repo. | ~free |
why
- Upgrades fail quietly. The model that rewrites every call site is worse than the one that stops at the first real break.
- Cheap models are fine when the compiler tells them the answer. Frontier earns it when the compiler stays green and the app is wrong.
- Don’t let it bump the world. One dependency, one pr.
- Pair with test-generation if the old suite never covered the api you just changed.