Rollen statt Personalunion.

Der Ein-Personen-Betrieb

In jedem kleinen Betrieb kennt man die Figur: Der Chef macht Angebot, Ausführung, Buchhaltung und Qualitätskontrolle selbst. Das geht erstaunlich lange gut — bis zu dem Punkt, an dem er seine eigene Arbeit abnehmen soll. Nicht weil er schlampt, sondern weil niemand die eigene Lösung mit fremden Augen sieht.

Genau so habe ich monatelang mit KI gearbeitet. Eine Sitzung, ein Modell, ein Gesprächsverlauf — und am Ende die Bitte: „Schau noch mal über Sicherheit, Architektur und Anforderungen." Dasselbe Modell, das zwei Stunden lang gebaut hat, sollte das Gebaute beurteilen. Personalunion, mit allem, was daran hängt:

• Es prüft sich selbst. Der Verlauf, in dem die Lösung entstanden ist, ist derselbe, in dem sie bewertet wird. Die Begründung von vorhin steht noch im Kontext — und überzeugt.
• Es hat nur eine Perspektive. Wer gerade an einer Funktion gebaut hat, denkt in Funktionen. Fragen nach Betrieb, Bedienbarkeit oder Anforderungsquelle liegen außerhalb dessen, worauf die Aufmerksamkeit gerade steht.
• Es entscheidet selbst, ob geprüft wird. Eine Bitte im Prompt ist eine Empfehlung. Manche Runden endeten ohne jede Prüfung — der Ereignisstrom sagte es hinterher ganz nüchtern.

„Runde beendet, ohne eine einzige Rolle zu beauftragen — Review steht aus."

Was ein Team anders macht

Der Gegenentwurf ist keine bessere Aufforderung, sondern eine andere Organisation. In einem Team arbeitet nicht ein Alleskönner schneller, sondern mehrere Fachleute nebeneinander — und das Entscheidende daran sind nicht die Titel, sondern drei ganz handfeste Unterschiede.

Erstens: eigene Köpfe. Jede Rolle läuft als eigene Sitzung, in einem eigenen Prozess, mit eigenem Kontextfenster. Sie sieht den Arbeitsstand, aber nicht den Gedankengang dessen, der ihn erzeugt hat. Kein „das hatten wir doch schon besprochen".

Zweitens: eigene Fähigkeiten. In einem echten Team kann nicht jeder alles, und das ist der Punkt. Meine Sicherheitsrolle darf als einzige im Netz recherchieren — ohne aktuelle Angriffsmuster ist eine Sicherheitsprüfung nur ein Bauchgefühl. Die Bedienbarkeitsrolle steuert einen echten Browser und schaut sich das gerenderte Ergebnis an statt den Quelltext. Der Senior-Entwickler hat bewusstkeine Schreibrechte, weil ein Prüfer, der nebenher am selben Code arbeitet, kein Prüfer mehr ist.

Drittens: eine Zuweisung statt einer Bitte. Rollen werden gestartet, nicht gefragt. Ob eine Prüfung stattfindet, ist damit keine Entscheidung des Modells mehr, sondern eine Eigenschaft des Ablaufs.

Die Besetzung

Fünf Rollen, bewusst wenige. Jede hat einen eigenen Auftragstext, eigene Werkzeuge, teilweise ein eigenes Modell — und eine Frage, die sie als Erste stellt:

Der wichtigste Absatz steht dabei nicht in der Aufgabe einer Rolle, sondern in ihrer Abgrenzung: In jeder Rollenbeschreibung steht, wofür die anderen vier zuständig sind. Ohne diesen Absatz liefern fünf Rollen fünfmal denselben Befund, nur anders formuliert — meistens den offensichtlichsten. Fünf Meinungen sind noch keine Rollenverteilung.

Hand in Hand: die Übergabe

Ein Team wird nicht dadurch produktiv, dass alle gleichzeitig loslaufen, sondern durch eine saubere Übergabe. Bei mir sieht die so aus: Die Konsole ermittelt den Arbeitsstandeinmal — was geändert wurde, was neu ist, was noch nicht eingecheckt ist — und legt ihn jeder Rolle bei. Wie ein Briefing, das alle bekommen, statt dass sich jeder seine Unterlagen selbst zusammensucht.

Das klingt nach einer Kleinigkeit und ist der größte Einzelhebel: Vorher hat sich jede Rolle denselben Stand selbst geholt, bei fünf Rollen fünfmal. Am selben Fall gemessen:eine Abfrage statt zwölf.

Danach arbeiten drei Rollen gleichzeitig, jede mit eigener Zeitgrenze und eigener Abrechnung. Was zurückkommt, ist kein Gesprächsbeitrag, sondern ein Bericht mit Absender: Auftrag, Dauer, Verbrauch, Befund. Und weil jede Rolle ihr eigenes Ergebnis liefert, widersprechen sie sich manchmal — was ich als Merkmal verbuche, nicht als Fehler. Zwei Fachleute, die dasselbe sagen, hätte ich mir sparen können.

Der Bildschirm dazu

Damit ein Team arbeiten kann, muss man sehen, wer gerade woran sitzt. Dafür gibt es eine kleine Konsole: ein Knoten je Rolle, live, mit Verbrauch, Dauer und Volltext des Befunds. Vorher war Delegation für mich eine Behauptung im Protokoll — jetzt ist sie ein Bild.

Das Werkzeug liegt seit heute offen:github.com/iwalbrunn/fleet-console. Es ist keine Bibliothek und kein Produkt, sondern der Bildschirm, auf dem diese Arbeitsweise sichtbar wird — und Teile davon sind selbst KI-gestützt entstanden, was der beste Grund für den ganzen Aufbau ist.

Wo die Team-Metapher aufhört

Ich will das Bild nicht überdehnen. Drei Stellen, an denen es trägt — und drei, an denen es kippt.

Es trägt bei der Arbeitsteilung, bei den unterschiedlichen Werkzeugen und bei der Übergabe. Es kippt hier:

• Niemand übernimmt Verantwortung. Ein Befund ist ein Hinweis, kein Beschluss. Die Entscheidung, was damit passiert, bleibt bei mir — samt der Folgen, wenn ich sie ignoriere.
• Sie beurteilen, sie bauen nicht. Keine der Rollen darf schreiben. Ein Rollenlauf liefert Befunde, keine Umsetzung.
• Es gibt keine Zusammenarbeit untereinander. Die Rollen reden nicht miteinander, sie arbeiten parallel am selben Stand. Das ist ein Gutachtergremium, keine Projektgruppe — und für den Zweck genau richtig, weil Absprache hier nur Angleichung wäre.

Dazu kommt der ehrliche Preis: Kontrolle kostet Rechenzeit. Fünf Rollen sind fünf Sitzungen. Deshalb der einmalige Arbeitsstand, deshalb Zeitgrenzen, deshalb das kleinere Modell überall dort, wo es reicht.

Was ich daraus mitnehme

Der Sprung kam nicht vom größeren Modell. Er kam davon, die Arbeit anders zu organisieren — genau wie in einem Betrieb, der vom Einzelkämpfer zum Team wird. Drei Punkte, die ich für übertragbar halte, auch ohne KI:

• Wer baut, prüft nicht sich selbst. Das gilt für Menschen seit jeher und für Modelle erst recht, weil sie so überzeugend begründen.
• Rollen brauchen unterschiedliche Fähigkeiten, nicht nur unterschiedliche Namen. Andere Werkzeuge, andere Rechte, andere Leitfrage — sonst sind es fünf Kopien.
• Übergabe schlägt Fleiß. Ein Briefing, das alle bekommen, spart mehr als jede Optimierung am einzelnen Arbeitsschritt.

Nachtrag vom 4. September 2026: weniger Rollen, mehr Belege

Drei Wochen mit dem Fünfer-Team im Alltag, und ich muss einen Teil dieses Artikels zurücknehmen. Nicht die Diagnose. Die Personalunion ist nach wie vor das Problem, und wer baut, sollte nicht sich selbst prüfen. Aber die Therapie war zu hoch dosiert.

Was passiert ist: Fünf Rollen sind fünf Sitzungen, und jede liest sich erst einmal in denselben Code ein. Bei kleinen Änderungen hat das Prüfen länger gedauert als das Bauen. Und die Befunde haben sich öfter überschnitten, als mir lieb war. Drei Rollen fanden dieselbe fehlende Fehlerbehandlung, die vierte fand nichts, die fünfte ein Problem, das keines war. „Fünf Meinungen sind noch keine Rollenverteilung", steht oben. Das gilt offenbar auch dann, wenn man sich mit der Abgrenzung Mühe gibt.

Der zweite Punkt hat mich mehr überrascht. Die aktuellen Modelle sind so gut, dass eine starke Sitzung mit einem sauberen Auftrag die meisten Aufgaben besser erledigt als ein Orchestrator, der fünf Leute koordiniert. Die Koordination kostet dann nur, ohne etwas zu bringen.

Also habe ich die Konsole umgebaut. Sie kennt jetzt drei Betriebsarten:

• Direkt. Eine starke Sitzung baut. Sonst nichts. Das ist der Standard, und er reicht erstaunlich oft.
• Verifiziert. Nach dem Bauen laufen zuerst die Prüfungen, die das Projekt ohnehin hat: Typprüfung, Tests, Lint, Build. Danach bekommt ein frischer Prüfer ohne Schreibrechte den Diff, die Anforderungsliste und die Ergebnisse dieser Prüfungen. Sein Auftrag lautet nicht „schau mal drüber", sondern: Widerlege, dass das fertig ist.
• Parallel. Für Migrationen und Audits, die sich wirklich in unabhängige Teile zerlegen lassen. Dafür nutze ich die eingebauten Workflows von Claude Code, statt selbst den Orchestrator zu spielen.

Die fünf Rollen gibt es noch. Sie sind nur kein Standard mehr, sondern Spezialisten, die ich dazuhole, wenn der Fall es hergibt: die Sicherheitsrolle bei allem, was Anmeldung oder Rechte berührt, die Bedienbarkeit bei Änderungen an der Oberfläche. Ein Klick, statt fünf Sitzungen für jeden Tippfehler.

Zwei Dinge sind dazugekommen, die ich im August noch nicht auf dem Zettel hatte. Die Anforderungsliste liegt jetzt außerhalb des Modells: Jede Nachricht von mir wird auf dem Server als Anforderung erfasst, das Modell darf nur den Status pflegen, nicht die Liste. Eine Sitzung kann damit nichts mehr „vergessen", ohne dass es auffällt. Und jede Sitzung kann in einer eigenen Git-Arbeitskopie laufen, damit sich zwei Aufträge am selben Projekt nicht in die Quere kommen.

Was vom Artikel bleibt: alle drei Punkte aus „Was ich daraus mitnehme". Wer baut, prüft nicht sich selbst; das erledigt jetzt ein Prüfer statt fünf. Rollen brauchen unterschiedliche Fähigkeiten; die Spezialisten haben sie weiterhin. Und Übergabe schlägt Fleiß; die Prüfungen des Projekts sind genau so ein Briefing, nur eines, das nicht diskutiert.

Was ich streiche: die Fünf als Standard. Kontrolle kostet Rechenzeit, das stand schon oben. Ich hatte nur unterschätzt, wie schnell sie mehr kostet, als sie findet. Der Umbau liegt wie gehabt aufGitHub.

Wie ist das bei euch — ein Modell für alles, oder arbeitet ihr schon mit getrennten Rollen? Schreiben Sie mir.