Prototyper, Builder, Sweeper: Rollen für Teams mit KI

Seit einiger Zeit passt bei uns die Frage „Wer macht das?“ nicht mehr zu den Berufsbezeichnungen. Früher war klar: Eine Datenbankmigration übernimmt, wer sich mit Datenbanken auskennt, ein Layout, wer gestalten kann. Heute kann eine Designerin mit einem Coding-Agenten eine Schnittstelle umsetzen, und ein Entwickler baut eine Landingpage, für die es vor zwei Jahren eine Woche Abstimmung mit der Gestaltung gebraucht hätte. Das Wissen, das früher den Zugang zu einer Aufgabe geregelt hat, braucht man für die Umsetzung oft nicht mehr selbst.

Damit wird die alte Einteilung unscharf. Wer sich als Spezialist für eine Technik versteht, merkt, dass diese Technik selten der Engpass ist. Wir haben deshalb überlegt, wie Rollen aussehen könnten, die zu dieser Arbeitsweise passen. Mitten in diese Überlegungen fiel ein Beitrag, den Boris Cherny Ende Juni auf X veröffentlicht hat. Er hat Claude Code bei Anthropic entwickelt und leitet dort das Team dahinter, also genau das Werkzeug, mit dem wir selbst täglich arbeiten. Er beschreibt fünf Rollen, und die liegen sehr nah an dem, was wir selbst skizziert hatten.

Die fünf Rollen

So beschreibt er die Rollen, die er in seinem eigenen Team sieht:

• Prototyper bringen neue Ideen hervor. Sie produzieren viele Entwürfe, die meisten davon gehen nie live.
• Builder machen aus einem Prototyp oder einer Idee schnell ein Produkt oder eine Infrastruktur, die im echten Betrieb trägt.
• Sweeper räumen auf. Sie glätten die Oberfläche, vereinfachen Code und System, bauen Funktionen wieder aus und verbessern die Performance.
• Grower nehmen ein fertiges Produkt und verbessern es Schritt für Schritt, bis es besser zu dem passt, was die Nutzer wirklich brauchen.
• Maintainer übernehmen ein ausgereiftes System und halten es sicher, zuverlässig, schnell und sparsam, auch wenn es wächst.

Dazu kommen zwei Beobachtungen. Viele Menschen decken zwei Rollen ab, manche drei. Und die Rollen hängen nicht am Beruf: Bei Anthropic gibt es Designer, die vor allem Prototyper sind, andere sind Builder oder Sweeper, und dasselbe gilt für Entwickler, Produktverantwortliche und Data Scientists.

Welche Mischung ein Team braucht, hängt für ihn vom Zustand des Produkts ab. Ein neues Produkt, das seinen Markt noch sucht, braucht vor allem Prototyper, Builder und Sweeper. Hat es seinen Markt gefunden und wächst, verschiebt sich das Gewicht zu Builder, Sweeper und Grower, dazu etwas Maintainer. Ein etabliertes Produkt lebt von Sweeper, Grower und Maintainer, ergänzt um einige Builder.

Warum uns das überzeugt

Das Modell sortiert Arbeit nach ihrer Phase im Leben eines Produkts. Steht etwas am Anfang, wird es gerade gebaut, aufgeräumt, weiterentwickelt oder im Betrieb gehalten? Jede Phase verlangt eine andere Haltung. Ein Prototyper muss aushalten, dass neun von zehn Ideen in der Schublade landen. Ein Maintainer braucht das Gegenteil: Er misstraut jeder Änderung, die das System unruhig macht.

Diese Haltungen gab es schon immer. Neu ist, dass sie sich vom Handwerkszeug gelöst haben. Solange man ein Framework jahrelang lernen musste, um damit zu bauen, hat das Framework die Rolle bestimmt. Übernimmt ein Agent den Großteil der Umsetzung, zählt stärker, was jemand gut kann: Ideen in Fülle hervorbringen, Dinge belastbar machen, Überflüssiges erkennen, Nutzer verstehen oder Systeme ruhig halten.

Dass eine Person mehrere Rollen trägt, ist für uns Alltag. In einem kleinen Team kann niemand nur eine Sache machen. Wer ein Projekt vom ersten Entwurf bis zum Livegang begleitet, ist zuerst Prototyper, dann Builder und am Ende Sweeper. Die Rollen geben dem einen Namen und machen sichtbar, in welcher Phase jemand gerade arbeitet und wo er stark ist.

Wo wir weiterdenken

Drei Punkte würden wir ergänzen oder anders gewichten.

Der Sweeper wird wichtiger, als die Liste vermuten lässt. Mit KI entsteht Code schneller, als ihn jemand aufräumt. Ein Prototyp sieht nach einem Nachmittag fertig aus, und die Versuchung ist groß, ihn einfach weiterzubauen. Wer vereinfacht, Funktionen wieder entfernt und Doppeltes zusammenführt, hält ein Projekt beherrschbar. Diese Arbeit ist unauffällig und wird selten gefeiert. In einem Team, das viel mit Agenten baut, braucht sie trotzdem einen festen Platz.

Fachwissen wandert ins Urteil. Für die Umsetzung braucht man es seltener, für die Prüfung des Ergebnisses weiterhin. Ob eine Schnittstelle sicher ist, ob eine Datenbankabfrage unter Last hält oder ob eine Seite barrierefrei ist, erkennt ein Agent nicht immer von selbst. Beim Maintainer ist das am deutlichsten. Sicherheit, Datenschutz und Betrieb folgen Regeln, die wir in unserem Informationssicherheits-Managementsystem festgelegt haben, und die gelten unabhängig davon, wer oder was den Code geschrieben hat.

Für eine Agentur fehlt eine Rolle: die Abstimmung mit dem Kunden. Das Modell beschreibt ein Team, das sein eigenes Produkt baut. Wir arbeiten für Kunden. Zwischen Prototyp und Builder liegt bei uns fast immer ein Gespräch: Ist das gemeint? Passt das zum Budget, zur Marke, zu den Abläufen im Haus? Diese Übersetzung zwischen Idee und Auftrag war schon vor der KI der Engpass, und mit schnellerer Umsetzung fällt sie noch stärker auf (siehe Allein ist gerade schneller). Am ehesten steckt sie im Grower, aber sie beginnt bei uns viel früher.

Was wir daraus mitnehmen

Wir wollen ausprobieren, Aufgaben in Projekten auch nach diesen Rollen zu verteilen. Bei einer neuen Aufgabe würden wir dann zuerst fragen, in welcher Phase das Projekt steckt und wer dafür die passende Haltung mitbringt. Das Technische kann der Agent in vielen Fällen mittragen.

Auch die Übergabe sieht damit anders aus. Geht ein Projekt vom Bauen in den Betrieb über, wechselt oft auch die Rolle. Projekt-Skills, in denen Aufbau und Eigenheiten eines Projekts stehen, helfen dabei, dass der Maintainer nicht bei null anfängt.

Offen ist für uns, was das für neue Kolleginnen und Kollegen heißt. Bisher hat man sich über ein Fachgebiet eingearbeitet. Werden Rollen nach Haltung verteilt, braucht es einen anderen Einstieg, und wie der aussieht, wissen wir noch nicht.

Quellen: Boris Cherny auf X, 28. Juni 2026: die fünf Rollen im Claude-Code-Team