Pair Programming mit Claude Code: schneller entwickeln, ohne die Kontrolle abzugeben

Pair Programming mit Claude Code bedeutet nicht, der KI die gesamte Verantwortung zu überlassen. Der stabile Ansatz ist klarer: Der Mensch hält Ziel, Grenzen und Akzeptanzkriterien fest. Claude Code übernimmt Code-Recherche, kleine Änderungen, Testläufe und die Vorbereitung der Review.

Die offizielle Seite Claude Code overview beschreibt Claude Code als agentisches Coding-Werkzeug, das Codebases lesen, Dateien bearbeiten, Befehle ausführen und sich in Entwicklungswerkzeuge integrieren kann. Das ist deutlich mächtiger als ein Chatfenster, aber genau deshalb brauchen Prompts klare Leitplanken.

Dieser Artikel ist die praktische Fortsetzung des Claude Code Getting Started Guide. Er zeigt einen wiederholbaren Ablauf für kleine Features, Bugfixes, Tests, Refactorings und Pull Requests.

Rollen zuerst klären

Bevor Claude Code etwas implementiert, muss klar sein, welche Entscheidungen beim Menschen bleiben. Claude kann viele Dateien lesen und schnell Code schreiben, sollte aber Produktintention, Sicherheitsgrenzen und Merge-Kriterien nicht eigenständig verändern.

Bereich	Mensch entscheidet	Claude Code übernimmt
Ziel	Was sich ändern soll und was nicht	Relevante Dateien und mögliche Wege finden
Recherche	Suchbereich festlegen	Code, Tests, Diff und Logs lesen
Umsetzung	Größe und Risiko des Diffs freigeben	Kleine, fokussierte Änderungen machen
Verifikation	Pass- oder Fail-Signal definieren	Tests, Lint, Build oder Screenshots ausführen
Review	Merge-Fähigkeit beurteilen	Risiken, fehlende Tests und Alternativen auflisten

So wird Claude Code zu einem produktiven Pairing-Partner, nicht zu einem unbeaufsichtigten Ersatz. Für Einsteiger ist das auch didaktisch besser: Beginne mit einem Bug, einer Testdatei oder einer Komponente, nicht mit einem kompletten Modul.

Das Repository in den ersten 10 Minuten vorbereiten

Vorbereitung wirkt stärker als ein besonders cleverer Prompt. Die Claude Code best practices empfehlen, Claude eine überprüfbare Erfolgsmessung zu geben und Exploration, Planung, Implementierung und Prüfung zu trennen. Praktisch nutze ich drei Regeln.

Erstens: nicht direkt auf main arbeiten, sondern Branch oder Worktree verwenden. Zweitens: ein kurzes CLAUDE.md pflegen. Die offizielle memory documentation erklärt, dass CLAUDE.md zu Beginn jeder Session als persistente Anweisung geladen wird. Drittens: die Prüfkommandos sichtbar machen.

# CLAUDE.md

## Project rules
- Before editing, summarize the files you plan to inspect.
- Prefer small diffs and explain risky changes before applying them.
- After code edits, run `npm run lint` and the narrowest relevant test.
- Do not read `.env*` files or change deployment settings without approval.

## Common commands
- `npm run lint`
- `npm run test`
- `npm run build`

CLAUDE.md sollte kurz bleiben. Wenn dort jede Projektentscheidung und jedes How-to steht, gehen wichtige Regeln unter. Wiederholbare Abläufe passen besser in Skills, weil sie nur bei Bedarf geladen werden.

Der Kernablauf: erkunden, planen, umsetzen, prüfen

Der häufigste Fehler ist ein direkter Auftrag wie “bau das mal ein”. Sicherer ist dieser Ablauf:

flowchart LR
  A[Ziel formulieren] --> B[Relevante Dateien erkunden]
  B --> C[Plan prüfen]
  C --> D[Klein ändern]
  D --> E[Checks ausführen und Diff lesen]
  E --> F{Bestanden?}
  F -- Nein --> C
  F -- Ja --> G[Für PR zusammenfassen]

Der erste Prompt muss nicht lang sein, aber Ziel, Umfang, Verbote und Verifikation enthalten.

Ziel: Den 500-Fehler auf der Profilseite nach dem Login beheben.
Umfang: Beginne mit `src/auth` und `src/pages/profile`.
Nicht tun: Auth-Strategie ändern, DB-Schema ändern oder `.env` lesen.
Vorgehen: Lies relevante Dateien, nenne 3 wahrscheinliche Ursachen und zeige vor Änderungen einen Plan.
Verifikation: Führe die vorhandenen Auth-Tests und `npm run lint` aus.

Wenn der Plan zu groß ist, begrenze ihn vor der ersten Änderung.

Der Plan ist plausibel, aber schreibe zuerst nur den Reproduktionstest.
Bestätige, dass er fehlschlägt, bevor du Produktionscode änderst.
Danach schlage Änderungen am Produktionscode Datei für Datei vor.

Das passt gut zu TDD, also testgetriebener Entwicklung. Ein zuerst fehlschlagender Test macht das Problem sichtbar und zwingt die Lösung in eine prüfbare Form.

Ein kleines ausführbares Beispiel

Zum Üben eignet sich eine kleine Funktion besser als Produktivcode. Speichere den folgenden Inhalt als pair-check.test.ts und führe ihn mit Vitest aus.

import { describe, expect, it } from "vitest";

type ClaudeMode = "direct" | "plan-first" | "human-review";

export function decideClaudeMode(input: {
  changedFiles: number;
  touchesSecrets: boolean;
  hasReliableTests: boolean;
}): ClaudeMode {
  if (input.touchesSecrets) return "human-review";
  if (input.changedFiles > 3) return "plan-first";
  if (!input.hasReliableTests) return "plan-first";
  return "direct";
}

describe("decideClaudeMode", () => {
  it("allows direct work for small, well-tested changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("direct");
  });

  it("requires a plan for broad changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 5,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("plan-first");
  });

  it("requires human review for secret-related work", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: true,
        hasReliableTests: true,
      }),
    ).toBe("human-review");
  });
});

npm install -D vitest typescript
npx vitest run pair-check.test.ts

Bitte Claude Code danach, eine Regel zu ergänzen: “Wenn Billing betroffen ist, muss human-review gewählt werden.” Lass zuerst den Test schreiben, dann das Scheitern bestätigen, anschließend implementieren und erneut testen. Der Code ist klein, trainiert aber denselben Ablauf wie bei API-Handlern, React-Komponenten oder Migrationsskripten.

Vier Use Cases aus der Praxis

Der erste Use Case ist eine kleine Bedingung in einer bestehenden Funktion, etwa “CSV-Export für kostenlose Accounts ausblenden”. Das betrifft UI, Berechtigungen und Tests, ohne die gesamte Architektur anzufassen.

Der zweite Use Case ist Bug-Analyse. Gib Fehlermeldung, Reproduktionsschritte und erwartetes Verhalten mit. Die offizielle Seite Common workflows empfiehlt Reproduktionskommandos und Stack Traces, damit Claude Ursachen verfolgt statt zu raten.

Der dritte Use Case ist Testausbau. Claude soll zuerst bestehende Testmuster lesen und dann Fälle wie Erfolg, keine Berechtigung, ungültige Eingabe und leere Daten ergänzen. Für systematisches Vorgehen passt der testing strategies guide.

Der vierte Use Case ist die Selbstreview vor dem PR. Lass Claude git diff lesen und nach Sicherheit, Abwärtskompatibilität, fehlenden Tests und unklaren Namen priorisieren. Die GitHub-Dokumentation zu pull request reviews erklärt, wie Kommentare, Approvals und Änderungsanforderungen Qualität sichern. Claude Code bereitet die menschliche Review vor, ersetzt sie aber nicht.

Konkrete Stolperfallen und Gegenmaßnahmen

Falle	Was passiert	Sicherere Gewohnheit
“Mach es besser”	Nicht angeforderte Refactorings landen im Diff	Umfang, Nicht-Ziele und Akzeptanzkriterien nennen
Zu großer Diff	Review wird langsam und Fehler verstecken sich	Eine Aufgabe, ein Diff, ein Plan
Keine Verifikation	Die Änderung wirkt nur fertig	Tests, Lint, Build oder Screenshot verlangen
Riesiges CLAUDE.md	Wichtige Regeln gehen unter	Abläufe in Skills auslagern
Zu breite Rechte	Secrets oder Produktion werden erreichbar	Permissions und hooks nutzen

Die unterschätzte Gefahr ist Approval-Fatigue. Wenn alles bestätigt werden muss, bestätigen Menschen irgendwann automatisch. Wenn fast alles erlaubt ist, kann ein schlechter Prompt zu weit gehen. Praktisch heißt das: viel Vertrauen für reversible Arbeit, viel Reibung für irreversible Arbeit. Konkrete Muster findest du im approval and sandbox guide.

Die Session in einen reviewbaren PR verwandeln

Im Team sollte der Wert nicht im Chat bleiben. Beende die Session mit einer PR-Zusammenfassung.

Fasse diesen Diff für eine Pull Request zusammen.
Enthalten sein sollen:
- Warum die Änderung gemacht wurde
- Wichtigste geänderte Dateien
- Ausgeführte Verifikationskommandos und Ergebnisse
- Risiken, die Reviewer genau prüfen sollten
- Bereiche, die absichtlich nicht geändert wurden

Claude kann den Entwurf schreiben, aber der finale Text gehört in menschliche Hände. Bei Sicherheit, Zahlungen, Datenschutz und Datenlöschung ist die Zuversicht des Modells kein Beweis. Beweise sind Diff, Testausgabe, Logs und Review-Diskussion.

Ergebnis des praktischen Tests

Als Masa diesen Ablauf für einen kleinen Next.js-Fix nutzte, war die Review schneller als bei einem einfachen “implementiere das”. Der Grund war nicht perfekter Code, sondern die Begrenzung im ersten Prompt: Dateien, Verbote, Lint und Tests waren klar. Claude Code berührte weniger irrelevante Dateien und ließ die Verifikation in der Unterhaltung stehen. Bei UI-Änderungen mit schwachen Tests blieb menschliche Sichtprüfung nötig. Die Lehre ist klar: Pair Programming mit Claude Code heißt nicht Verantwortung abgeben, sondern die Grenze der Verantwortung bewusst gestalten.

Wähle für die nächste Session eine kleine Aufgabe und gehe durch Erkunden, Planen, Umsetzen und Prüfen. Für gemeinsame Prompts und Review-Regeln im Team gibt es ClaudeCodeLab training.