Teambuilding mit KI

Ich habe Televism von Anfang an so aufgesetzt, dass ich es gemeinsam mit KI-Agenten entwickle. Trotzdem wird aus Mensch und Agent nicht automatisch ein funktionierendes Team, nur weil beide am selben Projekt arbeiten.

Wir mussten uns erst einspielen: herausfinden, wie wir Ideen entwickeln, wer welche Entscheidungen trifft und wann aus einer Idee tatsächlich Code wird. Bevor wir produktiv zusammenarbeiten konnten, brauchten wir deshalb erst einmal gemeinsame Spielregeln.

Erst mal Regeln festlegen

Ein Team, das gerade zusammenfindet, klärt als Erstes, wie es zusammenarbeitet: Wer macht was? Was wird abgestimmt, was läuft von allein? Bei uns steht dieses Arbeitsmodell in einer Datei: AGENTS.md. Das ist unser gemeinsames Regelwerk, kein technisches Dokument – es beschreibt wie an Televism gearbeitet wird, nicht was gebaut wird.

Dort steht zum Beispiel, dass wir neue Features zuerst im Fachkonzept erarbeiten. Anschließend werden sie in ein technisches Design überführt. Erst wenn ich dieses für gut befunden habe, wird Code generiert.

Der Aufwand soll bewusst nach vorn wandern: in die Abstimmung des Ansatzes und ein gemeinsames Verständnis. Am Ende soll schon möglichst alles klar sein, sodass beim Generieren des Codes keine Überraschungen mehr entstehen. In unseren Spielregeln stehen auch die harten Leitplanken: Was darf der Agent allein entscheiden, was nicht? Commits und Pushes etwa macht er nur auf ausdrückliche Aufforderung – nie selbstständig, auch nicht als Abschluss einer Aufgabe.

Fachkonzept und technisches Konzept sind dabei keine flüchtigen Planungsdokumente für einen einzelnen Task, sondern die fortlaufende Projektdokumentation. Das hilft bei der Abstimmung – und hat noch einen zweiten Vorteil, auf den wir später kommen.

Bei einer konkreten Aufgabe komme ich mit einer Idee. Wir brainstormen erst einmal, dann erweitert der Agent das Konzept um diese Idee. Ich muss anschließend nur das Diff reviewen, um zu sehen, ob wir dasselbe Verständnis haben. Auf Ebene des technischen Konzepts, kurz TK, setzt sich das fort – zumindest so weit, wie ich die Kontrolle behalten möchte.

Die Implementierung übernimmt der Agent inzwischen selbstständig. Das war zu Beginn auch kein Selbstgänger, aber dazu kommt noch ein eigener Post. Den fertigen Code prüfe ich nur grob, vor allem darauf, ob er die erwarteten Packages, Dateien und Tests angefasst hat.

Keine verkleideten Personas

Wir beide sind in vielen Rollen unterwegs: Product Owner, Architekt, Tester, Infrastructure Engineer und Security Engineer.

Ich lasse mir dabei gerne helfen. Eine Sache mache ich aber bewusst nicht, obwohl sie überall empfohlen wird: Ich verpasse dem Agenten keine Personas.

Ich habe damit herumgespielt und nie einen Unterschied festgestellt, ob ich einem Agenten oder LLM sage: „Du bist ein sehr erfahrener Software-Entwickler, spezialisiert auf Spring-Anwendungen, mit hohem Qualitätsbewusstsein und tiefen Kenntnissen über blablabla. Reviewe diesen Code.“ Oder schlicht: „Review this.“

Was er braucht, ist kein Kostüm, sondern das richtige Dokument zum richtigen Zeitpunkt. Für querschnittliche Rollen, die er im Lauf einer Aufgabe einnimmt, gibt es deshalb eigene Leitfäden, die aus der AGENTS.md verlinkt sind. Ein neues Feature aufsetzen, einen zeitgesteuerten Trigger bauen, einen Integrationstest schreiben, sichtbare Texte übersetzbar machen: Für jedes dieser Querschnittsthemen liegt eine eigene Anleitung bereit.

Nicht „Stell dir vor, du wärst Tester“, sondern „So testen wir hier“. Das ist der Unterschied zwischen Rollenspiel und Handwerk.

Ein Partner mit Gedächtnisverlust

Jetzt kommt der Haken: Mein neuer Partner leidet an Gedächtnisverlust.

Es ist nicht so, dass ich ihn einmal einarbeite und er dann für immer weiß, wie der Hase läuft. Er startet jede Aufgabe bei null. Kein Wissen über das Projekt, keine Erinnerung an das, was wir letzte Woche zusammen gebaut haben. Alles, was ihm zur Verfügung steht, ist das, was gerade in seinem Kontext liegt. Sonst nichts.

Hier kommen die Dokumente von oben wieder ins Spiel. Es ist nicht nur für mich leichter, mich mit dem Agenten auf Ebene von Fachkonzept und TK auszutauschen statt auf Code-Ebene. Auch für ihn ist es leichter, komprimiertes Wissen über das Projekt aus der Dokumentation zu laden, anstatt es sich vollständig aus dem Code anzueignen.

Auch dabei gibt es einiges zu beachten: kleine, klar abgegrenzte Dateien sowie Verlinkungen vom Code in die Dokumentation und zurück. Dazu aber an anderer Stelle mehr.

Ein Zuhause für einen vergesslichen Partner

Gemeinsame Regeln schaffen Vertrauen: nicht, weil sie den Agenten perfekt machen, sondern weil sie sicherstellen, dass wir vom selben Problem sprechen. Dann muss ich nicht jede Zeile Code nachvollziehen, sondern kann prüfen, ob Konzept, betroffene Stellen und Tests zusammenpassen.

Dafür braucht der Agent ein artgerechtes Zuhause: Regeln müssen auffindbar sein, Wissen kompakt und verlinkt, und der Einstieg ins Projekt muss auch ohne Vorgeschichte gelingen.