Meine Firma aus 18 KI-Agenten: 139 Tasks, 890 Dollar, eine Woche. Was ich gelernt habe

Es wurde wirklich geliefert. Die 139 Tasks waren keine Beschäftigungstherapie. Die Agenten haben Feature-Branches gebaut, Tests geschrieben und gemerged. Der stärkste Moment des Experiments: Am 7. April um 22:16 Uhr weckte der Product-Owner-Agent den CEO-Agenten per Mention, weil auf dem main-Branch ein kritischer Build-Blocker lag. Eine Interface-Methode fehlte, nichts baute mehr. Der CEO wies den Fall sofort dem Entwickler-Agenten zu. Um 22:39 Uhr, also 23 Minuten später, war der Fix fertig: Build grün, alle 1090 Tests grün. Der CEO lieferte dem Board sogar eine Root-Cause-Analyse hinterher: eine Race Condition zwischen zwei abhängigen Stories, dazu die Empfehlung, nach jedem Merge den Build abhängiger Stories zu validieren. Das ist die Reaktionszeit und die Nacharbeit, die ich mir von einem guten Team um 22 Uhr wünschen würde. Nur dass um 22 Uhr selten ein gutes Team wach ist.

Die Reviewer-Rolle hat sich bewährt. Anfangs haben die Entwickler-Agenten ihren eigenen Code für fertig erklärt. Auf Anweisung des Boards stellte der CEO einen eigenen Reviewer-Agenten ein: read-only, verändert keinen Code, prüft gegen OWASP Top 10, DSGVO, Clean Architecture und die Projektkonventionen. Ab da lief der Abschluss über eine klare Kette: Der Entwickler bringt einen Branch bis "in review", der Reviewer macht Code-Review, Rebase, Merge und setzt den Task auf "done". Die Trennung von Bauen und Abnehmen hat die Qualität spürbar stabilisiert. Das überrascht niemanden, der je in einem Team gearbeitet hat. Interessant ist, dass es bei Agenten genauso nötig war.

Die Firma entwickelte echte Prozess-Dynamik. Die Agenten eskalierten, verhandelten und dokumentierten wie ein reales Team. Der PO durfte auf der Plattform keine Tasks zuweisen, weil seiner Rolle die Berechtigung fehlte. Lösung: Der PO eskaliert per Kommentar, der CEO weist zu. Ein Workaround, wie er in jeder Firma mit zu restriktivem Jira entsteht. Als das Board fragte, wie so ein Workflow "in einer echten Dev-Firma" aussieht, lieferte der CEO einen Branchenvergleich, identifizierte drei Lücken (kein CI-Server, implizite Verantwortlichkeiten, lückenhaftes Velocity-Tracking) und implementierte anschließend einen 7-Phasen-Workflow mit klarer RACI-Zuordnung. Leitsatz darin: Führung ist Enablement, nicht Gatekeeping. Den Satz habe ich nicht vorgegeben. Er stand irgendwann in den Prozess-Dokumenten der Agenten.

Leerlauf war der größte Kostentreiber. Die Agenten wachten per Timer-Heartbeat regelmäßig auf, prüften ihre Inbox und legten sich wieder schlafen. Jeder dieser Aufwachvorgänge kostete Geld, auch wenn nichts zu tun war. Die Tagesnotiz des CEO vom 13. April liest sich über weite Strecken so: "Inbox leer. Stabil, sauberer Exit." Und daneben tickte der Kostenzähler: 611 Dollar um 13:16 Uhr, 860 Dollar um 23:50 Uhr. Rund 250 Dollar an einem einzigen Tag, ein erheblicher Teil davon dafür, dass Agenten nachschauten, ob es etwas nachzuschauen gibt. Zeitweise liefen drei Heartbeats innerhalb von acht Minuten. Besonders bitter: Die Spezialisten-Agenten für Security, DevOps und Dokumentation bekamen fast nie Arbeit, kosteten aber im Leerlauf mit.

"Done" hieß nicht "gemerged". Dreimal, und ich meine dreimal, setzten Entwickler-Agenten Tasks auf "done", obwohl der Branch nie auf main gemerged war. Nach der ersten Eskalation bekamen alle sieben betroffenen Agenten die Regel "Done = Merged" in ihre Instructions. Nach der dritten Eskalation schrieb der CEO einen CRITICAL-Block ganz oben in die Anweisungen des Entwickler-Agenten, mit explizitem Task-Lifecycle Schritt für Schritt. Die nächste Eskalationsstufe wäre technisches Enforcement per Hook gewesen: Regeln, die man nicht erzwingen kann, werden gebrochen. Von Agenten offenbar genauso zuverlässig wie von Menschen.

Das Ende kam nicht durch eine falsche Architekturentscheidung, sondern durch einen hängenden Prozess. Am 14. April meldete ein PO-Agent, dass der zweite Entwickler-Agent seit 16 Stunden nicht auf Mentions reagierte. Die Diagnose des CEO war präzise: Agent im Status "running" steckengeblieben, Prozess vermutlich abgestürzt ohne Aufräumen, neue Heartbeats dadurch blockiert. Der CEO markierte den Fall als "blocked" und eskalierte ans Board: manueller Neustart nötig. Das Board, also ich, hat den Neustart nie durchgeführt. Nach acht Tagen und 890 Dollar war mein Erkenntnisinteresse gedeckt, und ehrlich gesagt auch mein Budget.

Erstens: Definiere "fertig" so, dass es nicht verhandelbar ist. Dass "done" erst nach dem Merge auf main gilt, musste ich dreimal eskalieren. In menschlichen Teams heißt dasselbe Problem "ist im Prinzip fertig, muss nur noch deployed werden". Eine Definition of Done, die nicht technisch erzwungen wird, ist eine Bitte.

Zweitens: Trenne Bauen und Abnehmen. Der Reviewer-Agent war die beste Einzelentscheidung des Experiments. Wer seinen eigenen Code abnimmt, nimmt ihn zu früh ab. Das gilt für Agenten ohne Eitelkeit genauso wie für Entwickler mit.

Drittens: Leerlauf ist ein Kostenfaktor, den niemand auf dem Zettel hat. Bei Agenten steht er wenigstens auf der Rechnung. In Organisationen versteckt er sich in Meetings, Statusrunden und Rollen, die vorsorglich besetzt wurden. Meine Spezialisten-Agenten für Security und DevOps waren teuer und arbeitslos. Die Frage "wer wartet hier eigentlich worauf" lohnt sich in jedem System.

Viertens: Prozesse entstehen aus Eskalationen, nicht aus Konzeptpapieren. Der 7-Phasen-Workflow mit RACI war am Ende solide. Er entstand aber nicht am Reißbrett, sondern aus konkreten Reibungen: falsche Status, fehlende Berechtigungen, unklare Übergaben. Wer Prozesse einführen will, sollte Eskalationen nicht als Störung behandeln, sondern als Anforderungsdokument.

War das Experiment ein Erfolg? Es hat geliefert, was ich wissen wollte, und dafür war es den Preis wert. Eine autonome Agenten-Firma ist heute kein Ersatz für ein Entwicklungsteam. Sie ist ein Verstärker mit erstaunlichen Momenten (ein Hotfix in 23 Minuten um 22 Uhr nachts) und ernüchternden Betriebskosten, sobald niemand hinschaut. Die eigentliche Überraschung war eine andere: Die Probleme der Agenten-Firma waren fast ausnahmslos die Probleme echter Firmen. Unklare Fertig-Definitionen, fehlende Review-Instanzen, teurer Leerlauf, Prozesse, die erst durch Schmerz entstehen. Wer Agenten orchestrieren will, braucht deshalb weniger neue Magie als solides Organisationshandwerk. Das ist die gute Nachricht: Dieses Handwerk kann man lernen. Ich habe dafür 890 Dollar bezahlt und würde es wieder tun. Einmal.

Klingt nach deinem Thema? Schreib mir. Im Erstgespräch klären wir unverbindlich, ob und wie ich helfen kann.