Breaking the Loop

Von Benedikt Stemmildt (hackers&wizards) und Markus Andrezak (überproduct)

Agenten in einer Software Factory finden immer noch ein Problem, noch ein Ticket, noch eine Verbesserung. Wann die Arbeit fertig ist, kann nur eine zweite, viel langsamere Schleife sagen: die bis zum Markt.

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 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, 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.

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 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 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” ausführlich beschrieben.

	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?

Zwei Schleifen, vier Brüche: die Factory läuft im Schritt Bauen

Das Beispiel

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

Die innere Schleife läuft nur so weit, wie die äußere es erlaubt: das Beispiel im Überblick

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.

Bruch 01: Wirkungsannahme

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.

Bruch 02: Forecast und Budget

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. 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.

Option Storming: gebaut ausprobieren, nur die besten in 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 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 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.

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ß.

Bruch 03: Probefahrt

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. 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.

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 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.

Bruch 04: Verfallsdatum

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: 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.

Der Weg des Beispiels: von sieben Ideen zu einem entfernten Feature

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 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.

1. Lasst euren Review-Agenten nur noch gegen Akzeptanzkriterien und Prüfungen arbeiten. Belegte Fehler werden zu neuen Kriterien, alles andere wandert auf die Liste.
2. 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.

Das Gespräch dazu

Wie wir da hingekommen sind: Stories Connecting Dots, Ep. 42 mit Benedikt Stemmildt von hackers&wizards. Die Folge ist lang. Mit Absicht. Ihr hört uns beim Denken zu.

Quellen und Vertiefung

• hackers&wizards: Was ist eine Software Factory?
• hackers&wizards: Verifikation entscheidet über den Durchsatz
• hackers&wizards: Coding-Speed ist nicht Delivery-Speed
• Markus Andrezak: AI Flow Dynamics - The Loops Don’t Get Faster On Their Own, 18.06.2026
• Markus Andrezak: Option Storming - The 3D Chess Behind Claude Code, 13.03.2026
• Yoko Li, a16z: Knowing When to Stop: The Art of Making a Loop Converge, 06.08.2026
• Faros AI: The AI Productivity Paradox Research Report, 23.07.2025
• Anthropic: Redesigning source control at Anthropic, 13.10.2026
• Aruna Ranganathan, Xingqi Maggie Ye, Harvard Business Review: AI Doesn’t Reduce Work - It Intensifies It, 09.02.2026
• Haolin Jin, Huaming Chen: Are LLMs Reliable Code Reviewers? Systematic Overcorrection in Requirement Conformance Judgement, 28.02.2026
• Liina Suoniemi: prompt-vs-metric-eval, 2026
• Habit Hooks: habit-hooks
• Jina Yoon, PostHog: Stop being the code review bottleneck, 09.07.2026
• Ryan Singer, Basecamp: Shape Up, Kapitel 8: The Betting Table
• Eric Colson, Daragh Sibley, Dave Spiegel, Stitch Fix: The Sobering Truth About the Impact of Your Business Ideas, 04.11.2021, dort die Angaben zu Microsoft und Booking.com