Upgrade Copilot

The problem: Dependency upgrades stall inside teams not because upgrading is technically hard, but because assessing safety is slow and manual. Before bumping a version, someone has to read the changelog line by line, guess which breaking changes actually touch the codebase, grep for every call site, check whether those sites are even tested, and only then decide whether to proceed. That triage tax is why teams sit on outdated — sometimes vulnerable — dependencies for months, only upgrading once a CVE forces the issue. It's a maintenance workflow with high manual effort and high error risk: it's easy to miss a call site, and easy to assume "we probably don't use that function" without actually checking. The solution: Upgrade Copilot is a multi-agent workflow built in IBM Bob 2.0 that automates this entire triage process for a given dependency + target version. Given a project and an upgrade target, it: (1) reads the dependency's migration notes via document understanding to extract a structured list of breaking changes; (2) scans the codebase in parallel to find every call site touching that dependency; (3) cross-references the two — the key step existing tools skip — so a breaking change in a function the codebase never calls is correctly ignored, while a breaking change in a function it does call is flagged as real risk; (4) checks whether each at-risk call site has test coverage, flagging untested risk separately from tested risk; (5) drafts the actual code fix for each flagged site, and adds missing tests for previously-untested ones. Target users: engineering teams doing routine maintenance — the people who currently avoid dependency bumps because assessing them eats a day of manual work, and the people who inherit "big bang" upgrades once a security issue forces the question. How they interact with it: a developer opens their project in Bob, states the dependency and target version, and lets Bob's Plan mode explore the repo and migration docs to propose a task breakdown. Independent sub-tasks (fixing separate source files) run without depending on each other, while dependent steps (adding tests, bumping the manifest) run last, after the code fixes land. The developer reviews Bob's plan before handing it to Agent mode to execute, keeping a human decision point in the loop. What makes it unique: most AI dev-tool demos analyze a single repo in isolation — explain this codebase, review this PR, score this release. Upgrade Copilot instead targets a routine but chronically neglected maintenance task, and its core insight is the cross-reference step: correctly separating "breaking changes in the library" from "breaking changes that actually affect this specific codebase." That distinction is exactly the tedious, error-prone part a human currently has to do by hand — and it's the part that determines whether an upgrade takes an hour or a week. Demonstrated impact: on our sample project (10 lodash 3.x call sites, only 3 originally tested), Bob correctly identified all 10 breaking call sites, correctly separated tested from untested ones, and produced a full migration plan — in minutes, via a task decomposition and file-scan process that would otherwise take a developer significantly longer to do manually and with higher risk of missing a call site.