Wie man KI-Coding-Agenten in einem Entwicklerteam skalieren kann

Ein Entwickler mit einem Coding-Agenten ist eine Produktivitätsgeschichte. Es ist einfach zu erzählen, es lässt sich gut demonstrieren und es ist wirklich wahr.

Fünf Entwickler mit zwanzig Agenten ist etwas ganz anderes. Es ist ein Koordinationsproblem, und Koordinationsprobleme werden nicht mit dem Tool gelöst, das sie verursacht hat. Das ist der Teil, über den niemand schreibt, denn es zeigt sich erst nach der Enthusiasmusphase: Die individuellen Gewinne sind real, sie kommen sofort, und dann, irgendwo um den dritten oder vierten Entwickler, beginnt das Team, seine neue Geschwindigkeit dafür zu verwenden, um sich selbst aufzuräumen.

Was folgt, ist die Reihenfolge des Scheiterns. Keine Liste von Best Practices im Abstrakten, sondern die Reihenfolge, in der Dinge tatsächlich kaputtgehen, denn sie in der falschen Reihenfolge zu beheben, kostet ein Viertel.

Was zuerst kaputtgeht: gemeinsamer Kontext

Jeder Entwickler, der einen Agenten betreibt, bringt ihm leise seine eigene Version des Codebases bei.

Eine Person sagt ihrem Agenten, dass das Projekt Serveraktionen verwendet und niemals API-Routen. Eine andere erwähnt es nie, sodass ihr Agent API-Routen schreibt. Ein dritter erwähnt es einmal, in einer Sitzung, die vor drei Tagen endete. Niemand liegt falsch, niemand lügt, und das Repository enthält jetzt drei Interpretationen derselben Konvention. Du wirst dies in der Überprüfungsschlange bemerken, was der falsche Ort ist, um es zu bemerken: bis dahin existiert der Code.

Die Lösung ist langweilig und es ist das wichtigste Hebel auf dieser Seite. Lege die Konventionen in eine Datei, committe die Datei.

CLAUDE.md für Claude Code, AGENTS.md für Codex und die meisten anderen CLI-Agenten, und in der Praxis halten viele Teams eine tragbare Kontextdatei, anstatt zwei zu pflegen, die auseinanderdriften. Der Mechanismus ist wichtiger als der Dateiname: Die Anweisungen leben im Repository, sodass sie mit einem git pull ankommen, anstatt durch denjenigen, der zufällig im Raum war.

Was gehört hinein:

• Die Konventionen, die ein Agent nicht aus dem Lesen des Codes ableiten kann, insbesondere die, die das Codebase derzeit an einigen Stellen verletzt
• Die Befehle: wie man die Tests, den Build, den Linter ausführt und welche davon automatisch ausgeführt werden dürfen
• Die Teile des Repos, die gefährlich zu berühren sind, und warum
• Was das Team nicht will: das Refactoring, um das niemand gebeten hat, die Abhängigkeit, die nicht hinzugefügt werden darf, das Muster, von dem man sich entfernt

Was nicht hinein gehört, und hier verbrennen sich Teams: alles, was spezifisch für eine Maschine ist. Absolute Pfade, persönliche API-Tokens, lokale Ports, der bevorzugte Editor von jemandem. In dem Moment, in dem ein maschinenspezifischer Wert in einer committen Kontextdatei landet, erbt jeder andere Entwickler eine Einstellung, die für ihn falsch ist, und Agenten sind extrem gut darin, Anweisungen treu zu befolgen, die nicht mehr zutreffen.

Ein nützlicher Test, bevor du eine Zeile hinzufügst: Wenn ein Teamkollege dies zieht, hilft es ihm oder macht es ihm Probleme?

Was als zweites kaputtgeht: zwei Agenten, eine Datei

Agenten verhandeln nicht. Sie überprüfen nicht, ob jemand anderes gerade bearbeitet. Zwei Agenten, die auf dasselbe Modul zeigen, überschreiben sich gegenseitig, und keiner wird es erwähnen, denn aus der Sicht jedes einzelnen wurde die Arbeit erfolgreich abgeschlossen.

Solo ist das unsichtbar. Du betreibst einen Agenten zur Zeit, oder du betreibst mehrere und sie berühren zufällig verschiedene Dinge. In einem Team wird es strukturell und produziert die schlimmste Art von Fehler: Arbeit, die stillschweigend zwischen zwei erfolgreichen Testläufen verschwindet.

Zwei Mechanismen beheben es, und du willst beide.

Isolation. Git-Arbeitspfade geben jeder Aufgabe ihren eigenen Checkout des Repositories, sodass parallele Agenten physisch nicht kollidieren können. Das ist die günstige Hälfte der Lösung und es gibt keinen Grund, es nicht zu tun.

Eigentum. Isolation stoppt das Überschreiben; sie verhindert nicht, dass zwei Personen dasselbe Problem zweimal, in zwei Branches, auf zwei inkompatible Arten lösen. Das wird beim Zuweisen gelöst, indem jede Aufgabe auf eine Menge von Dateien beschränkt wird und dies in der Aufgabe selbst gesagt wird. Nicht "verbessere den Checkout-Fluss", sondern "ändere den Zahlungsschritt, in diesen drei Dateien, berühre nicht den Warenkorb".

Die zweite Hälfte ist die, die Teams überspringen, und sie bestimmt, ob der Merge eine Formalität oder ein Nachmittag ist.

Was als drittes kaputtgeht: Überprüfung

Alles an der Überprüfung im Teammaßstab folgt aus einer Zahl: wie viel Diff pro Stunde ankommt.

Ein Entwickler, der jede Zeile liest, funktioniert gut. Fünf Entwickler, die jeweils vier Agenten betreiben, erzeugen mehr Diff pro Tag, als das Team lesen kann, und das ehrliche Ergebnis ist keine sorgfältige Überprüfung, sondern Genehmigungstheater. Ein Mensch, der ein neunhundert Zeilen Diff um 18 Uhr überfliegt, produziert eine Unterschrift, ohne Wissen zu erzeugen, was schlimmer ist als keine Überprüfung, denn es erzeugt Sicherheit, wo keine besteht.

Die Politik, die überlebt, ist nicht "alles überprüfen" und es ist nicht "den Agenten vertrauen". Es ist, die Überprüfung an die beiden Grenzen der Arbeit zu verlagern: Lies den Plan, bevor der Agent beginnt, denn ein falscher Plan, der perfekt ausgeführt wird, ist der teuerste Fehler, der möglich ist, dann lies das Diff im Verhältnis dazu, was die Änderung brechen kann. Marketingtexte und CSS werden überflogen. Authentifizierung, Zahlungen, Berechtigungen, persönliche Daten und Migrationen werden jedes Mal zeilenweise von einem Menschen gelesen, unabhängig davon, wie sauber das Diff aussieht.

Das verdient ein eigenes Gespräch, und wir haben es separat aufgeschrieben: Solltest du den Code deines KI-Agenten noch überprüfen geht die zehn objektiven Hinweise durch, dass eine Änderung schiefgelaufen ist, und die Blast-Radius-Tabelle, die Teams so übernehmen können.

Eine team-spezifische Ergänzung. Wenn mehrere Agenten ein Repository teilen, benötigt die Überprüfung eine Zuordnung: welcher Agent, welche Aufgabe, welcher Entwickler. Ohne sie hat ein Diff keinen Autor und die Überprüfung wird zur Archäologie. Das ist das nützlichste, was du in deinem Setup beheben kannst, sobald du drei oder vier gleichzeitige Agenten hast.

Was als viertes kaputtgeht: Kosten und das Gespräch über Kosten

Die Token-Ausgaben hören auf, ein persönliches Detail zu sein, in dem Moment, in dem sie auf einer Teamrechnung erscheinen.

Die Falle ist, dass die Rechnung monatlich und aggregiert ist, sodass das Gespräch, das sie erzeugt, ebenfalls monatlich und aggregiert ist, was bedeutet, dass es eine Politik anstelle einer Lösung erzeugt. Jemand schlägt ein günstigeres Modell für alle vor. Jemand anderes schlägt vor, die Sitzungen zu begrenzen. Beides sind Vermutungen.

Die tatsächliche Verteilung ist fast nie gleichmäßig. Es sind eine kleine Anzahl von lang laufenden Sitzungen, an einem oder zwei Projekten, mit einem Kontext, der den ganzen Tag gewachsen ist und nie zurückgesetzt wurde. Das ist ein verhaltensbedingtes Problem, das behoben werden kann, und du kannst es nur beheben, wenn du die Ausgaben pro Sitzung und pro Projekt anstelle von pro Monat sehen kannst. Wir haben die Mechanik davon in wie man die Token-Nutzung überprüft und wie man sie senkt, ohne langsamer zu werden behandelt.

Mache die Zahl für die Personen sichtbar, die sie erzeugen, bevor sie ein Managementthema wird. Ein Entwickler, der sehen kann, dass eine Sitzung mehr gekostet hat als sein gesamter vorheriger Tag, ändert seine Gewohnheiten von selbst, und das kostet das Team politisch nichts.

Was sich tatsächlich in den Ritualen des Teams ändert

Drei Dinge, aus unserer Erfahrung und dem, was Teams berichten.

Standup wechselt von Status zu Entblockierung. Was jede Person gestern gemacht hat, ist größtenteils in den Branches sichtbar. Was fünf Minuten wert ist, ist, welche Agenten feststecken und woran.

Prompts werden zu gemeinsamen Vermögenswerten. Die Anweisung, die für einen Entwickler ein gutes Ergebnis erzielt hat, ist für das Team mehr wert als der Code, den sie produziert hat, und es ist genau die Art von Dingen, die in einer privaten Terminalhistorie verdampfen. Teams, die eine gemeinsame Prompt-Bibliothek im Repository führen, hören auf, jede Woche dieselbe Formulierung neu zu entdecken.

Spezialisierung wechselt von Personen zu Rollen. Sobald Agenten das Schreiben übernehmen, ist die interessante Frage, wer was überprüft, und Teams neigen natürlich dazu, Agenten Rollen zuzuweisen, genau wie sie sie Menschen zuweisen: einer für die Implementierung, einer für die Überprüfung, einer für die Tests. Das ist die Idee hinter Agent Teams, bei der eine Aufgabe von einer Dev-Rolle an eine QA-Rolle mit dem Diff, den Risiken und den Testhinweisen übergeben wird, und die Qualitätsschranken werden von deinem Test-Setup entschieden, anstatt von der eigenen Meinung eines Agenten über seine Arbeit.

Das Setup, das hält

Kondensiert, in der Reihenfolge, die zählt:

Die ersten vier kosten nichts außer Zustimmung. Die letzten beiden sind der Grund, warum ein Team schließlich etwas über dem Terminal möchte: nicht, weil Terminals schlecht sind, sondern weil ein Terminal einen Agenten zur Zeit zeigt und dir keine Möglichkeit gibt, die Frage zu beantworten: "Wer führt was aus, an welchem Projekt, gerade jetzt".

Das ist das Problem, um das AgentsRoom für Teams aufgebaut ist: jeder Agent über jedes Projekt in einer Ansicht, mit seiner Rolle, seinem Status und seinen Kosten angehängt, und ein mobiles Begleitgerät für die Zeiten, in denen das Team nicht an ihren Schreibtischen ist. Es funktioniert auf die gleiche Weise mit Claude Code und mit Codex, was wichtiger ist, als es klingt: die meisten Teams enden damit, beide zu betreiben, und ein Setup, das von einem Anbieter ausgeht, wird leise das nächste sein, was kaputtgeht.

Fange jedoch mit der Kontextdatei an. Es ist kostenlos, es dauert einen Nachmittag, und es beseitigt mehr Reibung als jedes Tool, das du in diesem Quartal installieren kannst.