Allein ist gerade schneller
Mit KI entsteht in einem Dialog mehr, als sich einem Kollegen erklären lässt. Wie mehrere Menschen gleichzeitig an einem Projekt arbeiten, haben wir noch nicht herausgefunden.
Seit Monaten sitzen wir immer wieder zusammen und fragen uns dasselbe: Wie arbeiten mehrere Menschen an einer Sache, die zum größten Teil eine KI baut? Eine gute Antwort haben wir bis heute nicht.
Das Problem zeigt sich an einem gewöhnlichen Nachmittag. Jemand von uns setzt sich mit Claude Code an einen neuen Dienst. Nach drei Stunden steht ein lauffähiger Stand mit ein paar Tausend Zeilen Code. Unterwegs sind Dutzende kleine Entscheidungen gefallen. Eine Bibliothek passt nicht, weil sie auf dem Server nicht läuft. Eine Datenstruktur fliegt raus, nachdem der erste Test zeigt, wie langsam sie bei großen Mengen wird. Ein Sonderfall beim Import fällt erst auf, als echte Daten durchlaufen. Im Code steht das Ergebnis all dieser Erkenntnisse. Warum er so aussieht, steht dort meistens nicht.
Die Übergabe kostet so viel wie die Arbeit
Soll jetzt eine Kollegin einsteigen, findet sie einiges schon im Projekt vor. Wir legen für jedes Projekt Skills an, also Anleitungen, die die KI von selbst lädt, sobald jemand eine passende Aufgabe angeht: einen Import erweitern, eine neue Seite anlegen, ausliefern. Darin steht, wie etwas gemacht wird. Was dort fehlt, ist der Rest des Nachmittags. Welche Richtung das Projekt gerade nimmt, welche Idee verworfen wurde und was als Nächstes ansteht, wird zu keiner Anleitung.
Für diesen Rest gibt es zwei Möglichkeiten. Die kurze Fassung erzählt in ein paar Absätzen, wohin es gehen soll und wo es hakt. Sie zeigt das Ergebnis, lässt aber die Abwägungen weg, und gerade die braucht man zum Weiterarbeiten. Wer damit loslegt, trifft dieselben Entscheidungen ein zweites Mal. Oder er trifft sie anders und merkt nicht, was er dabei kaputt macht.
Die ausführliche Fassung geht jeden Schritt des Dialogs durch. Das dauert ungefähr so lange wie die drei Stunden selbst. An dem Punkt fühlt sich die ganze Übung sinnlos an: Die Kollegin hätte das Projekt in derselben Zeit selbst mit der KI bauen können, und die Erkenntnisse hätte sie dann aus erster Hand.
Früher war das Verhältnis ein anderes. Programmieren war der teure Teil, die Abstimmung im Team kostete im Vergleich wenig. Saßen vier Leute zwei Wochen an etwas, lohnte sich jeden Tag eine Stunde Absprache. Heute schrumpft die Umsetzung auf einen Bruchteil, die Abstimmung dauert so lange wie immer. Ein Gespräch über Details wird so schnell zum langsamsten Teil des ganzen Projekts.
Neu ist das Problem nicht. Fred Brooks hat 1975 beschrieben, dass die Abstimmungswege schneller wachsen als das Team: Zwei Leute haben einen Kanal, vier haben sechs, sechs haben fünfzehn. Neu ist die Menge. Mit einer KI im Rücken erzeugt jedes Teammitglied heute so viel neuen Stoff, dass auf jedem dieser Kanäle mehr ankommt, als ein Mensch nebenbei aufnehmen kann.
Die großen Würfe kommen von Einzelnen
Dazu passt eine Beobachtung, die wir in den letzten Monaten immer wieder gemacht haben. Viele Projekte, die gerade Aufsehen erregen, stammen von einzelnen Menschen. Einer baut eine Bildbearbeitung nach, die sich mit der großen Kreativ-Suite messen will. Ein anderer schreibt ein bekanntes Spiel komplett neu. Der Agent OpenClaw, der Anfang 2026 in wenigen Wochen Zehntausende Sterne auf GitHub gesammelt hat, ist im Kern die Arbeit eines einzelnen Entwicklers. Hier und da steht vielleicht jemand als Sparringspartner im Hintergrund. Ein klassisches Team mit Frontend, Backend, Test und Projektleitung sehen wir dahinter fast nie.
Ganz trauen wir dieser Beobachtung nicht. Sichtbar werden vor allem Projekte, hinter denen eine Person mit einer guten Geschichte steht, und die meisten sind erst ein paar Monate alt. Wie es aussieht, wenn so ein Projekt drei Jahre gepflegt werden muss, zeigt noch keines. Das Muster fällt trotzdem auf. Wer allein mit einer KI arbeitet, hat keinen einzigen Abstimmungskanal und damit auch keinen Flaschenhals.
So machen wir es gerade
Bei uns hat sich ohne großen Beschluss eine Arbeitsweise eingespielt, die dazu passt. Eine Person kümmert sich eine Zeit lang um ein Projekt, von der ersten Zeile bis zum Betrieb. Danach kann jede andere Person es allein übernehmen und weiterführen. Das ist wie ein Staffellauf: Es läuft immer genau eine Person, und der Stab wechselt selten.
Damit die Übernahme klappt, muss das Wissen im Projekt selbst liegen. Den größten Teil tragen die Projekt-Skills, und für eine komplette Übergabe sind sie ideal. Wer übernimmt, muss sie nicht einmal kennen, die KI greift von selbst darauf zurück, sobald eine passende Aufgabe ansteht. Dazu kommen Notizen im Repository, die die KI bei jedem Start liest, Tests für die Stellen, an denen schon einmal etwas schiefging, und kurze Vermerke zu Entscheidungen, die sich aus dem Code nicht ablesen lassen. Wer neu dazukommt, lässt sich das Projekt zuerst von der KI erklären und fragt dort nach, wo es unklar bleibt. Was von einem KI-Projekt im Kopf bleibt und was nicht, haben wir in Wer weiß noch, was die KI gebaut hat? aufgeschrieben.
Das Nacheinander haben wir damit im Griff. Das Nebeneinander noch nicht.
Mehrere gleichzeitig: noch kein Weg
Sobald zwei oder drei Leute zur selben Zeit an einem Projekt arbeiten, kommen wir nicht weiter. Jede Person erzeugt mit ihrer KI an einem Tag mehr Änderungen, als die anderen sinnvoll nachvollziehen können. Wer jede Zeile prüft, verbraucht die Zeit, die die KI gespart hat. Ohne Prüfung driften die Stände auseinander, und am Ende passen zwei gut gebaute Hälften nicht zusammen.
Die Projekt-Skills, die beim Übergeben so gut funktionieren, helfen hier wenig. Sie springen erst an, wenn jemand schon etwas bauen will, und beantworten dann die Frage, wie es gemacht wird. Ob zwei Leute dasselbe Ziel verfolgen und das Projekt gleich einschätzen, klärt keiner davon. Genau darüber müssten sie sich aber laufend abstimmen.
Ein paar Ansätze probieren wir aus. Überzeugt hat uns noch keiner.
- Harte Grenzen ziehen. Jede Person bekommt einen klar abgegrenzten Teil mit festen Schnittstellen, abgestimmt werden nur diese Schnittstellen. Das klappt, solange die Grenzen stehen bleiben. Bei neuen Projekten verschieben sie sich ständig.
- Regeln abstimmen. Wir sprechen über die Regeln, nach denen die KI arbeitet: Architektur, Benennung, was getestet wird. Die Regeln liegen im Projekt und gelten für alle. Das senkt die Reibung. Was die andere Person gerade baut, versteht man dadurch trotzdem nicht.
- Nur die Richtung prüfen. Reviews schauen auf das Ziel und die großen Entscheidungen. Das geht schneller, lässt aber genau die Details durch, an denen es später hakt.
- Die KI übergeben lassen. Am Ende einer Sitzung schreibt die KI auf, was sie entschieden hat und warum. Beim Nacheinander hilft das. Für das Nebeneinander entsteht zu viel Text, den niemand liest.
Vielleicht ist das für den Moment die ehrliche Antwort: ein Projekt, eine Person, und alle anderen können übernehmen. Teamarbeit fände dann zwischen den Projekten statt, beim Austausch über Regeln, Werkzeuge und Fehler. Ganz zufrieden sind wir damit nicht. Manche Aufgaben sind auch mit KI zu groß für eine Person, und manche Entscheidungen werden besser, wenn zwei Leute darüber streiten.
Wer einen Weg gefunden hat, wie mehrere Menschen gleichzeitig an einem KI-gebauten Projekt arbeiten, ohne dass die Abstimmung alles auffrisst: Wir würden gern davon hören.