Breaking the Loop: Warum KI-⁠Agenten nie von allein fertig werden

Mehr Output, und der Umsatz merkt nichts davon

“Unsere Teams produzieren mit Agenten viel mehr. Warum sehen wir das im Umsatz nicht?” Diese Frage kennen wir aus unserer eigenen Kundenarbeit.

Abends wirft ein Team seine Factory an. Agenten ziehen sich Tickets, schreiben Code, lassen die Tests laufen, reviewen sich gegenseitig und bessern nach, wo die Prüfungen etwas ablehnen. Morgens warten Pull Requests, die meisten grün. Dazu kommen neue Tickets, die die Agenten über Nacht selbst angelegt haben.

Dass der Output steigt, lässt sich messen. Faros AI (öffnet in einem neuen Tab) hat 2025 Daten von mehr als 10.000 Entwickler:innen aus 1.255 Teams ausgewertet. Entwickler:innen in Teams mit hoher KI-Nutzung mergen 98 % mehr Pull Requests, und die Review-Zeit wächst um 91 %. Dabei nutzten die meisten Entwickler:innen im Datensatz nur Autovervollständigung, Agenten kaum. Mit Agenten wird der Sprung größer. Anthropic berichtet (öffnet in einem neuen Tab), im Mai 2026 im Schnitt rund 2.500 Code-Änderungen pro Tag gemergt zu haben und im September mehr als 30.000. Das waren so viele, dass Anthropic git für sein Monorepo durch einen Eigenbau ersetzt hat.

+98 % gemergte Pull Requests und 91 % mehr Review-Zeit in Teams mit hoher KI-Nutzung (Faros AI, 2025).

Im Unternehmen als Ganzem kommt davon wenig an. Auf dieser Ebene fand die Faros-Studie keinen signifikanten Zusammenhang zwischen KI-Nutzung und besserem Durchsatz, besseren DORA-Werten oder besserer Qualität. Als Gründe nennt sie Engpässe nach dem Coden, allen voran im Review, und Teams, die KI unterschiedlich stark nutzen. Wenn der Zuwachs schon dort versickert, wundert es nicht, dass er im Umsatz fehlt.

Bei Teams, die mit Agenten arbeiten, sehen wir einen weiteren, eigenen Grund: Agenten hören nicht von selbst auf. Ein Review-Agent findet in jeder Runde etwas. Jedes Finding wird umgesetzt, und jede Umsetzung liefert das nächste.

Ein Mensch sagt nach der zweiten Runde “gut genug” und lässt den Rest liegen. Vieles, was zählte, meldet sich ohnehin wieder: als Bug oder als Alarm aus dem Betrieb. Ein Agent dagegen kennt kein “gut genug”, solange ihm niemand eines mitgibt. Ein weiteres Finding kostet ihn keine Aufmerksamkeit, also sucht er weiter: noch eine Abstraktion, noch eine Optimierung für eine Last, die es nicht gibt.

Einen Baustein dieses Musters haben Jin und Chen (öffnet in einem neuen Tab) 2026 im Labor gezeigt: Sprachmodelle halten korrekten Code häufig für fehlerhaft, und noch häufiger, wenn sie ihr Urteil begründen und eine Korrektur vorschlagen sollen. Yoko Li von a16z (öffnet in einem neuen Tab) hat einen Agent Loop vermessen, dessen Ziel unerreichbar war. Zwei Drittel der Kosten brachten keinen Fortschritt mehr. Ihr Fazit: Schleifen haben “no idea how to stop”.

Das passiert im Kleinen wie im Großen. Im einzelnen Lauf taucht immer noch ein Finding auf, in der Factory als Ganzes immer noch ein Ticket. Bremsen gibt es für beides: eine maximale Rundenzahl, ein Token-Budget. Wir brauchen sie, doch sie deckeln nur den Aufwand. Wann etwas fertig ist, sagt keine von ihnen.

In der Factory selbst bleibt dafür ein einziges Kriterium: grün. Grün heißt, die Änderung besteht ihre Prüfungen. Ob es die richtige Änderung war, verrät kein Test. Und Code kann eine Prüfung bestehen, ohne besser zu werden. Fehlt die Wirkungsannahme, liefert eine Factory deshalb schnell Features, deren Nutzen niemand geprüft hat. Sie wird zur Endlosschleife, die Tokens verbrennt und Output erzeugt.

Der Titel ist eine Anleihe bei Judas Priest: “Breaking the Law”, 1980. Wer programmiert, kennt break, die Anweisung, die eine Schleife beendet. Ein break für “das reicht jetzt” hat die Factory nicht. Das muss ihr jemand mitgeben.

Den Takt gibt die langsame Schleife vor

Die innere Schleife ist die Factory. hackers&wizards definiert sie als das System, das Softwareänderungen produziert: Sie nimmt eine Absicht entgegen, zerlegt sie in begrenzte Arbeit, versorgt Agenten mit Kontext und nimmt Ergebnisse nach festgelegten Prüfungen an. Schreiben, prüfen, korrigieren: Eine solche Runde dauert Minuten.

Die äußere Schleife ist die Produktarbeit, und sie reicht bis zum Markt. Aus Strategie und Kundenwissen entsteht eine Annahme über die Wirkung. Das Team liefert aus, der Markt reagiert, und was dabei herauskommt, verändert das Wissen der Organisation über ihre Kunden. Ein Durchlauf dauert mindestens Wochen. Markus, einer von uns beiden, hat diese Schleife und ihr Tempo in “AI Flow Dynamics” (öffnet in einem neuen Tab) ausführlich beschrieben.

Den Takt gibt die langsame Schleife vor

	Innere Schleife: die Factory	Äußere Schleife: Produkt und Markt
Frage	Ist es richtig gebaut?	Ist es das Richtige?
Tempo	Minuten	Wochen
Geprüft gegen	Spezifikation und Akzeptanzkriterien	Erfolgsmodell und Marktdaten
Ergebnis	Output	Outcome
Endet	von allein nicht	mit einer Entscheidung, von der Frist erzwungen

Die innere Schleife macht das Team effizient, die äußere macht es effektiv. Schnell gebauter Code bringt nichts, wenn er in die falsche Richtung geht. Die richtige Richtung bringt nichts, wenn der Code dafür zu lange braucht. Erfolgreich ist, wer beides gemeinsam optimiert.

Kann ein Team mehr bauen, als es mit Kunden auswerten kann, ist die äußere Schleife der Bottleneck, und daran ändern auch mehr Agenten nichts. Ein Team kann an einem Nachmittag mehrere Optionen erzeugen. Es kann sie Kunden aber nicht im selben Tempo vorlegen und für jede ein sauberes Signal erwarten. Wie viele Features gleichzeitig bei Kunden im Test sein können, bestimmt deshalb das Feedback, das ein Team auswerten kann, nicht seine Baukapazität.

Vier Brüche, an denen ein Mensch entscheidet

Daraus leiten wir unsere Regel ab: Die innere Schleife läuft nur so weit, wie die äußere es zulässt. An vier Stellen braucht es die Entscheidung eines Menschen, sonst geht es nicht weiter. Diese Stellen heißen bei uns Brüche.

1. Weiterdenken: Ist die Idee plausibel genug, um mehr Aufmerksamkeit zu verdienen?
2. Bauen: Ist sie plausibel genug, um sie bauen zu lassen, und was darf das kosten?
3. Ausliefern: Ist das Gebaute gut genug, um an Kunden zu gehen?
4. Behalten: Hat es am Markt gehalten, was die Wirkungsannahme versprochen hat?

Das Beispiel

Durch die vier Brüche führt uns ein Beispiel. Es ist erfunden, seine Zahlen sollen nur den Ablauf zeigen.

Im Beispiel: der Bedarf

Ein B2B-Produkt unterstützt Teams bei der Projektsteuerung. In Interviews berichten Teamleiter, dass sie jeden Freitag den Projektstatus aus Aufgaben, Kommentaren und Gesprächen zusammensetzen. Das Team sammelt sieben Ideen für diesen Bedarf.

Erster Bruch: Keine Idee geht weiter ohne Wirkungsannahme

Viele Features entstehen morgens unter der Dusche. Früher fing danach die lange Arbeit erst an. Software war teuer, und das Team musste vorher erkennen, welche Variante die richtige ist.

Heute könnte jede dieser Ideen noch am selben Vormittag in der Factory landen. Deshalb fällt die erste Entscheidung, bevor die Factory startet, und sie braucht zunächst nur einen Satz.

Wenn dieses Feature erfolgreich ist, verändert sich für diese Menschen in dieser Situation Folgendes.

Dieser Satz ist die Wirkungsannahme. Erst danach legt das Team fest, an welcher Zahl es die Wirkung beobachten will und bis wann sie sich zeigen soll. Wirkungsannahme, Zahl und Frist zusammen sind das Erfolgsmodell. Es steht neben dem Bedarf in einer Feature-Datei.

Die Reihenfolge hat einen Grund: Nutzung ist noch kein Wert. Ein Sicherheitsgurt ist das Extrembeispiel: Sein Wert liegt im seltenen Ernstfall.

Für die Wirkungsannahme braucht ein Team Produktwissen, an das es herankommt: Strategie, Kundenwissen, KPIs, Research, frühere Features und was aus ihnen wurde. Für den Anfang genügen Markdown-Dateien, solange Menschen und Agenten sie finden und lesen können. Wir nennen das ein Product-Context-System. Darin steht, was die Organisation weiß, was sie vermutet und wo ihr Wissen dünn ist.

Schon dieser eine Satz sortiert aus. Oft sehen wir Features, die gebaut werden, ohne dass ihn vorher jemand aufgeschrieben hat.

Im Beispiel: das Erfolgsmodell

Für sechs der sieben Ideen kann der Product Manager die Wirkungsannahme schreiben. Für die bearbeitbare Wochenzusammenfassung steht in der Feature-Datei:

Wirkungsannahme: Teamleiter überarbeiten freitags einen Entwurf, statt den Status von Hand zusammenzusetzen.

Zahl: Mindestens 20 % der Teamleiter öffnen den Entwurf in mindestens drei verschiedenen Wochen, und mindestens die Hälfte dieser Teamleiter bearbeitet und teilt ihn. Öffnen allein wäre nur Nutzung. Erst ein geteilter Entwurf deutet darauf hin, dass er einen handgeschriebenen Status ersetzt hat.

Frist: acht Wochen.

Für die siebte Idee, ein Dashboard für die Geschäftsführung, findet der Product Manager keine Veränderung für die Teamleiter. Sie endet hier und hat keinen Token gekostet.

Zweiter Bruch: Mehrere Optionen bauen, jede mit eigenem Preisschild

Erst schätzen, dann aussortieren

Jede Idee, die den ersten Bruch übersteht, ist eine Option, also ein möglicher Weg, denselben Bedarf zu decken.

Vor die zweite Entscheidung setzen wir einen Forecast. Ein Skill, ein wiederverwendbarer Ablauf für Agenten, erhält die Feature-Datei und Zugriff auf das Product-Context-System. Mehrere Modelle schätzen aus verschiedenen Blickwinkeln, wie wahrscheinlich die Option die Ziele aus ihrem Erfolgsmodell erreicht. Heraus kommt eine Spanne, dazu die Quellen, die gefundenen Widersprüche und die Lücken. Liegen die Schätzungen weit auseinander, wird die Spanne breiter.

Mehr als eine grobe Näherung ist dieser Forecast nicht. Zwei Spannen lassen sich zudem nicht einfach nebeneinanderlegen: Eine kleine, fast sichere Verbesserung kann weniger wert sein als eine große, unsichere. Die Entscheidung bleibt bei einem Menschen.

Im Beispiel: der Forecast

Erst schätzen, dann aussortieren

Option	Forecast: Chance, die Ziele zu erreichen	Einschätzung
Bearbeitbare Wochenzusammenfassung	45 bis 60 %	Bedarf sichtbar, Vertrauen bleibt kritisch
Slack-/Teams-Digest	55 bis 70 %	Passt in einen vorhandenen Ablauf
Fragen an den Projektstatus	30 bis 55 %	Nutzungssituation noch unklar
Risikohinweise	50 bis 75 %	Hoher Nutzen möglich, abhängig von Datenqualität
Audio-Zusammenfassung	15 bis 40 %	Wenig Hinweise auf Bedarf an diesem Format
Präsentationsdeck	20 bis 30 %	Nur für einen kleinen Teil der Zielgruppe relevant

Der Product Manager streicht Audio und Präsentationsdeck. Vier Optionen dürfen gebaut werden.

Probefahrt statt Prospekt

Als Bauen noch teuer war, hätte das Team an dieser Stelle eine Option in die Entwicklung gegeben und dabei vielleicht die bessere verworfen. Bemerkt hätte es das nie, weil es nur Prospekte verglichen hätte. Hinterher hören wir dann oft: “Wir können nicht wissen, was dabei herausgekommen wäre, dafür gab es keinen A/B-Test.” Alle Optionen zu bauen, wäre zu teuer gewesen.

Weil Code inzwischen günstig entsteht, geht es anders. Die Factory baut mehrere Optionen für denselben Bedarf, und über ein Release ist damit noch nichts entschieden. Markus nennt das Option Storming (öffnet in einem neuen Tab). Gekauft wird erst nach der Probefahrt.

Das wirkt wie das Gegenteil dessen, was wir oben kritisiert haben. Dort verbrennt die Factory Tokens, hier lassen wir sie absichtlich Optionen bauen, die niemand ausliefert. Der Unterschied: Rechenzeit ist billig, knapp sind die Aufmerksamkeit der Menschen und das Signal vom Markt. Option Storming gibt das Billige aus, um das Knappe zu schonen. Im Beispiel erreichen drei von vier Optionen weder den Trunk, also den Hauptzweig des Produkts, noch den Markt.

Beliebig viele Optionen sind es trotzdem nicht. Jede Probefahrt kostet das Team Zeit, und wer mehr Optionen baut, als er ernsthaft ausprobieren kann, wählt dadurch nicht besser. So arbeitet Option Storming der äußeren Schleife zu: Statt Optionen früh aus dem Bauch heraus zu streichen, probieren wir sie gebaut aus und schicken nur die besten in den engsten Bottleneck, den Markt.

Die Bremsen bekommen einen Maßstab

Am Anfang jedes Laufs steht der Intake. Er erhält die Feature-Datei und prüft als Erstes, ob sie zum Bauen reicht. Nach unserer Erfahrung wird aus einer unklaren Anforderung ein unklarer Plan und aus dem Plan Code, den die Prüfungen ein ums andere Mal ablehnen. Ein guter Intake fragt deshalb beim Produktteam nach, bevor ein Agent auch nur eine Zeile schreibt. Fehlt dieser Schritt, baut die Factory womöglich perfekt das Falsche.

Dann starten die Agenten, ein eigener Lauf pro Option. Jetzt kommen die Bremsen vom Anfang wieder ins Spiel, diesmal mit einem Maßstab aus der äußeren Schleife.

Ein Budget pro Option. Product Manager und Engineering setzen es gemeinsam fest, in Euro für Tokens und in Korrekturrunden. Seine Höhe richtet sich danach, was dem Team die Entscheidung zwischen den Optionen wert ist. Ist das Budget aufgebraucht, endet der Lauf, und auch dieses Ergebnis schaut sich das Team an. Vielleicht war die Option zu groß geschnitten oder zu vage beschrieben, oder es fehlen ihr Daten.

Akzeptanzkriterien entscheiden, welches Finding zählt. Der Review-Agent findet weiterhin in jeder Runde etwas. Umgesetzt wird aber nur, was gegen ein Akzeptanzkriterium oder eine Prüfung verstößt, Sicherheitsprüfungen eingeschlossen. Belegt der Agent einen Fehler, den noch keine Prüfung abdeckt, etwa eine Sicherheitslücke oder falsche Daten, wird er behoben und als neues Kriterium oder neue Prüfung festgeschrieben.

Alles Übrige wandert auf eine Liste, die erst ein konkreter Anlass wieder öffnet: ein Bug, ein Alarm aus dem Monitoring, eine gemessene Latenz. Bis dahin ist der Code gut genug. Auf diese Weise endet auch der einzelne Lauf, entweder an erfüllten Kriterien oder am Budget.

Eine Prüfung sagt, wofür sie da ist. Eine Linter-Meldung wie function is too complex (11 > 5) teilt dem Agenten mit, dass etwas nicht stimmt, aber nicht, wie es besser wird. Häufig verschiebt er daraufhin nur Verzweigungen in Hilfsfunktionen.

Liina Suoniemi (öffnet in einem neuen Tab) hat das in einem kleinen Test gemessen. Fragte eine Anleitung, welche Aufgabe die Funktion hat, stieg bei Sonnet 4.6 der Anteil echter Vereinfachungen von 11 % auf 78 %.

Tools wie Habit Hooks (öffnet in einem neuen Tab) tauschen jede Meldung gegen eine kurze Anleitung.

Optionen enden vor dem Trunk. Jede Option entsteht als Wegwerf-Build auf einem eigenen Branch, mit Preview-Umgebung und Testdaten und mit Belegen: Screenshots, einem aufgezeichneten Klickpfad, Testergebnissen. Solche Builds kosten Tokens und den Betrieb der Preview.

Auf Dauer teuer wird Code im Trunk. Dort muss jemand die Verantwortung für ihn tragen, und Optionen, die nie nebeneinander existieren sollen, stehen sich gegenseitig im Weg. Was das Team nicht auswählt, räumt die Factory ab. Die Feature-Datei hält fest, was gebaut wurde und warum es endete.

Die Messung gehört zu den Akzeptanzkriterien. Steht im Erfolgsmodell, dass Teamleiter den Entwurf öffnen, bearbeiten und teilen, baut die Factory die passenden Events gleich mit. Eine Prüfung stellt sicher, dass sie auch ankommen. Wer diesen Teil weglässt, hat am Ende der Frist die vereinbarte Zahl nicht.

Im Beispiel: der Bau

Jede Option bekommt 150 Euro für Tokens und höchstens sechs Korrekturrunden. Vier Optionen kosten also höchstens 600 Euro für Tokens.

Der Intake fragt, was die Wochenzusammenfassung zeigen soll, wenn ein Projekt in der Woche keine Aktivität hatte. Jede Option läuft gegen Testdaten aus drei typischen Teams, eines davon mit lückenhaft gepflegten Aufgaben.

Die Risikohinweise verbrauchen ihre sechs Korrekturrunden, weil die lückenhaften Daten immer neue Sonderfälle erzeugen. Der Lauf endet dort, mit einer unvollständigen Preview. Bis hierhin hat keine Zeile den Trunk erreicht.

Dritter Bruch: Gebaut heißt noch nicht ausgeliefert

Nun kommt die Probefahrt. Product Manager, Design und Engineering klicken sich durch die Previews und holen, wo es sinnvoll ist, einzelne Kunden dazu. Der Forecast-Skill bewertet die Optionen erneut, diesmal mit den Belegen aus der Factory.

Streng bleibt die Auswahl trotzdem, denn Marktfeedback ist knapp und kommt langsam. Sie kommt nur später, wenn das Team mehr weiß.

Im Beispiel: die Probefahrt

Dritter Bruch: Gebaut heißt noch nicht ausgeliefert

Gebaute Option	Vorher	Nachher	Beobachtung
Bearbeitbare Wochenzusammenfassung	45 bis 60 %	60 bis 75 %	Quellenangaben und Bearbeitbarkeit erhöhen das erwartete Vertrauen
Slack-/Teams-Digest	55 bis 70 %	50 bis 60 %	Im Ablauf fehlen Kontrolle und Korrekturmöglichkeit
Fragen an den Projektstatus	30 bis 55 %	45 bis 60 %	Die konkrete Interaktion ist nützlicher als die Beschreibung
Risikohinweise	50 bis 75 %	25 bis 45 %	Lückenhafte Daten erzeugen zu viele falsche Hinweise

Vor dem Bau hatten der Digest und die Risikohinweise die höchsten Forecasts. Ein Team, das nach dem Prospekt entschieden hätte, hätte vermutlich eine dieser beiden gebaut. Nach der Probefahrt führt die Wochenzusammenfassung, und die Risikohinweise liegen hinten. Dem Digest fehlt genau das, was die Wochenzusammenfassung hat: die Möglichkeit zu korrigieren.

Das Problem der Risikohinweise war in der Beschreibung ein Halbsatz, in der Preview ist es eine Seite voller Fehlalarme. Die Factory lernt daraus: Der Intake fragt künftig bei jedem Feature, das Inhalte aus Projektdaten generiert, nach dem Verhalten bei lückenhaften Daten.

Abgenommen wird die Option, nicht der Diff

Ein Pull Request legt jemandem eine einzelne Änderung zur Prüfung vor. Agenten erzeugen solche Änderungen schneller, als Menschen sie lesen können. Kleinere Pull Requests und Agenten, die einen Teil davon selbst freigeben, verschaffen etwas Luft, so macht es etwa PostHog (öffnet in einem neuen Tab). Entschieden wird aber eine Ebene höher: Das Produkt nimmt die Option ab, nicht den Diff.

Der Build der gewählten Option wird nicht gemergt. Als Wegwerf-Build sollte er eine Entscheidung ermöglichen, nicht bleiben. Er dient als Vorlage, nach der die Factory das Feature in kleinen Schritten auf dem Trunk neu baut, mit denselben Prüfungen wie jeder Lauf und mit eigenem Budget. Abgenommen ist das Feature, sobald es die Akzeptanzkriterien und Klickpfade der Option besteht. Riskante Schritte lesen Engineers, den Rest prüft ein Review-Agent. Den Code der verworfenen Optionen liest kein Mensch. Dass wir neu bauen statt mergen und abräumen statt aufheben, beruht auf einer Annahme: Bei Token-Kosten von wenigen hundert Euro ist Neubauen billiger als Aufheben und Pflegen.

Ausliefern mit Verfallsdatum

Technisch verlangt der dritte Bruch, dass Deploy und Release getrennt sind. Die Factory bringt das Feature hinter einem Feature Flag in Produktion und versieht es mit einem Verfallsdatum, der Frist aus dem Erfolgsmodell. Überschreiten Fehlerraten oder Latenzen die vereinbarten Schwellen, rollt die Factory die Änderung von sich aus zurück.

Ob das Feature wirkt, zeigt sich dagegen erst im Lauf der Frist, im Beispiel innerhalb von acht Wochen. Wer es in dieser Zeit zu sehen bekommt, entscheidet der Product Manager. An dieser Stelle gibt die äußere Schleife den Takt vor, und die innere wartet.

Im Beispiel: die Auslieferung

Die Probefahrt kostet drei Menschen je zwei Stunden. Das Team liefert die Wochenzusammenfassung an eine begrenzte Kundengruppe aus, mit acht Wochen Frist. Die Fragen an den Projektstatus haben in der Probefahrt positiv überrascht, und das Team merkt sie sich für später. Die Feature-Dateien mit Forecast und Belegen bleiben, die Builds der verworfenen Optionen werden abgeräumt.

Vierter Bruch: Ein Feature muss sich seinen Platz verdienen

Nach unserer Erfahrung bleibt in den meisten Produkten alles Ausgelieferte, bis jemand die Kraft aufbringt, es wieder zu entfernen. Ohne Frist leidet die äußere Schleife am selben Problem wie die innere: Sie hört nicht auf. Die Erfahrung großer Experimentierer (öffnet in einem neuen Tab) spricht aber dagegen, dass Bleiben der Normalfall sein sollte. Microsoft berichtet, dass rund ein Drittel der getesteten Ideen positiv wirkt. Bei Booking.com verbessern neun von zehn solcher Ideen die Metriken nicht.

Mit dem Verfallsdatum kehrt sich der Normalfall um. Ist die Frist abgelaufen, entfernt die Factory das Feature wieder, außer ein Mensch entscheidet, dass es bleibt. Auch dieser Normalfall ist eine Entscheidung, nur hat das Team sie schon mit der Frist getroffen. Damit hat auch die äußere Schleife eine Grenze. Die innere hat ein Budget in Tokens und Korrekturrunden, die äußere eine Frist in Wochen. Das letzte Review übernimmt in diesem Ablauf der Markt, und es betrifft ein ganzes Feature.

Für Projekte kennt Basecamp den Circuit Breaker (öffnet in einem neuen Tab): Was im gesetzten Zeitraum nicht fertig wird, bekommt im Regelfall keine Verlängerung. Wir übertragen ihn auf ausgelieferte Features. Wie streng die Frist ausfällt, legt das Team fest.

• In der harten Variante fliegt raus, was seine Wirkung nicht zeigt.
• Eine mittlere Variante lässt eine Verlängerung zu.
• In der mildesten entfernt die Frist nichts und erzwingt nur am Stichtag eine Entscheidung.

So oder so hängt das Team die tatsächlichen Daten an die Feature-Datei. Die Daten gibt es, weil die Factory die Messung mitgebaut hat.

Im Beispiel: das Ergebnis

Nach acht Wochen haben 28 % der Teamleiter in der Kundengruppe den Entwurf in mindestens drei Wochen geöffnet, das Ziel waren mindestens 20 %. Bearbeitet und geteilt haben ihn aber nur 38 % dieser Teamleiter, erwartet war mindestens die Hälfte. In Gesprächen zeigt sich ein Grund: Teamleiter kopieren den Text lieber in ihre eigene Mail.

Das Ziel beim Öffnen ist erreicht. Ob der Entwurf den handgeschriebenen Status ersetzt, bleibt zunächst offen: Wer den Text in die eigene Mail kopiert, taucht in der Messung nicht als Teilen auf. Das Erfolgsmodell hat das Teilen zu eng gefasst. Der Product Manager verlängert einmal um vier Wochen, und die Factory zählt jetzt auch mit, wer den Text kopiert. Bleibt das zweite Ziel auch dann verfehlt, wird das Feature entfernt.

In den vier Wochen der Verlängerung sind es 44 % dieser Teamleiter statt 38 %, das Kopieren mitgezählt. Das zweite Ziel bleibt verfehlt. Die Gespräche zeigen, was die Teamleiter kopieren: einzelne Absätze. Den Rest schreiben sie neu, und der Status kostet sie so viel Zeit wie vorher. Die Wirkungsannahme trifft damit nicht zu: Der Entwurf ersetzt das Zusammensetzen von Hand nicht. Der Product Manager entscheidet: Die Wochenzusammenfassung wird entfernt. Die Factory baut sie zurück, und die Kundengruppe erfährt vorher, warum.

Vierter Bruch: Ein Feature muss sich seinen Platz verdienen

	Ziel	Nach acht Wochen	In der Verlängerung
In mindestens drei Wochen geöffnet	mindestens 20 %	28 %
Davon bearbeitet und geteilt	mindestens die Hälfte	38 %	44 %, Kopieren mitgezählt

Die Probefahrt hatte diese Option nach vorn gebracht, und erst die Frist hat gezeigt, dass sie ihr zweites Ziel verfehlt. In der Feature-Datei steht jetzt, was vorher niemand wusste: Teamleiter wollen Bausteine für ihren Status, keinen fertigen Entwurf. Das spricht für die Fragen an den Projektstatus, die in der Probefahrt positiv überrascht hatten. Sie gehen als nächste Option durch die vier Brüche, mit einer schärferen Wirkungsannahme.

Fertig ist die Arbeit an der Wochenzusammenfassung trotzdem: Der Markt hat geantwortet, und ein Mensch hat entschieden. Die Factory hätte von sich aus weitergebaut.

Was das für Umsatz und Zeit bedeutet

Und der Umsatz? Über den entscheidet die äußere Schleife, und die ist durch Agenten nach unserer Erfahrung nicht schneller geworden. Mehr Output hilft dort vor allem, wenn er besser auswählen lässt, was den Markt erreicht.

Und die Zeit, die beim Codeschreiben frei wird? Sie kommt nicht von allein an.

Aruna Ranganathan und Xingqi Maggie Ye (öffnet in einem neuen Tab) haben Anfang 2026 Zwischenergebnisse einer Studie vorgelegt. Acht Monate lang haben sie ein Technologieunternehmen mit rund 200 Beschäftigten begleitet. Mit KI waren die Leute dort schneller, übernahmen mehr verschiedene Aufgaben und arbeiteten länger, oft ohne dass jemand es verlangt hatte. Untersucht wurden mehrere Funktionen, nicht nur die Entwicklung.

Für uns heißt das: Gewonnene Zeit füllt sich von selbst mit mehr Arbeit. In Teams mit einer Factory ist das nach unserer Beobachtung meist noch mehr Bauen, also innere Schleife. Wer die Zeit nicht verplant, verliert sie genau dorthin.

Dabei gehört die Zeit in die äußere Schleife: in Wirkungsannahmen, Probefahrten und Gespräche mit Kunden. Sinnvoll war das schon immer. Nach unserer Erfahrung blieb dafür nur wenig übrig, solange das Bauen die Zeit des Teams auffraß.

Wo dieses Modell an Grenzen stößt

Dass die Probefahrt hilft, ist eine Annahme. Wir halten es für plausibel, dass Teams nach einer Probefahrt besser wählen als nach dem Prospekt. Gemessen haben wir das nicht. Dazu kommt, dass vor allem das Team selbst die Probefahrt macht, und wir vermuten, dass es die eigene Preview nachsichtiger bewertet. Einzelne Kunden davorzusetzen hilft.

Der Forecast ist nicht kalibriert. Ob Sprachmodelle die Wirkung eines Features brauchbar schätzen können, ist offen. Der Forecast sortiert vor und zwingt dazu, Annahmen aufzuschreiben. Mehr sollte ihm vorerst niemand zutrauen.

Vier Entscheidungen können zur neuen Warteschlange werden. Der stärkste Einwand gegen jede menschliche Entscheidung im Ablauf: Menschen skalieren nicht. Die vier Brüche gelten aber pro Idee, nicht pro Änderung, und die Factory bereitet jede Entscheidung mit Belegen vor. Wer trotzdem mehr Features zur Entscheidung bringt, als er entscheiden kann, hat den Bottleneck bloß verlagert.

Wartbarkeit schlägt nicht von selbst Alarm. Findings zu Struktur und Wartbarkeit landen auf der Liste, und weder ein Bug noch ein Alarm öffnet die Liste wieder. Wer nicht will, dass die Wartbarkeit verfällt, schreibt sie als Prüfung fest.

Entfernen hat seinen Preis. Nimmt man Kunden ein Feature weg, das sie schon nutzen, kann das Vertrauen kosten. Darum geht die Auslieferung zuerst an eine begrenzte Gruppe. Sauber entfernen lässt sich nur, was dafür gebaut wurde: mit eigenem Flag, eigenen Daten und ohne Schnittstelle, auf die sich andere verlassen. Deshalb gehört der Rückbau in die Akzeptanzkriterien.

Die Frist kann zu kurz sein. Kleine B2B-Kundengruppen liefern nach unserer Erfahrung in wenigen Wochen oft kein sauberes Signal. Die Länge der Frist legt das Team deshalb für jedes Feature eigens fest.

Nicht alles hat Optionen oder ein Verfallsdatum. Eine Migration oder eine regulatorische Änderung baut niemand viermal, und automatisch entfernt sie auch niemand. Die Wirkungsannahme und die Messung in den Akzeptanzkriterien gelten dort trotzdem.

Was ihr am Montag tun könnt

Für die ersten drei Schritte braucht ihr keine Factory.

1. Schreibt die Wirkungsannahme für die nächsten drei Features in eurer Warteschlange auf. Wo euch das nicht gelingt, habt ihr ein Feature gefunden, das nicht weitergehen sollte.
2. Macht die Messung zum Teil der Akzeptanzkriterien eures nächsten Features.
3. Gebt dem nächsten Feature ein Verfallsdatum und entscheidet am Stichtag, ob es bleibt.

Für die Schritte 4 und 5 braucht ihr Agenten.

4. Lasst euren Review-Agenten nur noch gegen Akzeptanzkriterien und Prüfungen arbeiten. Belegte Fehler werden zu neuen Kriterien, alles andere wandert auf die Liste.
5. Lasst für einen einzigen Bedarf zwei Optionen mit Budget bauen und entscheidet erst anhand der Previews.

Wann die Arbeit fertig ist

Sobald es ein Erfolgsmodell gibt, ist es kein Mangel mehr, dass eine Factory nicht von selbst aufhört. Dann haben beide Schleifen ihr break. Die innere endet an Akzeptanzkriterien und Budget, die äußere an der Frist aus dem Erfolgsmodell. Fertig ist die Arbeit, wenn der Markt geantwortet hat und ein Mensch entschieden hat, ob das Feature bleibt.