Claude Code im Team: vom Einzelversuch zur Arbeitsweise

In vielen Teams sieht der Stand so aus: Drei oder vier Leute arbeiten seit Monaten mit Claude Code, jeder mit eigenem Setup, eigenen Freigaben und eigenen Tricks. Die Ergebnisse sind teils beeindruckend, aber nicht übertragbar. Wenn eine Kollegin krank ist, weiß niemand, warum ihre Sessions so gut funktionieren. Und wer neu dazukommt, fängt bei null an.

Das ist kein Tool-Problem, sondern eine fehlende Arbeitsweise. Claude Code bringt die Bausteine für Teamarbeit bereits mit. Sie müssen nur bewusst entscheiden, was davon gemeinsam gilt.

Warum Einzelnutzung nicht von selbst zur Teampraxis wird

Claude Code merkt sich wenig über eine Session hinaus. Jede Sitzung startet mit einem frischen Kontextfenster. Was ein Entwickler seinem Agenten über Wochen beigebracht hat, steckt deshalb oft in persönlichen Dateien, in Gewohnheiten beim Prompten oder schlicht im eigenen Kopf.

Dazu kommt ein menschlicher Faktor. In einer Diskussion auf Reddit beschreibt jemand die Rolle, die viele Teams kennen: Eine Person probiert jedes neue Agenten-Setup in der Woche seines Erscheinens aus, trägt aber dieselben Sprint-Tickets wie alle anderen. Das Experimentieren läuft obendrauf und zehrt mit der Zeit aus. Der Rest des Teams wartet ab, bis ein Werkzeug ausgereift ist. Beides ist legitim, aber ohne Absprache entsteht genau die Lücke zwischen einer Pionierin und einem Team, das ihre Erkenntnisse nie übernimmt.

Was ins Repository gehört und was persönlich bleibt

Claude Code kennt persönliche Einstellungen, Projekteinstellungen, die mit dem Repository geteilt werden, und zentral verteilte Vorgaben der Organisation. Für das Team ist nicht die genaue Rangfolge entscheidend, sondern eine Absprache: Was für alle gilt, steht in eingecheckten Dateien. Was nur eine Person betrifft, bleibt lokal.

Ein Detail sorgt in Teams regelmäßig für Verwirrung: Wer bei einer Rückfrage des Agenten eine Freigabe dauerhaft erteilt, erteilt sie nur für sich selbst. Die Kollegen bekommen davon nichts mit. Gemeinsame Freigaben entstehen deshalb nicht nebenbei in einer Session, sondern bewusst im Team.

Die Konsequenz: Gemeinsame Regeln und Freigaben landen in einem Pull Request und werden reviewt wie Code. Für jede geteilte Regeldatei gibt es eine verantwortliche Person, und Änderungen daran brauchen ein Approval wie jede andere Änderung am Repository. Wie die einzelnen Einstellungen technisch aufgebaut sind, ist Konfigurationsarbeit; die Teamfrage lautet, wer entscheidet, was der Agent für alle darf.

Gemeinsamer Kontext statt zehn Prompt-Gewohnheiten

Claude Code liest dauerhafte Anweisungen aus einer eingecheckten Kontextdatei im Projekt, CLAUDE.md oder eine bestehende AGENTS.md. Wie diese Datei aufgebaut ist, ist zweitrangig. Für das Team zählen drei Entscheidungen.

Erstens: Welche Datei führt? Wer neben Claude Code auch Cursor oder Codex nutzt, legt eine Datei als Quelle fest und verweist aus den anderen darauf, statt dieselben Regeln dreimal zu pflegen.

Zweitens: Wer ist verantwortlich? Eine Person sammelt Vorschläge, hält die Datei kurz und widerspruchsfrei und räumt regelmäßig auf. Ohne diese Rolle wächst die Datei, weil jeder ergänzt und niemand streicht.

Drittens: Wann kommt ein Eintrag dazu? Die Dokumentation nennt Anlässe, die sich direkt als Teamregel eignen:

• Der Agent macht denselben Fehler zum zweiten Mal.
• Ein Review findet etwas, das der Agent über diese Codebasis hätte wissen müssen.
• Jemand tippt dieselbe Korrektur ein, die er schon in der letzten Session getippt hat.
• Ein neues Teammitglied bräuchte denselben Kontext, um produktiv zu werden.

Jeder dieser Anlässe wird ein kleiner Pull Request an der führenden Datei, mit Review wie jede andere Änderung. Was der Agent auf keinen Fall tun darf, gehört nicht nur in die Kontextdatei, sondern zusätzlich hinter eine technische Freigabe.

Ausprobieren mit Budget statt Dauer-Pionierarbeit

Die Antworten in der Reddit-Diskussion lassen sich zu einem brauchbaren Verfahren verdichten:

1. Ein fester, kleiner Zeitblock pro Sprint für Experimente, statt sie in die Ticketarbeit sickern zu lassen.
2. Ein neues Werkzeug oder Setup wird an einem echten Ticket getestet, mit einer kurzen Behalten-oder-Verwerfen-Liste.
3. Das Ergebnis wird aufgeschrieben, damit andere es nachbauen können, auch wenn das Tool verworfen wird.
4. Die Rolle des Tool-Scouts rotiert, statt dauerhaft an einer Person zu hängen.
5. Der kritische Pfad bleibt auf dem bewährten Setup; Neues muss sich erst an einer Nebenaufgabe beweisen.

Mehrere Beteiligte betonen außerdem, dass das Team erprobte Werkzeuge selbst abholen sollte, statt jede Neuheit vorgesetzt zu bekommen. Das entlastet die Early Adopter und senkt den Widerstand bei den Abwartenden.

Was das für Ihr Entwicklerteam bedeutet

Der Schritt vom Einzelversuch zur Arbeitsweise besteht aus wenigen, konkreten Entscheidungen: Welche Einstellungen und Kontextdateien liegen im Repository, wer pflegt sie, und wie gelangen neue Erkenntnisse dort hinein. Dazu gehört ein gemeinsamer Blick auf die Ergebnisse, denn mehr Agenten-Code bedeutet mehr Reviewarbeit. Eine Review-Checkliste für KI-generierte Pull Requests ist deshalb meist der nächste sinnvolle Baustein, ebenso ein gemeinsames Verständnis für Risiken wie Prompt Injection über Issues und READMEs.

Wichtig ist auch, was nicht passieren sollte: Regeln, die nur in einem Wiki stehen, Freigaben, die jeder anders setzt, und ein einzelner Enthusiast, der das alles nebenbei trägt. Welche Themen ein gemeinsamer Einstieg abdecken kann, zeigt die Übersicht der geplanten Trainingsmodule.

Eine gemeinsame Arbeitsweise entsteht nicht durch eine Lizenz, sondern durch Absprachen, die im Repository sichtbar sind und gepflegt werden. Wer diese Absprachen früh trifft, macht die Erfahrung der Einzelnen für das ganze Team nutzbar.

Sie wollen, dass Ihr Team Claude Code nach gemeinsamen Regeln am eigenen Repository nutzt statt nach zehn privaten Setups? Inhouse-Training anfragen und kurz beschreiben, wo Ihr Team heute steht – Details zum Ablauf finden Sie auf der Seite Training.