# Pair Programming mit KI: so arbeitest du mit Agenten

URL: https://agentvera.dev/de/blog/ai-pair-programming/ · Veröffentlicht: 2026-10-27

Ein praktischer Leitfaden zu Pair Programming mit KI: Driver- und Navigator-Rolle mit einem Agenten, Freigabemodi, kleine Schritte, Diffs reviewen, zwei Agenten als Paar.

**Kurz gesagt:**

- Pairing mit einem Agenten funktioniert wie klassisches Pair Programming: Eine Seite fährt und tippt, die andere navigiert und reviewt. Leg deine Rolle vor jeder Aufgabe fest, nicht mittendrin.
- Wähle den Freigabemodus nach dem Risiko: Bei fremdem oder riskantem Code reviewst du jeden Schritt, bei gut getestetem, gut verstandenem Code fährt der Agent mit automatisch akzeptierten Bearbeitungen.
- Halte Schritte klein, committe oder setz nach jedem einen Checkpoint, lies jeden Diff, und hol dir eine zweite Meinung, indem ein zweiter Agent reviewt, was der erste geschrieben hat.

Pair Programming mit KI ist dieselbe Praxis, die Entwickler seit Jahrzehnten nutzen, nur dass ein Platz von einem Coding-Agenten besetzt ist. Eine Seite fährt (Driver): Sie tippt den Code. Die andere navigiert (Navigator): Sie behält den Plan, achtet auf Fehler und entscheidet, was als Nächstes kommt. Der Unterschied: Ein Agent tippt viel schneller, als du lesen kannst, also ist das Schwierige nicht mehr das Schreiben von Code. Es ist, die Kontrolle darüber zu behalten, was geschrieben wird.

Dieser Leitfaden zeigt, wie du die Rollen mit einem Agenten aufteilst, wann du ihn allein fahren lässt und wann du jeden Schritt reviewst, wie die Freigabemodi in Claude Code, Codex und Gemini CLI zu dieser Entscheidung passen, wie du Schritte klein und Diffs lesbar hältst, wie du zum Lernen pairst statt nur zu delegieren und wie du zwei Agenten miteinander pairen lässt, während du navigierst. Befehlsnamen und Modi folgen der offiziellen Dokumentation mit Stand Oktober 2026.

## Driver und Navigator, mit einem Agenten auf einem Platz

Beim klassischen Pairing wechseln die Rollen oft. Mit einem Agenten gibt es zwei nützliche Setups.

**Du navigierst, der Agent fährt.** Das ist für die meiste Arbeit der Standard. Du beschreibst Ziel, Rahmenbedingungen und den nächsten Schritt; der Agent bearbeitet Dateien und führt Befehle aus; du liest, was er getan hat, und steuerst. Deine Aufgabe ist die eines guten Navigators: das große Ganze im Blick behalten, merken, wenn der Code in die falsche Richtung läuft, und ihn früh stoppen.

**Du fährst, der Agent navigiert.** Du schreibst den Code selbst und nutzt den Agenten als zweites Paar Augen. Bitte ihn, die Funktion zu reviewen, die du gerade geschrieben hast, Randfälle vorzuschlagen, herauszufinden, woher ein Wert kommt, oder den Test zu schreiben, bevor du den Code schreibst. Das ist langsamer, aber das richtige Setup, wenn du jede Zeile verstehen musst, etwa bei Code, den du allein pflegen wirst, oder wenn du eine neue Sprache lernst.

Leg das Setup fest, bevor du eine Aufgabe beginnst, und sag es im Prompt: „Ich schreibe den Parser, du reviewst jede Funktion, die ich einfüge, und listest Randfälle auf“ ist eine ganz andere Session als „Implementiere den Parser; halt nach jeder Funktion an, damit ich reviewen kann.“ Die Rollen mittendrin unausgesprochen zu wechseln ist der Weg zu Code, den niemand ganz versteht.

## Wann du ihn fahren lässt und wann du jeden Schritt reviewst

Die Frage ist nicht, ob du dem Agenten vertraust. Sie ist, wie teuer ein Fehler ist und wie schnell du ihn bemerken würdest. Eine einfache Faustregel:

| Situation | Vorgehen |
| --- | --- |
| Gut getesteter Code, klare Aufgabe, sauberer Git-Stand | Fahren lassen; den finalen Diff reviewen |
| Neues Feature in Code, den du kennst | Erst planen, dann in kleinen Schritten fahren lassen |
| Fremde Codebasis oder Bibliothek | Jeden Schritt reviewen |
| Datenbankmigrationen, Auth, Zahlungen, Löschvorgänge | Jeden Schritt und jeden Befehl reviewen |
| Alles, was Produktion oder geteilte Remotes berührt | Du führst es selbst aus |

Zwei Dinge machen es sicher, den Agenten fahren zu lassen: Tests, die fehlschlagen, wenn Verhalten kaputtgeht, und eine Möglichkeit zum Rückgängigmachen. Hast du beides, kostet ein falscher Weg ein paar Minuten. Hast du keins, reviewe jeden Schritt oder schreib zuerst Tests ([Unit-Tests mit KI schreiben](/de/blog/write-unit-tests-with-ai/ "Unit-Tests mit KI schreiben") zeigt, wie).

Ein guter Mittelweg für größere Aufgaben ist, zuerst zu planen. In Claude Code lässt der Plan Mode den Agenten lesen und einen Plan vorschlagen, ohne etwas zu bearbeiten; du reviewst den Plan, korrigierst ihn, wechselst dann den Modus und lässt ihn umsetzen. [Plan Mode in Claude Code](/de/blog/claude-code-plan-mode/ "Plan Mode in Claude Code") geht das durch. Einen Plan zu reviewen dauert eine Minute; eine falsche Implementierung zu reviewen dauert viel länger.

## Freigabemodi: wie viel der Agent ohne Nachfrage darf

Jedes große Coding-Agent-CLI hat eine Einstellung dafür, wie oft es anhält und dich fragt. Diese Einstellung ist dein Pairing-Stil als Konfiguration.

**Claude Code** hat Berechtigungsmodi, mit Stand Oktober 2026:

- `default`: fragt vor Dateibearbeitungen und vor Befehlen, die nicht schon erlaubt sind. Das ist jeden Schritt reviewen.
- `acceptEdits`: Dateibearbeitungen im Arbeitsverzeichnis sowie einfache Dateibefehle wie `mkdir` und `mv` werden ohne Nachfrage akzeptiert; andere Befehle fragen weiterhin.
- `plan`: liest und schlägt vor, bearbeitet nichts.
- `auto`: Ein Klassifikator im Hintergrund prüft jede Aktion und blockiert riskante, sodass der Agent seltener fragt. Die Verfügbarkeit hängt von deinem Tarif und Modell ab, und Admins können ihn abschalten.
- `bypassPermissions`: gar keine Prüfungen. Die Dokumentation empfiehlt ihn nur in isolierten Umgebungen wie Containern oder VMs.

Drück Shift+Tab, um während einer Session durch die Modi zu wechseln, starte mit `claude --permission-mode acceptEdits` oder setz `permissions.defaultMode` in den Einstellungen. Beantwortest du eine Nachfrage mit „Yes, and don't ask again“, wird die Regel gespeichert, sodass derselbe Befehl nicht mehr nachfragt. [Claude-Code-Berechtigungen](/de/blog/claude-code-skip-permissions/ "Claude-Code-Berechtigungen") erklärt das riskante Ende der Skala.

**Codex CLI** kombiniert eine Sandbox mit einer Freigaberichtlinie. Das Standard-Preset Auto lässt es innerhalb des Workspace bearbeiten und Befehle ausführen und fragt, bevor es ihn verlässt (`--sandbox workspace-write --ask-for-approval on-request`). Wechsle während einer Session mit `/permissions`, zum Beispiel auf Read Only, oder starte mit `--sandbox read-only`, wenn es nur schauen soll.

**Gemini CLI** hat `--approval-mode` mit `default` (fragen), `auto_edit` (Bearbeitungen akzeptieren, bei anderen Tools fragen), `plan` (nur lesen) und `yolo` (alles akzeptieren).

Eine praktische Zuordnung: Jeden Schritt reviewen heißt überall den Standardmodus. Den Agenten bei Routinearbeit fahren zu lassen heißt, Bearbeitungen zu akzeptieren, Shell-Befehle aber weiter freizugeben, denn bei Befehlen passieren die unumkehrbaren Dinge. Voll automatisch gehört in einen Container oder einen Wegwerf-Worktree, nie auf einen Rechner mit Produktionszugangsdaten.

## Kleine Schritte

Pairing funktioniert, weil jeder Schritt klein genug ist, um darüber zu sprechen. Mit einem Agenten zählt das noch mehr, denn er kann tausend Zeilen erzeugen, bevor du die ersten hundert gelesen hast.

- **Bitte um einen Schritt nach dem anderen.** „Füge die Validierungsfunktion und ihre Tests hinzu, dann halt an“ ist besser als „bau den Registrierungsablauf“.
- **Sag, wann er anhalten soll.** Agenten machen gern mit der nächsten naheliegenden Sache weiter. „Halt danach an und fass zusammen, was du geändert hast“ lässt dich das Tempo bestimmen.
- **Committe nach jedem grünen Schritt.** Ein Commit pro Schritt gibt dir einen sauberen Punkt zum Zurücknehmen und eine lesbare History. Mit `git add -p` prüfst du jeden Hunk auf dem Weg hinein.
- **Nutze Checkpoints für das Dazwischen.** In Claude Code setzt `/rewind` (oder zweimal Esc) Code und Unterhaltung auf einen früheren Prompt zurück. Änderungen durch Shell-Befehle erfasst es nicht, also bleibt Git dein eigentliches Sicherheitsnetz. [Änderungen von Claude Code rückgängig machen](/de/blog/undo-claude-code-changes/ "Änderungen von Claude Code rückgängig machen") behandelt beides.

Geht ein Schritt schief, mach ihn rückgängig und prompte neu mit dem, was du gelernt hast. Den Agenten seinen eigenen Fehltritt auf dem falschen Code reparieren zu lassen, richtet meist ein größeres Durcheinander an, als den Schritt neu zu beginnen.

## Diffs reviewen

Als Navigator ist der Diff dein wichtigstes Werkzeug. Lies ihn, bevor du den Schritt akzeptierst, nicht nach den nächsten drei.

```bash
git status
git diff --stat
git diff
```

In Codex zeigt `/diff` die aktuellen Änderungen innerhalb der Session. Jeden Agenten kannst du fragen: „Zeig mir den Diff deiner Änderungen und erkläre jeden Hunk in einer Zeile.“

Worauf du achtest, über die Frage hinaus, ob der Code funktioniert:

- **Umfang.** Geänderte Dateien, die nichts mit der Aufgabe zu tun haben. Umbenennungen, Neuformatierungen und „kleine Aufräumarbeiten“ verstecken echte Änderungen.
- **Gelöschte oder abgeschwächte Tests.** Eine Assertion, die an die neue Ausgabe angepasst wurde, oder ein als übersprungen markierter Test ist ein Warnsignal.
- **Stummgeschaltete Fehler.** Leere `catch`-Blöcke, `any`-Casts, abgeschaltete Lint-Regeln, `--force`-Flags.
- **Neue Abhängigkeiten.** Jede ist Code, den du jetzt pflegst.
- **Dinge, die du nicht erklären kannst.** Wenn du nicht sagen kannst, warum eine Zeile da ist, frag nach, bevor du sie akzeptierst.

Der Leitfaden zu [KI-Code-Review](/de/blog/ai-code-review/ "KI-Code-Review") geht tiefer darauf ein, wie du Agenten-Output in der Pull-Request-Phase reviewst.

## Lernen oder delegieren

Pairing mit einem Agenten kann dich bei Dingen schneller machen, die du schon kannst, oder dir Dinge beibringen, die du nicht kannst. Dafür brauchst du unterschiedliche Sessions.

**Wenn du delegierst,** zählt das Ergebnis. Gib klare Abnahmekriterien vor, lass den Agenten fahren, reviewe Diff und Tests. Das passt für Boilerplate, Migrationen und Code in Bereichen, die du schon verstehst.

**Wenn du lernen willst,** bremse bewusst:

- Bitte um einen Plan und eine Erklärung, bevor Code entsteht: „Erklär, wie du das angehen würdest und warum, schreib noch keinen Code.“
- Tipp die Kernlogik selbst und lass den Agenten sie reviewen.
- Frag bei seinen Entscheidungen „warum das und nicht jenes?“ und lass dir die Alternative zeigen.
- Bitte ihn, zuerst einen fehlschlagenden Test zu schreiben, und bring ihn dann selbst zum Bestehen.

Eine nützliche Gewohnheit: Wenn du ein Stück Code ohne den Agenten nicht neu schreiben könntest, hast du es noch nicht gelernt, sondern nur akzeptiert. Bei manchem Code ist das in Ordnung, aber es sollte eine Entscheidung sein, kein Zufall.

## Zwei Agenten als Paar: einer schreibt, einer reviewt

Die Navigator-Rolle kann auch ein zweiter Agent übernehmen. Ein Agent schreibt; ein anderer, idealerweise ein anderes Modell, damit sich ihre blinden Flecken unterscheiden, reviewt; du entscheidest, was umgesetzt wird.

Eine einfache Variante mit zwei CLIs im selben Repository:

```bash
# Terminal 1: Claude Code implements the step
claude "Add rate limiting to the /login route. Stop when tests pass."

# Terminal 2: Codex reviews the uncommitted changes
codex review --uncommitted
```

`codex review` kann auch gegen einen Basis-Branch (`--base main`) oder einen einzelnen Commit (`--commit <sha>`) reviewen, und innerhalb einer Session macht `/review` dasselbe. Füg die Befunde, denen du zustimmst, beim schreibenden Agenten ein und ignoriere die anderen: Der Output des Reviewers ist ein Rat für dich, keine Anweisung für den anderen Agenten.

Ein paar Regeln lassen das Pairing zwischen Agenten funktionieren:

- **Anderes Modell oder zumindest eine frische Session.** Ein Reviewer, der den Kontext des Schreibers teilt, stimmt ihm eher zu.
- **Der Reviewer bearbeitet nichts.** Lass ihn nur lesend laufen. Zwei Agenten, die gleichzeitig dieselben Dateien bearbeiten, sind ein Merge-Konflikt, kein Review.
- **Du bleibst der Navigator.** Leite den Review-Output nicht in einer endlosen Schleife direkt an den Schreiber weiter. Lies ihn, such die echten Probleme heraus und schick diese.
- **Schreib die Kriterien auf.** „Prüfe auf fehlende Eingabevalidierung, unbehandelte Fehler und geändertes Verhalten“ ergibt ein viel nützlicheres Review als „reviewe das“.

Bei größeren Aufgaben skaliert dasselbe Muster auf mehrere Schreiber in getrennten Worktrees mit einem Reviewer; das behandelt [KI-Agenten-Teams](/de/blog/ai-agent-team/ "KI-Agenten-Teams").

## So geht es in AgentVera

AgentVera führt Claude Code, Codex, Gemini CLI und andere CLI-Agenten nebeneinander in einem Fenster aus, sodass beide Pairing-Setups in eine Ansicht passen.

- **[Workspace](/de/features/workspace/ "Workspace").** Leg den schreibenden und den reviewenden Agenten in Panes nebeneinander auf dasselbe Projekt. Jeder Agent hat seine eigene Berechtigungseinstellung (Ask, Auto oder Full access), sodass der Schreiber Bearbeitungen akzeptieren kann, während der Reviewer nur liest.
- **[Automatische Freigabe](/de/features/auto-approval/ "Automatische Freigabe") (Pro und Team, Claude Code).** Lesezugriffe, nur lesende Git-Befehle sowie Test-, Lint- und Build-Befehle werden für dich freigegeben, während riskante Befehle wie `git push`, `rm` oder `git reset --hard` immer bei dir landen. Das ist das Setup „lass ihn fahren, aber die gefährlichen Teile gehören mir“, ohne dich durch jede Nachfrage zu klicken.
- **[Benachrichtigungen und Freigaben](/de/features/notifications-and-approvals/ "Benachrichtigungen und Freigaben").** Wartet ein Agent auf dich, bringt dich ein Tastenkürzel direkt zu dem, der am längsten wartet.
- **[Checkpoints](/de/features/checkpoints-and-replay/ "Checkpoints und Replay").** Jeder Turn wird gesichert, sodass du einen Schritt einer Session rückgängig machen kannst, ohne die Git-History anzufassen.
- **[Code-Review](/de/features/code-review/ "Code-Review").** Am Ende eines Turns reviewt ein Claude-Modell deiner Wahl die Änderungen und listet Befunde mit Schweregrad und Datei:Zeile, und du kannst sie an den Agenten zurückschicken. Das ist ein eingebauter zweiter Agent auf dem Navigator-Platz.
- **[Review-Inbox](/de/features/review-inbox/ "Review-Inbox").** Fertige Arbeit wartet als Karten mit den geänderten Dateien, Risikohinweisen und Diffs, wo du sie freigibst oder mit einer Notiz zurückschickst.
- **[Agenten-Nachrichten](/de/features/agent-messaging/ "Agenten-Nachrichten").** Agenten im selben Projekt können sich Nachrichten schicken und eine Aufgabenliste teilen, auch über verschiedene CLIs hinweg, sodass der Schreiber den Reviewer direkt fragen kann.

## Fazit

Pair Programming mit KI funktioniert, wenn die Rollen klar sind. Leg vor jeder Aufgabe fest, wer fährt. Stell den Freigabemodus nach dem Risiko ein, nicht nach deiner Laune. Halte Schritte klein und committe nach jedem grünen. Lies jeden Diff, bevor du ihn akzeptierst. Entscheide bewusst zwischen Delegieren und Lernen. Wenn du eine zweite Meinung willst, lass einen zweiten Agenten reviewen, während du der Navigator bleibst.

Wenn du eine lange Aufgabe mit vielen Schritten zum Üben suchst, ist [JavaScript mit KI zu TypeScript migrieren](/de/blog/migrate-javascript-to-typescript-with-ai/ "JavaScript mit KI zu TypeScript migrieren") eine gute Wahl: Jeder Schritt ist klein, und der Compiler sagt dir, wann er fertig ist.

## Häufige Fragen

**Was ist Pair Programming mit KI?** Gemeinsam mit einem KI-Coding-Agenten an Code arbeiten, so wie zwei Entwickler im Paar arbeiten: Einer fährt und schreibt den Code, der andere navigiert, gibt die Richtung vor und reviewt jeden Schritt. Mit einem Agenten kannst du jede der beiden Rollen übernehmen.

**Sollte ich den Agenten ohne Freigaben laufen lassen?** Nur bei Arbeit, die du danach günstig prüfen kannst: gut getesteter Code, ein sauberer Git-Stand und eine Aufgabe, die du verstehst. Bei fremdem Code, Migrationen, sicherheitskritischen Teilen oder allem, was Produktion berührt, lass die Freigaben an und reviewe jeden Schritt.

**Wie groß sollte ein Schritt sein?** Klein genug, dass du den ganzen Diff in ein paar Minuten lesen und jemand anderem erklären kannst. Eine Funktion, ein Bugfix oder eine Datei ist eine gute Größe. Braucht ein Schritt eine lange Erklärung, teil ihn auf.

**Kann ich beim Pairing mit einem KI-Agenten etwas lernen?** Ja, wenn du es willst. Lass dir vom Agenten seinen Plan erklären, bevor er Code schreibt, tipp die wichtigen Teile selbst und frag, warum er einen Ansatz einem anderen vorgezogen hat. Wenn du nur Diffs akzeptierst, delegierst du die Arbeit, lernst aber wenig.

**Können zwei KI-Agenten miteinander pairen?** Ja. Ein verbreitetes Setup: Ein Agent schreibt den Code, ein zweiter, oft ein anderes Modell, reviewt die nicht committeten Änderungen. Du bleibst der Navigator, der entscheidet, welche Befunde umgesetzt werden.

---

**Ü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/