# Abhängigkeiten mit KI aktualisieren ohne kaputten Build

URL: https://agentvera.dev/de/blog/upgrade-dependencies-with-ai/ · Veröffentlicht: 2026-10-27

Abhängigkeiten mit KI-Agenten sicher aktualisieren: npm outdated sortieren, ein Major pro Branch, Migrationsguide lesen, Codemods, Tests und Dependabot-PRs fixen.

**Kurz gesagt:**

- Starte mit einer Bestandsaufnahme: npm outdated, pnpm outdated oder pip list --outdated, dazu npm audit; dann sortiert der Agent jedes Update in Patch, Minor und Major mit einer Risikonotiz.
- Patch- und Minor-Updates bündelst du in einem Branch, aber jedes Major-Upgrade bekommt einen eigenen Branch oder Worktree; zuerst wird der Migrationsguide gelesen und der offizielle Codemod ausgeführt.
- Testsuite, Typprüfung und Build sind der Beweis. Verbiete, Tests anzupassen, damit sie grün werden, committe die Lockfile und prüfe ihren Diff.
- Dependabot und Renovate öffnen die PRs; ein Agent liest auf diesem Branch das fehlgeschlagene CI-Log, repariert den Code und pusht. Genau dort sparst du die meiste Zeit.

**Um Abhängigkeiten mit KI zu aktualisieren, überlässt du dem Agenten das Lesen und die repetitiven Änderungen und behältst die Sicherheitsregeln für dich: ein Major-Upgrade pro Branch, der Migrationsguide wird vor jeder Codeänderung gelesen, und die Testsuite ist der einzige Beweis, dass es funktioniert hat.** Coding-Agenten wie Claude Code, Codex und Gemini CLI sind gut im mühsamen Teil von Upgrades: eine API in achtzig Dateien umbenennen, das Test-Setup an einen neuen Runner anpassen, einen kryptischen Peer-Dependency-Fehler erklären. Bei einer Sache, die hier sehr wichtig ist, sind sie schlecht: Sie erinnern sich an die alte Version der Bibliothek.

Diese Anleitung zeigt einen Ablauf, der für eine kleine App genauso funktioniert wie für ein großes Monorepo: Bestandsaufnahme, Einordnung, die einfachen Updates bündeln, die schwierigen isolieren, Codemods, Lockfiles, Verifikation, Bot-PRs und Sicherheitshinweise. Die Beispiele nutzen npm und pnpm, mit Python-Entsprechungen, wo es Unterschiede gibt.

## Warum Dependency-Upgrades mit Agenten schiefgehen

Upgrades wirken einfach, und genau deshalb gehen sie schief. Die typischen Fehlerbilder:

- **Veraltetes Wissen.** Die Trainingsdaten eines Modells enden irgendwann. Bitte es, auf eine Version zu wechseln, die danach erschienen ist, und es schreibt selbstbewusst Code für die Version, die es kennt.
- **Ausufernder Umfang.** Aus „React aktualisieren“ werden React, der Router, die Testbibliothek, ESLint und drei Plugins, alles in einem Diff.
- **Torpfosten verschieben.** Nach dem Upgrade schlägt ein Test fehl, also aktualisiert der Agent den Snapshot, lockert die Assertion oder überspringt den Test.
- **Den Installer zum Schweigen bringen.** Ein Peer-Dependency-Konflikt wird mit `--force` oder `--legacy-peer-deps` „behoben“, statt Versionen zu finden, die wirklich zusammenpassen.
- **Lockfile-Chaos.** Der Agent löscht die Lockfile, damit ein Installationsfehler verschwindet, und Hunderte transitive Pakete ändern sich auf einmal.

Jeder Schritt unten ist dazu da, eines davon zu verhindern.

## Schritt 1: Bestandsaufnahme machen

Fang mit Fakten an, nicht mit einem Prompt wie „aktualisiere alles“. Jedes Ökosystem hat einen eingebauten Befehl, der auflistet, was veraltet ist:

```bash
npm outdated            # Current, Wanted (highest in your range) and Latest
pnpm outdated           # add -r in a workspace
pip list --outdated     # for the active Python environment
```

Dazu die Sicherheitsansicht:

```bash
npm audit
pip-audit               # PyPA tool: pip install pip-audit
```

Dann gibst du die Ausgabe an den Agenten und bittest um eine Einordnung, nicht um Änderungen:

```text
Hier ist die Ausgabe von npm outdated und npm audit. Ändere noch nichts.
Erstelle eine Tabelle mit: Paket, aktuell, wanted, latest, Update-Typ
(Patch/Minor/Major), ob es eine direkte oder eine Dev-Abhängigkeit ist, und
einem Link zum Changelog oder zur Releases-Seite. Markiere alles mit einem
Sicherheitshinweis. Schlag dann eine Reihenfolge vor: was gebündelt werden
kann und was einen eigenen Branch braucht.
```

Das ist eine reine Lese-Aufgabe, also kannst du sie gefahrlos in einem Planungsmodus oder mit einer Nur-Lesen-Berechtigung ausführen. Die Tabelle wird dein Plan und zeigt dir früh, welche Upgrades wirklich groß sind.

## Schritt 2: die einfachen Updates bündeln

Patch- und Minor-Versionen sollen abwärtskompatibel sein. In der Praxis sind sie das meistens, und die Testsuite fängt den Rest ab. Erledige sie gemeinsam auf einem Branch:

```bash
git switch -c deps/minor-patch
npm update              # stays inside the ranges in package.json
```

Mit pnpm macht `pnpm update` dasselbe, mit `pnpm update --interactive` wählst du aus, und `pnpm update --latest` geht auch über Major-Versionen hinweg, also heb dir das für Schritt 3 auf. Dann:

```text
Führe die komplette Testsuite, die Typprüfung und den Build aus. Wenn etwas
fehlschlägt, finde heraus, welches Paket es verursacht hat, und repariere
den Code, nicht die Tests. Wenn ein Fix mehr als ein paar Zeilen braucht,
setz genau dieses Paket auf seine vorherige Version zurück und liste es für
ein separates Upgrade.
```

Der letzte Satz ist wichtig. Er hält das Bündel klein und langweilig und schiebt alles Überraschende in einen eigenen Branch.

## Schritt 3: ein Major-Upgrade pro Branch

Eine Major-Version bedeutet per Definition Breaking Changes. Gib jeder einen eigenen Branch und, wenn du mehrere gleichzeitig laufen lassen willst, einen eigenen Ordner mit einem [Git-Worktree](/de/glossary/git-worktree/ "Was ist ein Git-Worktree"):

```bash
git worktree add ../app-vite -b deps/vite-major
git worktree add ../app-eslint -b deps/eslint-major
```

Jetzt aktualisiert ein Agent das Build-Tool, ein anderer den Linter, und dein Hauptordner bleibt unberührt. Wenn ein Upgrade zum Sumpf wird, löschst du diesen Worktree samt Branch und verlierst sonst nichts. [Git-Worktrees für parallele Agenten](/de/blog/git-worktree-parallel-agents/ "Git-Worktrees für parallele Agenten") erklärt das Setup ausführlicher.

Zwei Regeln für Majors:

- **Immer nur ein Major-Schritt.** Von Version 3 auf 6 in einem Sprung stapelt drei Sätze Breaking Changes in einem Diff. Geh von 3 auf 4, bring alles auf Grün, committe, dann 4 auf 5.
- **Zusammengehörige Pakete gemeinsam aktualisieren, und sonst nichts.** Ein Framework und seine offiziellen Plugins müssen oft im Gleichschritt wechseln. Das ist in Ordnung. Pakete ohne Bezug warten.

## Schritt 4: den Migrationsguide lesen, bevor Code angefasst wird

Dieser Schritt löst das Problem mit dem veralteten Wissen. Bevor der Agent irgendetwas bearbeitet, soll er die echte Dokumentation genau der Version lesen, auf die du wechselst:

```text
Wir aktualisieren eslint von 8 auf 9. Bevor du irgendeine Datei bearbeitest:
1. Lies den offiziellen Migrationsguide und den Changelog für 9.0.0.
2. Liste jede Breaking Change auf, die dieses Repo betrifft, mit den
   betroffenen Dateien (durchsuche den Code, um es zu bestätigen).
3. Sag, was du für jede einzelne tun wirst.
Nutze die Docs und Typdefinitionen des installierten Pakets als Quelle der
Wahrheit, nicht deine Erinnerung an ältere Versionen. Warte auf mein OK.
```

Wenn dein Agent im Web suchen kann, holt er sich den Guide selbst; wenn nicht, füge die relevanten Teile ein oder verweise ihn auf die Release Notes in `node_modules/<package>/CHANGELOG.md`, falls das Paket eine mitliefert. Auch ein MCP-Server für Dokumentation hilft hier; siehe [die besten MCP-Server fürs Programmieren](/de/blog/best-mcp-servers-for-coding/ "Die besten MCP-Server fürs Programmieren").

Die Liste, die er erstellt, ist später auch deine Review-Checkliste: Jeder Punkt sollte einer Änderung im Diff entsprechen.

## Schritt 5: den Codemod zuerst laufen lassen

Viele Frameworks liefern Codemods: Skripte, die Code mechanisch für eine neue Version umschreiben. Ein Codemod ist deterministisch, der Agent nicht. Also lass den Codemod alles erledigen, was er kann, und gib dem Agenten den Rest.

Zwei bekannte Beispiele:

```bash
# Next.js: upgrades Next.js, React and React DOM and runs the codemods
npx @next/codemod upgrade major

# Angular: updates packages and runs their migrations
ng update @angular/core @angular/cli
```

Stand Oktober 2026 weist die Next.js-Dokumentation darauf hin, dass `@next/codemod upgrade` nicht interaktiv läuft und alle Standardwerte übernimmt, wenn stdin kein Terminal ist, und genau das ist der Fall, wenn ein Agent ihn ausführt. Wenn du selbst wählen willst, welche Codemods angewendet werden, führe ihn zuerst selbst aus und gib das Ergebnis an den Agenten.

Nach dem Codemod committest du und bittest den Agenten, die restlichen Punkte aus Schritt 4 zu erledigen: die Fälle, die der Codemod markiert oder übersprungen hat, eigene Wrapper um die alte API, das Test-Setup und Konfigurationsdateien. Wenn Codemod-Ausgabe und Agenten-Änderungen in getrennten Commits liegen, ist das Review viel einfacher. Dieselbe Idee gilt für größere Migrationen; [Legacy-Code mit KI refaktorieren](/de/blog/refactor-legacy-code-with-ai/ "Legacy-Code mit KI refaktorieren") und [JavaScript mit KI zu TypeScript migrieren](/de/blog/migrate-javascript-to-typescript-with-ai/ "JavaScript mit KI zu TypeScript migrieren") gehen tiefer auf schrittweise Migrationen ein.

## Schritt 6: die Lockfile als Teil der Änderung behandeln

Die Lockfile sorgt dafür, dass „läuft bei mir“ überhaupt etwas bedeutet. Ein paar Regeln, die in `AGENTS.md` oder `CLAUDE.md` gehören:

```markdown
## Abhängigkeiten
- Lösche niemals package-lock.json / pnpm-lock.yaml, um einen Installationsfehler zu beheben.
- Nutze --force oder --legacy-peer-deps nicht, ohne zu fragen.
- Installiere in CI mit npm ci; committe die Lockfile zusammen mit der Änderung an package.json.
- Füge während einer Upgrade-Aufgabe keine neuen Abhängigkeiten hinzu.
```

Wenn eine Installation an Peer-Dependencies scheitert, bitte den Agenten, den Konflikt zu erklären, statt ihn zu erzwingen. `npm explain <package>` (Alias `npm why`) zeigt, warum ein Paket im Baum ist und wer welche Version verlangt; `npm ls <package>` zeigt jede Kopie. Oft ist der eigentliche Fix, das Plugin zu aktualisieren, das den alten Peer festnagelt, und das gehört in denselben Branch.

Schau dir beim Review auch den Diff der Lockfile an. Ein Minor-Sprung einer einzigen direkten Abhängigkeit, der dreihundert transitive Einträge ändert, verdient eine Nachfrage.

## Schritt 7: mit deinen eigenen Checks verifizieren

„Es lässt sich installieren“ heißt nicht fertig. Definiere fertig im Prompt, so dass der Agent es prüfen kann:

```text
Fertig heißt: npm ci läuft durch, npm test besteht, tsc --noEmit besteht,
npm run build besteht, und keine bestehende Testdatei wurde geändert, außer
wo der Migrationsguide es verlangt (erkläre jede einzelne).
```

Wenn deine Testsuite rund um die Bibliothek, die du aktualisierst, dünn ist, schreib zuerst ein paar Tests auf der alten Version und halte sie während des Upgrades grün. Bei UI-Bibliotheken findet ein kurzer Check in einem echten Browser, was Unit-Tests übersehen: Ein Agent mit Browser kann die Hauptseiten öffnen und Konsolenfehler melden. Bei Build-Tools vergleichst du die Größe der Build-Ausgabe vorher und nachher; ein doppelt so großes Bundle ist ein Bug, auch wenn jeder Test besteht.

Prüfe den Diff mit drei Fragen: Hat sich ein Test geändert, hat sich öffentliches Verhalten geändert, und entspricht jede Änderung einem Punkt auf der Liste der Breaking Changes?

## Bot-PRs: Dependabot und Renovate plus ein Agent

Dependabot und Renovate öffnen zuverlässig Upgrade-PRs nach Zeitplan. Was sie nicht können, ist den Code reparieren, wenn das Upgrade etwas kaputt macht. Diesen Teil kann ein Agent übernehmen.

Eine minimale Dependabot-Konfiguration, die die einfachen Updates in einem PR bündelt:

```yaml
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      minor-and-patch:
        update-types:
          - "minor"
          - "patch"
```

Das Renovate-Pendant startet mit dem empfohlenen Preset:

```json
{
  "extends": ["config:recommended"],
  "packageRules": [
    { "matchUpdateTypes": ["minor", "patch"], "groupName": "minor and patch" }
  ]
}
```

Wenn ein Bot-PR rot wird, sieht die Schleife so aus:

```bash
gh pr checkout 123
gh pr checks 123              # find the failing run
gh run view <run-id> --log-failed   # the log of its failed jobs
```

```text
Das ist ein Dependabot-PR, der zod auf das nächste Major hebt. CI schlägt mit
dem Log unten fehl. Finde die Ursache, lies die Release Notes der neuen
Version und repariere unseren Code, damit er mit der neuen Version läuft.
Pinne nicht die alte Version und ändere keine Tests, um den Fehler zu
verstecken. Führe die Tests lokal aus und fasse die Änderung zusammen,
bevor du pushst.
```

Ein Detail: Sobald du eigene Commits auf einen Dependabot-Branch pushst, rebaset Dependabot diesen PR nicht mehr automatisch, und `@dependabot recreate` würde deinen Fix verwerfen. Merge ihn bald oder rebase ihn selbst. Die allgemeine Version dieser Schleife findest du in [CI-Fehler mit KI automatisch beheben](/de/blog/auto-fix-ci-failures-with-ai/ "CI-Fehler mit KI automatisch beheben").

## Sicherheitshinweise

`npm audit` listet bekannte Schwachstellen in deinem Abhängigkeitsbaum. Ein paar Dinge halten es nützlich:

- **Konzentrier dich auf das, was ausgeliefert wird.** `npm audit --omit=dev` lässt Dev-Abhängigkeiten weg, und `--audit-level=high` lässt den Befehl erst bei hohem oder kritischem Schweregrad fehlschlagen, was eine sinnvolle CI-Schranke ist.
- **`npm audit fix` vs. `--force`.** Ein einfaches `audit fix` bleibt innerhalb deiner deklarierten Bereiche. Mit `--force` kann es Semver-Major-Versionen installieren; behandle das wie ein Upgrade aus Schritt 3, nicht wie einen schnellen Fix.
- **Transitive Pakete.** Wenn das verwundbare Paket tief im Baum steckt und sein Elternpaket noch keinen Fix veröffentlicht hat, kann das Feld `overrides` in `package.json` (oder `pnpm.overrides` bei pnpm) eine gepatchte Version erzwingen. Bitte den Agenten, einen Kommentar oder ein Issue mit der Begründung anzulegen, damit der Override später wieder entfernt wird.
- **Frag, ob es erreichbar ist.** Lass den Agenten prüfen, ob dein Code die verwundbare Funktion überhaupt nutzt. Das heißt nicht, dass du den Fix auslässt, aber es zeigt dir, ob er heute dringend ist oder ins wöchentliche Bündel kann.

Für Python meldet `pip-audit` dieselbe Art von Befunden für eine Umgebung oder eine `requirements.txt`, und `pip-audit --fix` versucht, die betroffenen Pakete zu aktualisieren. Die größere Frage, was Agenten selbst installieren dürfen, behandelt [Sicherheit von KI-Coding-Agenten](/de/blog/ai-coding-agent-security/ "Sicherheit von KI-Coding-Agenten").

## Häufige Fehler

- **„Aktualisiere alle Abhängigkeiten auf latest“ in einem Prompt.** Du bekommst einen riesigen Diff und keine Möglichkeit, ihn zu bisecten.
- **Den Migrationsguide überspringen.** Der Agent schreibt Code für die Version, die er kennt.
- **Tests stillschweigend ändern lassen.** Ein aktualisierter Snapshot ist in Ordnung, wenn der Guide die Änderung erklärt; sonst versteckt er eine Regression.
- **Den Installer zwingen.** `--force` heute ist eine kaputte Installation für die nächste Person.
- **Parallele Upgrade-Branches mergen, ohne sie zusammen zu testen.** Zwei grüne Branches können zusammen rot sein; eine [Merge-Queue](/de/blog/merge-queue-for-ai-agents/ "Merge-Queue für KI-Agenten") testet jeden auf dem neuesten Stand von main.

## So geht es in AgentVera

AgentVera ist eine Desktop-App, die Coding-Agent-CLIs wie Claude Code, Codex und Gemini CLI nebeneinander ausführt, mit eingebautem Git. Einige Funktionen passen direkt zu diesem Ablauf:

- **Ein Worktree pro Major-Upgrade.** Lege im [Git-Panel](/de/features/git-and-github/ "Git und GitHub") einen Worktree an und starte darin mit einem Klick einen Agenten; das Vite-Upgrade läuft in einem Pane, das ESLint-Upgrade in einem anderen.
- **Eine wöchentliche Dependency-Regel.** [Automatisierungen](/de/features/automations/ "Automatisierungen") (Pro) können einen Agenten per Cron-Zeitplan in einem eigenen Worktree starten. Eines der eingebauten Playbooks ist „Abhängigkeiten aktualisieren (nur Minor und Patch)“, und das Ergebnis kann als PR landen oder in die Merge-Queue gehen.
- **Rote CI an einen Agenten.** Die [CI/CD-Zentrale](/de/features/ci-cd-center/ "CI/CD-Zentrale") listet Läufe von GitHub Actions, GitLab CI und Jenkins; bei einem fehlgeschlagenen Lauf öffnet „Mit einem Agenten beheben“ einen Claude-Agenten mit den Laufdetails und dem Log-Ende von bis zu drei fehlgeschlagenen Jobs. Eine Automatisierung kann außerdem einen Agenten starten, wenn die CI auf ausgewählten Branches rot wird.
- **Gegen deine Definition von fertig prüfen.** Schreib „Tests, Typprüfung und Build bestehen; keine Testdatei geändert“ in deine Nachricht. [Verify](/de/features/verify/ "Verify") macht daraus Kriterien, und am Ende des Turns prüft ein separater Verifier, der keine Dateien bearbeiten kann, jedes einzelne mit Belegen.
- **Review und Merge-Queue.** Das [Code-Review](/de/features/code-review/ "Code-Review") liest mit einem zweiten Modell, was der Agent geändert hat, und die [Merge-Queue](/de/features/merge-queue/ "Merge-Queue") bringt Upgrade-Branches nacheinander auf den neuesten Stand des Ziels, wobei dein Check-Befehl auf dem gemergten Ergebnis läuft.

## Fazit

Abhängigkeiten mit KI zu aktualisieren funktioniert, wenn du die Arbeit klein schneidest: zuerst die Bestandsaufnahme, einfache Updates in einem Bündel, jedes Major auf einem eigenen Branch, der Migrationsguide vor der ersten Änderung, der Codemod vor dem Agenten und die Tests als Richter. Der Agent nimmt dir das Lesen und die hundert kleinen Änderungen ab; der Prozess hält diese Änderungen ehrlich. Wenn das Upgrade erledigt ist und du die App auch schneller machen willst, lies [Code-Performance mit KI optimieren](/de/blog/optimize-code-performance-with-ai/ "Code-Performance mit KI optimieren").

Um es an deinem eigenen Repo auszuprobieren, [lade AgentVera herunter](/de/download/ "AgentVera herunterladen").

## Häufige Fragen

**Kann ein KI-Agent meine Abhängigkeiten selbstständig aktualisieren?** Bei Patch- und Minor-Updates mit einer guten Testsuite weitgehend ja: Er führt das Update, die Tests und den Build aus und behebt kleine Brüche. Bei Major-Versionen sollte er nach dem offiziellen Migrationsguide arbeiten, ein Paket pro Branch, und du prüfst den Diff vor dem Merge.

**Warum nutzt der Agent beim Upgrade einer Bibliothek alte APIs?** Seine Trainingsdaten sind älter als die Version, auf die du wechselst, also erinnert er sich an die vorherige API. Lass ihn zuerst Changelog und Migrationsguide genau dieser Zielversion lesen und sag ihm, dass die installierten Typdefinitionen und Docs mehr zählen als sein Gedächtnis.

**Sollte ich alles auf einmal aktualisieren?** Nein. Fasse Patch- und Minor-Updates zusammen, aber gib jedem Major-Upgrade einen eigenen Branch. Wenn fünf Majors in einem Diff landen und die Tests fehlschlagen, kann niemand sagen, welches Paket schuld ist.

**Ist npm audit fix --force sicher?** Nicht blind. Laut npm-Dokumentation erlaubt --force, dass audit fix Versionen außerhalb deiner deklarierten Bereiche installiert, auch Semver-Major-Sprünge. Behandle es wie jedes andere Major-Upgrade: auf einem eigenen Branch, mit ausgeführten Tests und geprüftem Diff.

**Wie lasse ich einen Agenten einen fehlschlagenden Dependabot-PR reparieren?** Checke den PR-Branch aus, gib dem Agenten das fehlgeschlagene CI-Log (zum Beispiel aus gh run view --log-failed), bitte um die Ursache und einen Fix, der die neue Version behält, führe die Tests lokal aus und pushe dann. Sobald du eigene Commits pushst, rebaset Dependabot diesen PR nicht mehr automatisch.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/