Automated dependency upgrades & large-scale codebase refactoring

Every organisation with more than a handful of repositories accumulates outdated runtimes, frameworks and libraries. Upgrades are tedious, repetitive and always deferred until a vulnerability or end-of-support date forces them. The modern answer combines deterministic code-transformation recipes (abstract-syntax-tree rewrites) with LLM agents that handle the long tail, and opens pull requests that are merged only after CI passes. The result is maintenance as a continuous background process rather than an annual project.

Problem & value

• Today: developers read migration guides, bump versions by hand, fix compile errors and failing tests, repeat the work for each repository, and often postpone it. Bots such as Dependabot and Renovate bump versions but cannot adapt source code to breaking API changes.
• AI value: the agent (or recipe) makes the source changes that a version bump requires, runs build and tests, iterates on failures and documents the result. Central teams can roll out an organisation-wide change (e.g. replace a logging library, move to a new auth SDK) across hundreds of repositories instead of asking every team to do it.
• Drivers: end-of-support dates for runtimes (e.g. Java LTS versions, Python and Node.js releases), vulnerable transitive dependencies, and in the EU the Cyber Resilience Act, which requires manufacturers of products with digital elements to handle vulnerabilities and provide security updates through the support period [1].

Variants

• Dependency hygiene: automated version bumps, lockfile updates, transitive-vulnerability patching, grouped PRs.
• Framework and runtime upgrades: Java 8/11 to 17/21, Spring Boot 2 to 3 (javax to jakarta), JUnit 4 to 5, Python 3.x bumps, Angular/React major versions, .NET Framework to modern .NET.
• Fleet-wide campaigns and deprecated-API removal: org-wide SDK/logging changes, new language features, replace deprecated calls, adopt new language features, migrate test frameworks.

How it works

1. inventory (all repos, build files, SBOM, dependency graph)
2. select campaign (target version / policy / advisory)
3. deterministic recipes (OpenRewrite-style AST rewrites, codemods) applied per repo
4. LLM agent for residual errors (compile failures, test failures, custom APIs)
5. build + tests + static analysis in CI (sandboxed)
6. PR with change summary, risk notes, link to migration guide
7. human review / auto-merge by policy
8. fleet dashboard, retry failed repos

• Recipes first: deterministic, repeatable transformations over a lossless semantic tree of the code (OpenRewrite) are cheap, auditable and do not hallucinate. They cover the known, mechanical part of a migration [2].
• LLM second: an agent reads compiler and test output, searches the repository and documentation, and patches what recipes cannot (project-specific wrappers, behavioural changes, flaky tests). Some tools also let an LLM author a new recipe once and then apply it everywhere.
• Verification loop: build and tests are the oracle. Without meaningful tests, an upgrade can compile and still change behaviour, so test coverage (see CODE-004) is a precondition.
• Human-in-the-loop: policy defines which PRs auto-merge (patch-level bumps with green CI) and which need review (major versions, security-sensitive modules, low test coverage).

Data preparation

The "data" here is mostly code: source repositories, build files and lockfiles, CI pipelines and test suites. In an SMB these live in GitHub/GitLab/Bitbucket, sometimes also on file shares or old SVN servers; the inventory of which repositories exist is often missing.

Typical gaps: repositories without automated tests (the biggest blocker, because the upgrade cannot be verified), unpinned or inconsistent dependency versions, broken or slow CI, forgotten forks, no list of owners per repository, and secrets inside code.

Preparation steps: 1. Inventory all repositories and name an owner for each (PREP-004). 2. Make builds reproducible: lockfiles, container builds, one CI pipeline per repository. 3. Add a minimum test baseline (smoke tests) to the most critical repositories before the first agent run. 4. Define an upgrade policy (target versions, banned libraries) as machine-readable config. 5. Remove secrets from code and restrict the bot's token rights.

Tools: SBOM generators, OSV-Scanner, Renovate/Dependabot configuration. Share of effort: low, roughly 10 to 20 percent of the project, but missing tests can turn it into the main task. See also GUIDE-003 and PREP-005 for exports from legacy systems.

Implementation paths

Which path for whom

• smb (A): Renovate, Dependabot or Copilot-style upgrade agents are mature, cheap and need no own integration for a handful of repositories.
• enterprise (B): With hundreds of repositories, own policies and CI, a custom fleet orchestrator (recipes plus LLM agent via API) fits better than per-seat products.
• developer (C): Self-hosted Renovate and OpenRewrite with a local open-weight code model keep source code on your own machine at no licence cost.
• public (C): Authorities should run Renovate/OpenRewrite on their own GitLab with a sovereign or local model, as source code and procurement rules limit SaaS use.

Path A — Buy (recommended for most organisations)

• Recipe plus platform: Moderne (platform around OpenRewrite, mass PRs and impact search across repositories; also offers an agent tooling layer) [2]. OpenRewrite itself is open source; the commercial platform adds scale, SaaS or on-prem runs and dashboards.
• Cloud-vendor agents: AWS Transform / Amazon Q Developer transformation for Java version upgrades and .NET modernisation [3]; Google and Microsoft offer comparable upgrade assistants (e.g. GitHub Copilot app modernization for Java and .NET).
• Dependency bots: GitHub Dependabot, Renovate (Mend; open source) for the version-bump layer [4].
• Coding agents: Claude Code, Copilot coding agent, Codex, Cursor, Devin suit single repos, less governed fleet campaigns.
• EU options: few dedicated EU vendors; JetBrains (CZ) offers IDE refactoring, GitLab self-managed runs in EU; check data residency (EU regions, on-prem runners).

Path B — Build on cloud APIs

• Orchestrate your own agent: a frontier code model (Claude, GPT, Gemini, Mistral Codestral/Devstral via EU-hosted Mistral API) in a sandbox with checkout, build, test and search tools, triggered by Renovate/Dependabot events or a campaign scheduler.
• Combine with OpenRewrite recipes as tools the agent can call, and with a repository graph or code-search index (Sourcegraph, tree-sitter based) for impact analysis.
• Integrate with GitHub/GitLab/Bitbucket APIs for PR creation, and with CI for the oracle.

Path C — Self-host (open source)

• Recipes and bots: OpenRewrite (check licence per recipe module), Renovate (self-hosted), Dependabot (GitHub Enterprise Server), jscodeshift, Rector (PHP), libcst/pyupgrade and go fix/gopls modernizers.
• Models: open-weight code models such as Qwen3-Coder, Devstral, DeepSeek-Coder-V3-class or gpt-oss, served with vLLM or Ollama; agent harnesses such as OpenHands, Aider, Cline.
• Hardware: HW2 for ~30B-class models on residual fixes; HW3/HW4 for stronger agentic models. Sandboxed CI runners are the bigger operational cost than the GPU.

Path D — Custom training

Rarely justified; custom recipes and better tests usually beat fine-tuning on accepted PRs.

State of the art (2026)

• Hybrid wins: deterministic recipes for the bulk, LLM agents for the remainder, CI as the judge. Pure LLM upgrades are more expensive, less repeatable and prone to silent behavioural changes.
• Agentic upgrade products from cloud vendors now handle multi-step Java and .NET upgrades with build-and-test loops; results vary strongly with test quality and dependency complexity [3].
• Agent tooling for recipes: vendors expose recipe catalogues and semantic code search to third-party coding agents (e.g. via MCP), so general agents can use precise, large-scale tools [2].
• Outdated knowledge: models often emit outdated APIs; retrieving current release notes helps.
• Limits and failure modes: behavioural regressions not covered by tests, hallucinated or non-existent package versions (also a supply-chain risk via "slopsquatting"), unreviewed transitive upgrades, flaky tests misread as upgrade failures, PR floods overloading reviewers, and licence changes in new versions.

Shared resources & combinations

• Same stack (llm-code + agent-framework + sandboxed CI): CODE-002 coding agents, CODE-014 bug fixing, CODE-005 legacy modernisation share agent harness and sandbox runners.
• Upstream: CODE-004 test generation raises coverage before an upgrade campaign; CODE-006 documentation helps agents understand internal frameworks.
• Downstream: CODE-003 AI code review for the generated PRs; SEC-004 for vulnerability-driven upgrades; CODE-009 for Terraform provider and Kubernetes manifest upgrades.

Effort, cost & KPIs

• Path A: days to weeks for a pilot on a few repositories; licence per repository or per line of code, or cloud-agent pricing per lines transformed (check vendor pricing pages).
• Path B: 1-3 months for a governed pipeline; cost drivers are tokens per repository, CI minutes and reviewer time.
• Path C: 2-4 months including sandbox runners and model serving.
• KPIs: share of repositories on supported runtime/framework versions, mean age of dependencies, time to patch a critical advisory, PR merge rate without manual edits, CI pass rate of generated PRs, reviewer minutes per PR, regressions traced to automated PRs.

People & change

Involve early: management (budget, risk appetite) and the department lead of engineering decide scope. IT and IT security set bot permissions, token scopes and the allowed model endpoints; legal/compliance checks licence rules for suggested libraries. End users are the developers who review the pull requests, so involve them from the first pilot day.

Works council: no, usually. The bot changes code, not employee behaviour, and does not rate individuals. If dashboards start to show per-developer merge or review statistics, §87(1) no. 6 BetrVG applies. Inform the council anyway under §90(1) no. 3 BetrVG when work processes change; public bodies inform the Personalrat. A DPO/DPIA is normally not needed because no personal data is processed beyond commit author names.

AI literacy: support developers' skills (Art. 4 AI Act) with a short session on reviewing AI-generated diffs and on prompt-injection risks from dependency changelogs (GUIDE-006, GUIDE-013).

Pilot and communication: start with 3 to 5 low-risk repositories and one volunteer team; publish the merge rate and the number of reverted PRs openly. Typical concern: "the bot breaks production." Answer: no auto-merge, CI must pass, a human approves every PR, rollback is one click. Frame it as removing a chore, not as replacing people (GUIDE-008, GUIDE-009).

Risks, regulation & compliance

• EU AI Act: minimal risk for developer tooling; AI literacy duty (Art. 4) applies. Code in safety-critical products stays under sector regimes (e.g. medical devices, machinery), where changes need documented verification regardless of who wrote them.
• Cyber Resilience Act and NIS2: promote timely updates and vulnerability handling; automated upgrades with traceable PRs and SBOM updates support the evidence trail [1].
• GDPR: source code may contain personal data (test fixtures, hard-coded emails, secrets). Use EU regions or self-hosting, a data processing agreement and secret scanning before sending code to external models.
• Security: agents run untrusted build scripts - isolate in ephemeral sandboxes without production credentials; pin and verify package names, hashes and provenance; prompt injection via release notes or READMEs is possible.
• Mitigations: merge only on green CI, staged rollout (canary repos), required human review for major bumps, audit log of agent actions.

Getting started

1. Build an inventory: repositories, languages, runtime/framework versions, SBOM, test coverage.
2. Turn on Renovate or Dependabot with grouped PRs and auto-merge for patch updates with green CI.
3. Pilot one campaign (e.g. Java 17 to 21 or Spring Boot 2 to 3) on 5-10 repositories with OpenRewrite recipes, then add an LLM agent for failures.
4. Define merge policy, sandbox rules and a dashboard for fleet status.
5. Expand campaign by campaign; record KPIs and the share needing manual work.

Sources

1. European Commission - Cyber Resilience Act - https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
2. OpenRewrite documentation - https://docs.openrewrite.org/
3. AWS - AWS Transform / Amazon Q Developer code transformation docs - https://docs.aws.amazon.com/transform/latest/userguide/what-is-service.html
4. Renovate documentation - https://docs.renovatebot.com/
5. GitHub Dependabot documentation - https://docs.github.com/en/code-security/dependabot
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj