LoopsWork verbindet drei Fragen:
Lernen wird zum nächsten Build. Die Loops können parallel aktiv sein.
KI-gestützte Softwareentwicklung umfasst unterschiedliche Arbeitsweisen. Entscheidend ist, wie Anforderungen, Prüfung und Rückmeldung zusammenkommen.
Eine Idee wird in Alltagssprache beschrieben, von KI umgesetzt und durch Ausprobieren weiterentwickelt. Das kann beim Erkunden und bei frühen Prototypen helfen. Sobald daraus verlässliche Software werden soll, braucht es nachvollziehbare Regeln, Tests und menschliche Prüfung.
So bezeichnet LoopsWork die Entwicklung im Zusammenspiel der drei Loops: Eine kleine, versionierte Spec führt die Umsetzung. Tests und Menschen prüfen das Ergebnis; nach dem Release werden Wirkung und Erkenntnisse zurückgeführt.
Eine Idee kann mit Vibe Coding beginnen und anschließend in eine kleine, überprüfbare Spec überführt werden. Specification Driven Development schafft die Vereinbarung; Loop-Coding führt sie über die Auslieferung hinaus bis zur Wirkung und zum Lernen weiter.
Eine kleine, überprüfbare Änderung wird beschrieben, umgesetzt und abgenommen.
Feedback Debt vorbeugen: Schon in der Spec festlegen, wer die Wirkung nach dem Release wann prüft. So wird es sichtbar →
Die zehn bestehenden Schritte mit Verantwortung, KI-Unterstützung, Nachweis und Übergabe:
Vorhaben können aus Vorstand, Geschäftsführung, Unternehmensstrategie, übergeordneten Initiativen oder aus dem Team kommen. PO und Team konkretisieren den Auftrag und priorisieren innerhalb ihres vereinbarten Mandats. Bei Bugfixes reichen oft Reproduktion, Sollverhalten und Prüffall als Arbeitskarte. Vor dem Start klären sie mit den zuständigen Verantwortlichen Ziele, feste Vorgaben, Entscheidungsrechte und den Investitionsrahmen: menschlicher Aufwand, KI-Kosten, erwarteter Nutzen und Prüfpunkte. Der Umfang bleibt im ausdrücklich freigegebenen Spielraum verhandelbar; Ziel- oder Budgetkonflikte gehen an die zuständige Entscheidungsinstanz.
Reale Beispiele mit Nutzern und Fachpartnern sammeln. Bei Bedarf einen kleinen Prototyp erproben.
Verhalten, Beispiele, Fehlerfälle und Akzeptanzkriterien festhalten. Die Messanforderungen aus V2 aufnehmen. Bei kritischen Komponenten auch Beobachtbarkeit, sinnvolle Alert-Auslöser und Verhalten bei Ausfall vereinbaren; der optionale Abschnitt Reliability & Observability hilft dabei. Zum Abschluss kurz prüfen: Slice – ist die Spec klein genug für einen abgegrenzten Kontext und eine eigenständige Prüfung? Falls nötig, in sinnvoll eigenständige Specs schneiden; PO und Team bestätigen die Aufteilung. Den bestätigten Stand eindeutig versionieren, damit Menschen und KI mit derselben Vereinbarung arbeiten.
Repository, Abhängigkeiten und Risiken prüfen. Passende versionierte KI-Skills auswählen und KI-Kontext gezielt zusammenstellen: aktuelle Spec, relevante Dateien, Beispiele und Fehler. Jede geschnittene Spec bekommt einen eigenen Auftrag mit nur dem relevanten Kontext; gemeinsame Schnittstellen und Abhängigkeiten bleiben sichtbar. Kleine Änderungen, Testbefehle, Budget und Agentengrenzen festlegen.
Bestätigte Kriterien in prüfbare Fälle übersetzen. Der Test muss am fehlenden Verhalten scheitern. Bei kritischen Komponenten auch das vereinbarte Fehler-, Fallback- und Recovery-Verhalten prüfen.
Die kleinste passende Implementierung entwickeln. Konkrete Testfehler als Rückmeldung nutzen. Vereinbarte Logs, Metriken, Monitoring-Konfiguration, Alerts und Fehlerverhalten gehören zur Umsetzung.
Struktur und Wartbarkeit verbessern; das vereinbarte Verhalten beibehalten. Tests erneut ausführen.
Eine kleine, zusammenhängende Änderung mit Spec-Bezug, Tests und Evidence unabhängig prüfen. Integration, Sicherheit, Architektur und bei Betriebsrelevanz Beobachtbarkeit, Alert-Reaktion und Wiederherstellung risikogerecht beurteilen.
Ein Pull Request (PR) legt eine vorgeschlagene Codeänderung zur Prüfung vor, bevor sie in den gemeinsamen Codebestand übernommen wird (Merge).
Eine benannte menschliche Person im Delivery Team prüft risikogerecht und entscheidet über die Merge-Freigabe. Grüne Tests sind wichtige Nachweise, ersetzen aber keine technische Beurteilung.
Änderungen bleiben fachlich zusammenhängend und gut prüfbar. Starre Zeilenlimits helfen dabei nicht; große, vermischte Änderungen werden sinnvoll geschnitten.
Die Prüftiefe folgt dem Risiko: Eine Textänderung braucht weniger Prüfung als eine Änderung an Berechtigungen, Zahlungen oder Datenmigrationen. Bedingte Punkte können mit „nicht relevant“ und kurzer Begründung markiert werden.
Das Agenten-Review ist ein eigenständiger Prüfauftrag mit Zugriff auf Spec, Änderungen und relevante Nachweise, in einem separaten KI-Kontext. Die Selbsteinschätzung des erzeugenden Agenten genügt nicht. Auch ein separater Agent garantiert keine Fehlerfreiheit. Agenten liefern Befunde und Korrekturvorschläge; Menschen entscheiden über die Freigabe.
Der Workmaster koordiniert den Ablauf und macht offene Reviews oder fehlende Nachweise sichtbar. Daraus entsteht keine automatische Freigabebefugnis. Merge-Freigabe in B8 und kontrollierte Auslieferung in B10 bleiben getrennte Entscheidungen.
Diese Prüfungen ergänzen sich. Keine ersetzt die andere.
Lange wartende oder zu große PRs verzögern Rückmeldung und erhöhen das Risiko von Nacharbeit. Offene Reviews sichtbar halten und zeitnah bearbeiten – so werden Feedback-Schulden früh begrenzt. Feedback-Schulden sichtbar machen →
Im Acceptance Slot reale Szenarien mit vorbereiteter Testversion, Daten und Rollen prüfen. Fachpartner bestätigt die Kriterien oder beschreibt konkrete Abweichungen. Neue Wünsche separat behandeln. Bei kritischen Komponenten gehört neben der fachlichen Funktion auch die vereinbarte Beobachtbarkeit und das geprüfte Fehlerverhalten zu den Abschlusskriterien.
Änderung aktivieren, Release und Nutzergruppe zuordnen. Betrieb und Datenerfassung prüfen. Vereinbarte Monitoring-Signale, Alerts und Recovery-Wege kontrollieren; Tiefe und Aufwand richten sich nach der Kritikalität.
Hier wird geprüft, ob die gewünschte Wirkung eintritt – über das technische Funktionieren hinaus.
Feedback Debt sichtbar machen: Ausgelieferte Änderungen mit noch ungeprüfter Wirkung samt Alter, Prüfdatum und Verantwortung verfolgen. So wird es sichtbar →
Hypothese und Messplan entstehen früh. Scorecard, Evidence, Monitoring, Telemetrie und Value Review helfen später, Ergebnisse einzuordnen und zu entscheiden.
Zielgruppe, Problem und erwartete Verbesserung formulieren. Nutzerfeedback einbeziehen.
Ausgangswert, Ziel, Vergleich, Datenmenge und Schutzkennzahlen vereinbaren. Technische Betriebsindikatoren nur aufnehmen, wenn sie Nutzer, Business-Wirkung oder Systemzuverlässigkeit erkennbar beeinflussen.
Ab Aktivierung Release, Nutzergruppe und Messpunkte prüfen. Fehlerhafte Erfassung korrigieren.
Die Datenpipeline berechnet Kennzahlen; Menschen prüfen Vollständigkeit, Vergleich und Nebenwirkungen.
Zahlen und Nutzererfahrung zusammen betrachten. Alternative Erklärungen benennen.
Beibehalten, verbessern, ausweiten, weiter untersuchen oder zurücknehmen. Der PO entscheidet im vereinbarten Mandat. Bei übergeordneten Ziel-, Budget- oder Prioritätsentscheidungen legt er Befunde und Empfehlung der zuständigen Instanz vor. Owner und nächste Aktion festhalten.
Erkenntnisse verändern Specs, Tests, Agenten-Kontext, Prompts, Regeln oder Arbeitsbedingungen.
Feedback Debt abbauen: Ausstehende Rückmeldungen klären und gewonnene Erkenntnisse in die nächste Spec, Tests oder Arbeitsregel übernehmen. So wird es sichtbar →
Beobachtungen werden zu einem begrenzten Experiment. Das Team prüft dessen Nutzen und verankert Bewährtes für die nächste Änderung.
Nacharbeit, Wartezeiten, Abnahmerückläufer, gelungene Arbeit und Teamfeedback aufnehmen. Incidents, Fehlalarme und Beinahe-Ausfälle als Feedback erfassen. Auch verwendete KI-Skill-Version, KI-Kontextumfang, fehlende Informationen und KI-Kosten mit passenden Belegen erfassen. KI-Skills und KI-Kontext erklärt.
Ein relevantes Problem wählen und mögliche Ursachen prüfen. Beobachtung von Interpretation trennen.
Eine kleine Änderung mit erwartetem Nutzen, Messung, Budget, Owner und Prüftermin festlegen. Zum Beispiel einen KI-Skill verbessern oder die KI-Kontextauswahl verändern; getrennt erproben, um Ursachen zuordnen zu können.
Änderung bei passenden nächsten Aufgaben anwenden. Aufwand und Wirkung beobachten.
Alte und neue Arbeitsweise an vergleichbaren Aufgaben prüfen. Bei KI-Skills und KI-Kontext: Ergebnisqualität, Nacharbeit, menschliche Prüfzeit und KI-Kosten vergleichen. Beobachtete Verbesserung und Unsicherheit festhalten.
Bewährte Erkenntnis in Specs, Tests, Monitoring, Alert-Schwellen, robustere Architektur, Arbeitsregeln, KI-Skills oder KI-Kontextvorlagen übersetzen. Erkenntnisse aus Störungen fließen in die nächste Spec in B3 zurück. Das Team genehmigt Version, Owner und Rücknahmeweg. Im Learning Exchange mit Belegen und Grenzen teilen; in B4 gezielt wiederverwenden.
Die gemeinsamen Regeln hinter dem Kreislauf. Öffne ein Prinzip für die vollständige Erklärung.
Wir beginnen mit einer Verbesserung für Menschen. Eine Idee wird nicht wertvoll, weil sie technisch machbar ist oder viel Code erzeugt. PO, Team und Fachpartner klären, welches Problem sich für wen verändern soll. Daraus entsteht eine überprüfbare Wirkungshypothese.
Erst die gewünschte Wirkung klären. Dann die nächste passende Änderung wählen.
Vor der Umsetzung festhalten: Was beobachten wir heute? Was soll besser werden? Welcher Nachweis hilft uns bei der nächsten Entscheidung? Der Messplan aus dem Value Loop fließt schon in Spec und Tests ein.
„Kunden sollen ihre Mengen leichter korrigieren können“ ist der Bedarf. „Mehr Nutzer erreichen mit gefülltem Warenkorb den Checkout, ohne zusätzliche Preisfehler“ ist die Wirkungshypothese. Ob das eintritt, prüfen wir mit passenden Daten und Nutzerfeedback.
Ein korrekt geliefertes Feature kann wenig Nutzen bringen. Der Value Loop hilft zu entscheiden: beibehalten, verbessern, weiter untersuchen oder zurücknehmen.
Die Spec ist die gemeinsame Vereinbarung über das gewünschte Verhalten. Sie beschreibt Regeln, Beispiele, Fehlerfälle und Akzeptanzkriterien. Menschen und Agenten arbeiten mit derselben bestätigten Version; Tests und Code beziehen sich auf diesen Stand.
Gewünschtes Verhalten vereinbaren, bevor der Agent es umsetzt.
Alltagssprache und konkrete Beispiele genügen für den Einstieg. Kritische offene Fragen bekommen einen Owner und werden vor der betroffenen Umsetzung geklärt. Das Team ergänzt Schnittstellen und technische Grenzen; der Messpartner ergänzt nötige Messpunkte.
„Mengen sollen änderbar sein“ lässt vieles offen. Klarer ist: „Gegeben eine Position mit Menge 1, wenn die Menge auf 0 gesetzt wird, dann wird die Position entfernt. Der verbleibende Warenkorb wird neu berechnet.“
Für einen kleinen Bug können Reproduktion, Sollverhalten und Regressionstest reichen. Klarheit braucht passende Informationen, keinen möglichst langen Text.
Wir prüfen früh, statt große Änderungen lange ungeprüft wachsen zu lassen. Ein kleiner Schritt macht sichtbar, ob wir den Bedarf richtig verstanden haben und die Umsetzung funktioniert. Konkrete Rückmeldung beeinflusst die nächste Arbeit.
Die nächste prüfbare Änderung liefern. Mit dem Ergebnis den nächsten Schritt wählen.
Schon beim Planen einen nächsten Nachweis festlegen: Prüffall, Review, fachliche Rückmeldung oder Beobachtung nach dem Release. Technisches Feedback kommt oft nach Minuten; eine belastbare Wirkungsmessung kann länger dauern. Die Loops laufen deshalb parallel.
Zuerst die Mengenänderung umsetzen und mit normalen Mengen, 0 und Bestandsgrenzen prüfen. Danach mit einem Fachpartner erproben, ob die Bedienung verständlich ist. Ein Befund kann direkt zu einer kleinen Korrektur führen.
Kleine Specs erzeugen kleine Änderungen. Kleine Änderungen lassen sich schneller prüfen. So werden auch Feedback- und Lern-Loops kürzer.
Ein Agent bekommt einen konkreten, begrenzten Auftrag. Dazu gehören die gültige Spec, relevanter Kontext, erwartete Nachweise und erlaubte Werkzeuge. Rückmeldung aus Tests und Reviews hilft, die Änderung gezielt zu korrigieren.
Auftrag, Prüfmaßstab und Grenzen festlegen. Bei fehlenden Grundlagen zuerst klären.
Vor dem Lauf festhalten: Was darf der Agent lesen oder ändern? Welche Tests muss er ausführen? Wann soll er stoppen und an Menschen übergeben? Budget, Versuchslimit und ein menschlicher Owner bleiben sichtbar. Mehr Denkfähigkeit erweitert keine Entscheidungsrechte.
Der Workmaster setzt nur die bestätigte Mengenregel um. Er darf die betroffenen Dateien ändern und Tests ausführen. Bei widersprüchlichen Kriterien fragt er nach; er schwächt weder Anforderungen noch geschützte Tests eigenmächtig ab.
Umsetzung und unabhängige Prüfung erhalten separate KI-Kontexte. Ein plausibler Text ersetzt keinen belegten Testnachweis.
Menschen entscheiden. Agenten helfen. Agenten können Optionen vorbereiten, Arbeit umsetzen und Befunde liefern. Verantwortung für Prioritäten, fachliche Regeln, technische Freigaben und Produktentscheidungen bleibt bei den benannten Menschen.
Für jede Entscheidung klären: Wer entscheidet, in welchem Mandat und mit welchen Nachweisen?
Der PO priorisiert innerhalb seines vereinbarten Mandats. Das Team verantwortet den technischen Weg und die Qualität. Fachpartner bestätigen das fachliche Verhalten; der Messpartner prüft die Aussagekraft der Daten. Der Loop Lotse unterstützt Zusammenarbeit und Lernen.
Ein Agent schlägt vor, Rabattcodes später zu liefern. PO und Team entscheiden über den Schnitt. Ein Prüfer liefert Befunde zur Preisberechnung; die benannte menschliche Verantwortung entscheidet über die Freigabe.
Rollen können kombiniert werden. Entscheidungsrechte, Vertretung und Übergaben müssen trotzdem erkennbar bleiben. Konflikte außerhalb des Mandats gehen an die zuständige Instanz.
Eine Erkenntnis wird nützlich, wenn sie die nächste Arbeit verbessert. Das Team sammelt belegte Erfahrungen aus Build und Value, sucht ein relevantes Muster und erprobt eine begrenzte Veränderung. Bewährtes wird in Specs, Tests, KI-Skills oder Arbeitsregeln verankert.
Ein Muster verstehen. Eine Veränderung erproben. Ihre Wirkung prüfen.
Beobachtung und Vermutung unterscheiden. Für ein Experiment Nutzen, Owner, Budget und Prüftermin festlegen. Höchstens ein bewusstes Prozessexperiment je Team gleichzeitig hält die Wirkung nachvollziehbar. Was nicht hilft, wird angepasst oder verworfen.
Versandgrenzen verursachen wiederholt Nacharbeit. Das Team ergänzt Grenzfälle in der Spec-Vorlage und prüft bei folgenden Aufgaben, ob Fehler und Prüfaufwand sinken. Hilft es, wird die Regel übernommen und mit anderen Teams geteilt.
Auch Kontextauswahl und Spec-Schnitt können Lerngegenstand sein. Bewertet werden Ergebnisqualität, Nacharbeit und Prüfzeit; KI-Kosten ergänzen die Betrachtung. Personen werden nicht bewertet.
Kleine Specs reduzieren den Kontext. Große Aufgaben benötigen häufig viel Hintergrundwissen, Dateien und Abhängigkeiten. LoopsWork schneidet Arbeit deshalb in kleine, eigenständig umsetzbare und überprüfbare Specs. Der Agent erhält die Informationen, die er für genau diesen Arbeitsschritt braucht.
Nicht dem Agenten mehr Kontext geben. Die Aufgabe so schneiden, dass er weniger Kontext braucht.
Weniger unnötiger Kontext begünstigt präzisere Agentenarbeit. Kleine Änderungen lassen sich schneller prüfen: Feedback- und Lern-Loops werden kürzer. Ein geringerer Token- und Modellverbrauch kann zusätzlich die Kosten senken; Aufteilung und Koordination verursachen ebenfalls Aufwand.
Small Spec → Small Context → Small Change → Fast Feedback
Eine Spec sollte so klein wie möglich, aber noch sinnvoll eigenständig umsetzbar und überprüfbar sein. Zu kleine Aufgaben erzeugen Verwaltungs- und Koordinationsaufwand. Nötige Fachregeln, Schnittstellen, Abhängigkeiten und Prüffälle bleiben Teil des Kontexts.
Prüfen, ob die Spec mit überschaubarem Kontext umgesetzt und anschließend eigenständig überprüft werden kann.
Wenn eine dieser Fragen mit „Nein“ beantwortet wird, sollte die Spec weiter zerlegt werden. PO und Team bestätigen den Schnitt, bevor die Umsetzung geplant wird.
„Baue einen neuen Checkout inklusive Gutscheinen, Zahlungsarten und Fehlerbehandlung.“
Jede Spec erhält eigene Akzeptanzkriterien. Gemeinsame Schnittstellen und Abhängigkeiten werden verlinkt; zusammengehörige Änderungen werden zusätzlich in der Integration geprüft.
Sub-Tasks dienen hier nicht nur der Projektorganisation. Sie reduzieren vor allem den Kontext, den ein Agent für den jeweiligen Arbeitsschritt verstehen muss.
Bestehende Werkzeuge wie Sub-Tasks können große Anforderungen in kleinere Specs zerlegen. Entscheidend ist nicht die Jira-Struktur, sondern ein möglichst kleiner, relevanter Kontext je Arbeitsschritt.
Bei KI-gestützter Softwareentwicklung – auch als Softwareentwicklung mit KI oder AI Coding bezeichnet – verbindet das Prinzip klare Anforderungen mit KI-Unterstützung. Es ergänzt Specification Driven Development: Die vereinbarte Spec steuert Umsetzung und Prüfung; ihr sinnvoller Schnitt hält beide überschaubar.
Vibe Coding erkundet Ideen durch Prompten und Ausprobieren. Loop-Coding verbindet in LoopsWork kleine vereinbarte Specs, Prüfung, Wirkung und Lernen. Vibe Coding und Loop-Coding einordnen.
Slice im Build Loop ansehen · So helfen KI-Agenten beim Schneiden
Diese Themen unterstützen die drei Loops im Alltag.