Vier aus meinem KI-Team haben nie eine einzige Anfrage bekommen. Keine Fehlermeldung, sie kamen einfach nie dran, weil ihr Name in einer alten Liste fehlte. Angefangen hat das im April, als KIRA lernte, Anfragen zu zerlegen und zu verteilen. Die Lehre daraus gilt für jede Liste, die irgendwo von Hand gepflegt wird.
Für dich in 30 Sekunden
- Niemand hakt die eigene Arbeit ab, auch keine KI. Prüfen soll immer jemand anderes als der, der gebaut hat.
- Eine Liste, die von Hand gepflegt wird, ist eine künftige Lücke. Jede Information gehört an genau eine Stelle.
- Ein Prüfprogramm, das schweigt, beweist nur, dass es nichts gefunden hat. Es beweist nicht, dass nichts da ist.
Lesezeit rund 7 Minuten
Was ich wollte: eine Stelle, die Anfragen annimmt
Mit LEON und MARA lief es gut, solange jeder seinen festen Ablauf hatte. Aber meine Anliegen kommen nicht sortiert. „Auf der Website ist ein Fehler, und dazu sollte es einen Artikel geben“ betrifft gleich mehrere Bereiche. Wer kümmert sich darum, in welcher Reihenfolge, und wer prüft, ob es wirklich erledigt ist?
Am Abend des 10. April stand in einer Strategie-Besprechung schon das ganze geplante Team fest, mit KIRA an der Spitze und Rollen von Technik über Recht bis Finanzen. Das Konzept dazu habe ich am selben Tag freigegeben. Damit war klar: Es braucht eine Stelle, die Anfragen annimmt und verteilt, so wie in einer echten Agentur.
Was ich gemacht habe: Anfragen zerlegen und verteilen
Am 10. April: ein Platz für Anfragen
Die erste Stufe war unspektakulär, aber grundlegend. Jede Anfrage bekam einen eigenen Eintrag, und darunter hingen ihre Teilaufgaben, je eine pro zuständigem Manager. Eine Teilaufgabe kann von einer anderen abhängen: Erst wenn die eine erledigt ist, beginnt die nächste. Eine eigene Seite, das Agentur-Dashboard, zeigt alle Anfragen als Baum mit ihren Teilaufgaben und dazu den Status des Teams.
Eine Entscheidung von diesem Tag ist wichtiger als jede Technik: Die Aufgaben selbst blieben an genau einer Stelle, in meiner damaligen Aufgabenverwaltung. Die Agentur verwies nur darauf und steuerte. Sonst hätte es jede Aufgabe zweimal gegeben, und früher oder später hätten die beiden Fassungen nicht mehr zusammengepasst. Der Grundsatz dahinter ist in KIRAs Arbeitsregeln eingegangen: Eine Information steht an genau einer Stelle.
Am 12. April: KIRA verteilt
Zwei Tage später kam die eigentliche Neuerung: das Verteilen. Ich schreibe eine Anfrage, und mit einem Klick auf „Anfrage routen“ liest Claude sie, zerlegt sie in Teilaufgaben, wählt die passenden Manager aus und legt fest, wer auf wen wartet. Routen heißt hier einfach: den richtigen Weg festlegen.
Am selben Tag kamen drei Kollegen dazu, wieder mit Namen als Kürzel:
TINA kümmert sich um Fehler und Änderungen am Code. JUST prüft, ob etwas sicher und rechtlich sauber ist. FINN behält offene Rechnungen im Blick. Und auf der Seite mit den Berichten bekam KIRA selbst eine neue Kachel ganz oben: als Geschäftsführung, die koordiniert und verteilt.
Niemand hakt die eigene Arbeit ab
Der wichtigste Gedanke dieser Tage steckt in einer einfachen Kette:
TINA baut, JUST prüft die Sicherheit, LEON prüft das Ergebnis. Und als feste Regel: TINA darf ihre eigene Arbeit nie selbst als erledigt markieren. In einem echten Team nennt man das Vier-Augen-Prinzip, hier sind es sogar sechs Augen. Wer die eigene Arbeit abnimmt, neigt dazu, sie für gelungen zu halten, und eine KI macht da keine Ausnahme.
Dazu kam eine Sperre für MARA: Solange für ein Projekt noch Mängel aus einer Qualitätsprüfung offen sind, schreibt sie dort keinen neuen Artikel. Erst wird repariert, dann wird weiterproduziert.
Was schwierig war: eine Liste, die niemand nachtrug
Am 9. April, also kurz vor all dem, habe ich einen Satz gesagt, der später in KIRAs Regeln aufgenommen wurde, sinngemäß: Es wird an einer Stelle etwas gemacht, an allen anderen ignoriert, und dann wundern wir uns, warum vieles nicht funktioniert. Beim Verteilen ist genau das passiert, nur langsamer.
Im Auftrag an das Sprachmodell, das die Anfragen verteilt, waren die Manager von Hand beschrieben. Dazu kam eine Liste der Namen, die es überhaupt wählen durfte. Beides stand von Hand im Code und wurde nicht mehr vollständig nachgezogen, während das Team weiterwuchs. Aufgefallen ist es erst am 15. September:
Betroffen waren NOVA, VERA, LISA und PAUL: Sie hatten eine Stellenbeschreibung und gehörten zum Team, waren für den Verteiler aber unsichtbar. Das Tückische daran: Einen Fehler mit Meldung repariert man, eine Lücke ohne Meldung fällt erst auf, wenn jemand nachzählt.
Dieselbe Lücke steckte noch an zwei weiteren Stellen. Die nächtliche Zusammenfassung las nur die Einträge von fünf Managern, die täglichen Berichte der anderen kamen dort nicht an. Und das Manifest sprach noch von einem Team aus sechs KI-Managern.
Repariert wurde es nicht, indem die Liste ergänzt wurde. Seitdem gibt es genau eine Stelle, an der das Team steht, und alles andere wird daraus berechnet: der Auftrag an das Sprachmodell, die erlaubten Namen, die Übersichten. Kommt jemand dazu, wird nur noch diese eine Stelle geändert. Und ein Prüfprogramm meldet, wenn irgendwo doch wieder eine Liste von Hand auftaucht.
Dieses Prüfprogramm gab es übrigens schon seit dem 10. September, und es hatte keine einzige Lücke gemeldet. Es erkannte Listen nur in einer bestimmten Schreibweise im Code, die veralteten Stellen waren aber als gewöhnlicher Text geschrieben, auch dort, wo sie im Code standen. Seit dem 15. September erkennt es auch Aufzählungen im Text. Ein Prüfprogramm, das schweigt, beweist nur, dass es nichts gefunden hat, nicht, dass nichts da ist.
Merksatz:
Eine Liste, die von Hand gepflegt wird, ist eine künftige Lücke.
Was du daraus mitnehmen kannst: Tipps für die Arbeit im KI-Team
- Zerlege Anfragen in Teilaufgaben mit klarer Reihenfolge. Wer auf wen wartet, ist genauso wichtig wie die Frage, wer was tut.
- Lass niemanden die eigene Arbeit selbst abhaken. Auch und gerade keine KI.
- Halte jede Aufgabe an genau einer Stelle. Alles andere verweist darauf.
- Erst reparieren, dann weiterproduzieren. Offene Mängel stoppen neue Arbeit im selben Bereich.
- Berechne Listen, statt sie zu pflegen. Wer im Team ist, steht an einem Ort, alles andere liest von dort.
Ein Beispiel: eine Anfrage in drei Schritten
Wie sich Anfragen zerlegen und verteilen lassen, zeigt der Satz vom Anfang: „Auf der Website ist ein Fehler, und dazu sollte es einen Artikel geben.“ Das ist nicht eine Aufgabe, das sind mindestens zwei, und sie hängen voneinander ab. Nach den Regeln aus diesem Kapitel sieht die Zerlegung so aus, als Beispiel und nicht als Protokoll eines echten Durchlaufs:
- Zuerst der Fehler. TINA behebt ihn. Daran hängt alles andere, denn ein Artikel über eine Seite, die noch nicht funktioniert, käme zu früh.
- Dann die Prüfung. JUST sieht nach, ob die Änderung sicher ist. LEON prüft, ob der Fehler wirklich weg ist, und erst er hakt ab.
- Zuletzt der Artikel. MARA beginnt erst, wenn nichts mehr offen ist. Das folgt derselben Logik wie ihre Sperre: erst reparieren, dann weiterproduzieren.
Das Wichtigste an dieser Zerlegung sind nicht die Namen, sondern die Reihenfolge. Wer auf wen wartet, entscheidet, ob am Ende ein Artikel über einen behobenen Fehler entsteht oder über einen, den es noch gibt. Solche Abhängigkeiten festzulegen war ab dem 12. April Teil des Routens. Wer eine große Anfrage dagegen in einem Rutsch abarbeitet, merkt oft erst am Ende, dass ein Schritt auf einen anderen hätte warten müssen.
Woran du eine Liste von Hand erkennst
Die Lücke aus diesem Kapitel war nicht versteckt, sie stand offen im Code und im Text. Gefährlich daran ist, dass jede einzelne Stelle für sich harmlos aussieht. Drei Anzeichen helfen, so etwas früher zu finden, auch ohne Programmierkenntnisse:
- Dieselben Namen stehen an mehreren Orten. Bei mir waren es der Auftrag an das Sprachmodell, die erlaubten Namen und die nächtliche Zusammenfassung. Jede dieser Stellen muss bei jeder Änderung mitgedacht werden.
- Eine Anzahl steht fest im Text. „Ein Team aus sechs“ stimmt nur, bis jemand Neuer dazukommt.
- Etwas fehlt, ohne sich zu melden. Wer nie drankommt, beschwert sich nicht. Frag deshalb nicht nur, ob alles funktioniert, sondern auch, ob jeder vorkommt, der vorkommen sollte.
Die Lösung ist in allen drei Fällen dieselbe: eine Stelle, an der das Team steht, und alles andere liest von dort. Das klingt nach Aufwand, erspart dir aber bei jeder Änderung die Suche nach den übrigen Stellen. Wer im KI-Team Anfragen zerlegen und verteilen lässt, braucht diese eine Stelle besonders, denn der Verteiler kann nur wählen, wen er kennt.
Ohne selbst zu programmieren
Gib der KI eine größere Anfrage und lass sie in Teilaufgaben mit Reihenfolge zerlegen, ohne dass sie gleich etwas erledigt. Dann siehst du, ob die Zerlegung stimmt, bevor Arbeit entsteht. Und das Vier-Augen-Prinzip geht auch im normalen Chat: Lass einen Text in einem neuen Gespräch prüfen, nicht in dem, in dem er entstanden ist, und gib der Prüfung einen eigenen Auftrag, etwa „Was fehlt, was ist falsch, was ist missverständlich?“
Fragen, die du der KI stellen kannst
- „Zerleg diese Anfrage in Teilaufgaben. Wer müsste sie in einem kleinen Team erledigen, und in welcher Reihenfolge?“
- „Wer in meinem Ablauf prüft die Arbeit eines anderen, und wo hakt jemand seine eigene Arbeit ab?“
- „Such in meinem Projekt jede Stelle, an der die Mitglieder meines Teams von Hand aufgezählt werden, und nenn mir Datei und Zeile.“ Das geht nur, wenn die KI deine Dateien wirklich lesen kann. Im normalen Chat erfindet sie sonst leicht Dateien und Zeilen.
Wie es weitergeht: eine Webapp für Projekte und Kunden
Während KIRA Kollegen bekam, lief daneben schon seit Mitte März etwas Zweites: eine eigene Webapp für meine Projekte und Kunden, auf einem eigenen Server und getrennt von KIRA. Kaum war die Webapp umgebaut, schickte meine alte Projekt-App, die noch parallel lief, neun Tage lang Daten an eine Adresse der Webapp, die es nach dem Umbau nicht mehr gab. Angekommen ist dort nichts, und keine der beiden Seiten schlug Alarm. Wie es dazu kam, erzähle ich in Kapitel 11.
Was du noch wissen solltest
So heißt der Auftrag, den ein Sprachmodell bekommt, samt allem, was man ihm dazu mitgibt. Über dein Projekt weiß das Modell nur, was dort steht: Fehlt ein Teammitglied in der Beschreibung, existiert es für das Modell nicht. Deshalb lohnt es sich, Prompts genauso sorgfältig zu pflegen wie Code.
Nicht unbedingt. Oft ist es dasselbe Sprachmodell, das je nach Rolle einen anderen Auftrag, andere Werkzeuge und andere Grenzen bekommt. Was einen Manager ausmacht, steckt dann in seiner Stellenbeschreibung, nicht im Modell. Ein kleineres Modell kann man gezielt dort einsetzen, wo die Aufgabe einfach ist.
Das ist der englische Fachbegriff für den Grundsatz aus diesem Kapitel: eine Information an genau einer Stelle. Ein Gegenbeispiel aus dem Alltag ist eine Kundenadresse, die in der Buchhaltung und zusätzlich in einer eigenen Tabelle steht. Ändert sich die Adresse, stimmt früher oder später eine der beiden nicht mehr, und niemand weiß, welche richtig ist.
Sie bringt beim Prüfen dieselben Annahmen mit, mit denen sie gearbeitet hat, und übersieht deshalb leicht dieselben Fehler wieder. Eine Prüfung bringt mehr, wenn sie in einem eigenen Durchlauf mit eigenem Auftrag passiert, zum Beispiel mit der Frage, was fehlt oder was schiefgehen kann. Am besten prüft sie gegen etwas Nachprüfbares, etwa ob eine Seite wirklich lädt.
