Loop Engineering und Graph Engineering: Was dahintersteckt

Ich war bei Loop Engineering und Graph Engineering zuerst skeptisch. Je mehr ich mich eingelesen habe, desto klarer wurde mir aber: Die Konzepte sind in der Softwareentwicklung nichts Neues, und wahrscheinlich nutzt du Teile davon schon, ohne es zu merken.

In diesem Artikel erkläre ich dir, woraus ein Loop besteht, welche vier Loop-Typen es gibt und wie ich sie in meinem Workflow mit Claude Code einsetze. Danach geht es um die Grenzen von Loops, um Graphen als nächste Ebene und um die Frage, ob das Ganze für dich überhaupt schon relevant ist.

Was ist Loop Engineering?

Wenn du mit Claude oder einem anderen Coding Agent arbeitest, läuft es vermutlich so: Du promptest eine Aufgabe, Claude bearbeitet sie und gibt dir das Ergebnis zurück. Du reviewst, promptest erneut, und der Prozess beginnt von vorne.

Das ist im Grunde schon ein Loop. Nur bist du darin der Taktgeber, und Claude ist dein Werkzeug.

Loop Engineering beginnt mit einem Perspektivwechsel: Betrachte deinen Coding Agent als eigenständigen Entwickler. Die Fähigkeit dazu hat er längst. Einem Kollegen würdest du auch nicht ständig auf die Finger schauen. Du gibst ihm eine Aufgabe mit einem klaren Zielzustand, und er arbeitet, bis sie erledigt ist. Dabei testet er selbst, prüft, ob das Ziel erreicht ist, bessert nach und meldet sich erst zurück, wenn alles fertig ist.

Der entscheidende Unterschied: Bisher hast du deinem Agent gesagt, was er bauen soll. Jetzt sagst du ihm zusätzlich, wann er fertig ist.

Die 3 Bestandteile eines Loops

Jeder Loop besteht aus drei Teilen:

1. Startkriterium: Wann läuft der Loop los? Stößt du ihn manuell an, folgt er einem Zeitplan oder startet er bei einem bestimmten Ereignis?
2. Aufgabe: Was genau soll erledigt werden?
3. Erfolgskriterium: Woran erkennt der Agent, dass er fertig ist?

Am wichtigsten ist der dritte Punkt. Das Erfolgskriterium muss sich mit Ja oder Nein beantworten lassen. Zum Beispiel:

• Eine Aufgabe hat einen bestimmten Status erreicht.
• Alle Tests sind grün.
• Alle Akzeptanzkriterien stehen im Testbericht auf „bestanden“.

Lässt das Kriterium Interpretationsspielraum, trifft der Agent eigene Annahmen darüber, wann er fertig ist. Im schlechtesten Fall dreht er unnötige Runden und verbrennt dabei Tokens.

Die 4 Loop-Typen

Anthropic hat in einem Artikel vier Arten von Loops beschrieben, unterschieden danach, wie das Erfolgskriterium aussieht. Zu jedem Typ zeige ich dir, wie ich ihn einsetze.

Zum Kontext: Ich entwickle Software mit einem eigenen Framework aus Skills und einem standardisierten Workflow. Der besteht aus den Schritten Spezifikation, Architektur, Aufgabenliste, Umsetzung, Qualitätssicherung und Deployment. Die Beispiele stammen aus diesem Workflow.

1. Turn-based Loop: Claude entscheidet selbst

Das ist die einfachste Form. Du gibst Claude eine Aufgabe. Er sammelt den nötigen Kontext, arbeitet die Aufgabe ab, prüft, was er prüfen kann, und entscheidet selbst, ob er fertig ist. Ein hartes Kriterium gibst du nicht vor.

So einen Loop kannst du komplett in einem Skill abbilden, also einer Arbeitsanleitung für Claude in Form einer Markdown-Datei. Dort schreibst du jeden Arbeitsschritt auf und ergänzt am Ende eine Regel wie: „Wenn ein Schritt fehlschlägt, behebe den Fehler und starte wieder bei Schritt 1.“

Ein Beispiel aus meinem Build-Skill, der für die Implementierung zuständig ist: Jeder Test, den Claude schreibt, muss mindestens einmal rot gewesen sein, bevor er grün werden darf. Coding Agents sind nämlich gut darin, sich Tests schönzuschreiben, und zwar so, dass sie gar nicht fehlschlagen können. Dann meldet Claude „Test ist grün“, aber der Test hätte nie etwas gefunden.

Der Ablauf sieht so aus:

1. Claude implementiert den Code und schreibt den Test dazu.
2. Er dreht die Erwartung im Test bewusst um oder nimmt die Prüfung im Code kurz heraus.
3. Der Test schlägt fehl. Damit ist bewiesen, dass er fehlschlagen kann.
4. Claude stellt alles wieder her.
5. Der Test muss grün sein. Erst dann geht es weiter.

Die Schwäche dieses Loop-Typs: Derselbe Agent entwickelt und verifiziert. Er beurteilt sein eigenes Ergebnis und kennt den Weg dahin, also schaut er womöglich nicht genau genug hin. Besser ist ein externer Prüfer, der nur das Ergebnis sieht. Dafür habe ich einen QA-Skill, der die Prüfung an einen unabhängigen Reviewer-Agent mit eigenem Kontext übergibt. Der bekommt nur die Spezifikation und das Ergebnis und kann gezielt prüfen.

2. Goal-based Loop: Du gibst ein messbares Ziel vor

Beim Goal-based Loop legst du selbst ein messbares Ziel fest. In Claude Code geht das mit dem Befehl /goal. Claude arbeitet dann über mehrere Runden weiter, bis das Ziel erreicht ist. Nach jeder Runde prüft ein kleines, schnelles Modell, ob die Bedingung erfüllt ist. Falls nicht, startet Claude die nächste Runde, statt dir die Kontrolle zurückzugeben.

Die Ziele schreibe ich mir nicht spontan aus. Bevor ich ein Feature entwickle, lege ich eine Spezifikation an, also ein Anforderungsdokument. Darin stehen Akzeptanzkriterien mit einer festen ID, jeweils im Format:

Angenommen X, wenn Y, dann Z.

Jedes Kriterium ist damit von Natur aus wahr oder falsch. Genau das brauche ich als Zielbedingung: Implementierung und Qualitätsprüfung sind erst abgeschlossen, wenn alle Akzeptanzkriterien erfüllt sind. Da ich zusätzlich mit einem Status pro Feature arbeite, sieht mein Prompt so aus:

/goal PROJ-1: Alle Akzeptanzkriterien sind implementiert und stehen im Testbericht auf bestanden. Der Status des Features steht auf approved. Maximal 5 Durchläufe.

Die Obergrenze für Durchläufe ist kein eigener Parameter von /goal, sondern Teil der Bedingung. Sie hilft dem Prüfmodell, den Loop zu beenden, bevor er ausufert.

Das Schöne daran: Die Erfolgskriterien stehen schon fest, bevor die erste Zeile Code entsteht. Claude läuft los, nutzt die Skills für die Implementierung und startet später einen unabhängigen QA-Agent. Der findet Bugs und meldet sie an den Haupt-Agent, der nachbessert. Dann prüft der QA-Agent erneut. Das läuft so lange im Kreis, bis der Testbericht keine Fehler mehr enthält.

Mehr zu /goal und /loop findest du in meinem Artikel über die Claude Code Befehle, die ich täglich nutze.

3. Time-based Loop: Start nach Zeitplan

Den Time-based Loop startest nicht du, sondern ein Intervall oder eine feste Uhrzeit. Ein typisches Beispiel: „Prüf alle 5 Minuten meine Pull Requests, beantworte neue Kommentare und behebe fehlgeschlagene CI-Läufe.“

In Claude Code gibt es dafür zwei Befehle:

• /loop läuft lokal in deiner aktuellen Session. Schließt du sie, endet auch der Loop.
• /schedule legt eine Routine an, die in der Anthropic-Cloud läuft, also auch, wenn dein Rechner aus ist. Sie arbeitet mit einer frischen Kopie deines Repositorys und läuft höchstens einmal pro Stunde.

In meinem Workflow gibt es einen Audit-Skill. Er prüft, ob Dokumentation und Code noch zusammenpassen: Liegt jeder Funktion im Code eine Spezifikation zugrunde? Hat jedes Akzeptanzkriterium eine Aufgabe und ein Testergebnis? Ich will keinen Code in meiner Anwendung, der nicht durch eine Spezifikation begründet ist. Das schleicht sich schnell ein, wenn du zwischendurch Änderungen hineinpromptest, die an den Anforderungen vorbeigehen.

Den Audit nutze ich in zwei Varianten.

Variante 1: Monitoring während der Arbeit.

/loop 1h /audit

Der Loop behebt nichts, er zeigt mir nur jede Stunde, ob Abweichungen entstanden sind. Das Intervall ist das Startkriterium, das Ergebnis ist ein Bericht. Den genauen Ablauf beschreibt der Skill. Die Abweichungen behebe ich anschließend selbst.

Variante 2: Prüfen und beheben in der Cloud. Hier gebe ich ein Erfolgskriterium mit und die Erlaubnis, bestimmte Dinge selbst zu beheben:

/schedule Führe /audit aus. Wenn ein Akzeptanzkriterium noch kein Testergebnis hat, lass die Qualitätssicherung laufen. Wenn dabei Bugs gefunden werden, behebe sie, aber auf einem eigenen Branch, nie auf main. Wiederhole das, bis der Audit-Skill keine Abweichung mehr meldet, maximal 3 Durchläufe. Die Spezifikation ist während des gesamten Vorgangs schreibgeschützt. Alles andere, vor allem Code ohne Spezifikation, fasst du nicht an, sondern schreibst es in den Bericht.

Den Bericht schaue ich mir morgens an und leite daraus die nächsten Schritte ab. Wichtig: Claude darf hier Bugs beheben, aber weder die fachlichen Anforderungen in der Spezifikation umschreiben noch Code ändern, den die Spezifikation nicht vorgibt.

4. Proaktiver Loop: Das System handelt selbst

Proaktive Loops werden durch einen zeitlichen Trigger oder ein Ereignis ausgelöst, und das kann sehr individuell sein. Beispiel: Ein Pull Request wird erstellt. Das löst den Loop aus, ein Agent prüft den Pull Request, ein zweiter verifiziert das Ergebnis. Du bist nicht mehr aktiv beteiligt und erfährst erst hinterher davon.

Auf diesem Typ baut auch die Dark Software Factory auf, eine kleine Softwarefabrik aus mehreren proaktiven Loops. Dazu weiter unten mehr.

Mehr Autonomie heißt mehr Vertrauen

Von Typ 1 bis Typ 4 geben wir dem Agent Schritt für Schritt mehr Autonomie und damit mehr Vertrauen. Das entlastet dich. Gleichzeitig müssen die Vorgaben präziser werden, denn Fehler fallen dir unter Umständen erst auf, wenn das Ergebnis des Loops bei dir landet.

Wenn du etwas auf diese Weise automatisieren willst, geh deshalb schrittweise vor. Lass den Loop erst in einer Testphase laufen und schau dir die Zwischenergebnisse regelmäßig an.

Reward Hacking: Wenn der Agent das Ziel austrickst

Bei Zielvorgaben in Loops gibt es eine Falle, die du kennen solltest: Reward Hacking. Damit ist gemeint, dass ein Agent sein Ziel auf dem kürzesten Weg erreicht, aber nicht so, wie du es gemeint hast.

Angenommen, das Ziel lautet: „Lauf so lange, bis alle Tests grün sind.“ Der einfachste Weg dorthin: Tests löschen oder so umbauen, dass sie nicht mehr fehlschlagen können. Das passiert nicht, weil der Agent dich ärgern will, und auch nicht, weil das Ziel unklar wäre. „Alle Tests grün“ ist eindeutig. Es passiert, weil der Agent teilweise den kürzesten Weg nimmt.

Ein sauber formuliertes Erfolgskriterium reicht also nicht. Du musst auch festlegen, wer prüft, ob das Ziel erfüllt ist. Und dieser Prüfer darf nicht derselbe Agent sein, der die Aufgabe umgesetzt hat.

In meinem Framework gelten deshalb diese Regeln:

• Die Spezifikation ist schreibgeschützt, solange gebaut und getestet wird. So kann der Agent die Anforderungen nicht an sein Ergebnis anpassen.
• Entwickelnder und testender Agent sind getrennt.
• Der QA-Agent findet Bugs, behebt sie aber nicht. Das übernimmt der Build-Agent.
• Subagents melden nie selbst, dass sie fertig sind. Der Haupt-Agent prüft das Ergebnis und bewertet, ob es ausreicht.

Die Grenze von Loops: Context Rot

Loops erlauben dir, Arbeitsaufträge an Agents abzugeben, die dann selbstständig laufen, bis ein Ziel erreicht ist. Was passiert aber bei einem größeren Auftrag?

Nimm an, du willst in einer bestehenden SaaS-Anwendung ein großes Feature umsetzen. Es ist in einer Spezifikation dokumentiert, mit Anforderungen, User Stories, Akzeptanzkriterien und allem, was nicht dazugehört. Du könntest das komplett in einen einzigen Loop geben: Architektur, Aufgabenplanung, Umsetzung, Testing und Deployment nacheinander.

Dann bekommst du ein Problem mit dem Kontextfenster, also dem Arbeitsgedächtnis des Agents. Er müsste den gesamten Auftrag in einem einzigen Kontext halten. Das führt schnell zu Context Rot: Je voller das Kontextfenster, desto stärker lässt die Leistung des Agents nach. Irgendwann wird er so unzuverlässig, dass die Ergebnisqualität nicht mehr stimmt. Wie du das im Alltag abfederst, zeigt die Ressource So verhinderst du Context Rot.

Die Lösung: Den Prozess in einzelne Loops aufteilen, jeder mit eigenem, frischem Kontext. Zwischen den Loops gibt es Übergabepunkte, an denen Artefakte weitergereicht werden:

• die Spezifikation
• das Architekturdesign
• der Aufgabenplan
• das Ergebnis der Umsetzung
• der Testbericht

Der nächste Loop bekommt nur das Artefakt, also das Ergebnis, und nicht die 200 Zwischenschritte, die der vorherige Loop gebraucht hat. Damit ist das Kontextproblem gelöst. Und wenn du dir diese Konstruktion auf einer Karte vorstellst, bist du beim Graph Engineering.

Was ist Graph Engineering?

Ein Graph ist eine Landkarte, die den Ablauf und die Zusammenhänge deiner Agents und Loops beschreibt. Sie besteht aus zwei Elementen:

• Knotenpunkte: ein Loop, ein Agent oder ein Subagent.
• Verbindungen (Kanten): die Artefakte, die zwischen den Knoten übergeben werden.

Jeder Knoten arbeitet mit seinem eigenen frischen Kontext und konzentriert sich nur auf seine abgesteckte Aufgabe. Die Kontextfenster bleiben voneinander getrennt.

Wenn du in Claude Code schon mit Subagents gearbeitet hast, hast du im Prinzip bereits einen Graph gebaut. Dabei muss in einem Graph nicht alles parallel laufen. Sequenzielle Abläufe funktionieren genauso.

Graph Engineering ist kein Knowledge Graph

Nicht verwechseln solltest du das mit Knowledge Graphs. Erweiterungen wie Graphify indexieren deine Codebase und bauen daraus einen Wissensgraphen, damit Abfragen effizienter werden und du Abhängigkeiten schneller findest. Ähnlich funktioniert der Second-Brain-Ansatz mit Obsidian. Mit Graph Engineering im Sinne dieses Artikels hat das nichts zu tun.

Neu ist das Konzept nicht

Graphen gibt es in der Softwareentwicklung schon seit einigen Jahren. LangChain hat mit LangGraph eine Bibliothek entwickelt, die genau das macht: Agents als Knoten und Übergaben als Kanten definieren, inklusive Schleifen.

Die Dark Software Factory als Graph

Ein gutes Beispiel für einen Graph ist die Dark Software Factory. Die Definition ist einfach: ein Repository, das seinen eigenen Code ausliefert. Du gibst eine Spezifikation hinein, und am Ende kommt geprüfter, ausgelieferter Code heraus. Der Mensch ist bewusst nicht beteiligt. Daher der Name: Die Fabrik läuft „im Dunkeln“, etwa nachts, wenn niemand am Arbeitsplatz ist.

So könnte die Landkarte aussehen:

1. Warteschlange: Aufträge warten auf ihre Bearbeitung. In meinem Workflow wäre das eine Spezifikation mit einem bestimmten Status, zum Beispiel „freigegeben“.
2. Takt: Ein Time-based Loop schaut alle paar Minuten nach, ob etwas in der Warteschlange liegt.
3. Eingangsprüfung: Ein Agent gleicht den Auftrag mit den Zielen ab und vor allem mit den Ausschlusskriterien, also dem, was nicht zum Projektumfang gehört. Er darf den Auftrag ablehnen oder aufteilen. Die Factory kann dich also auch korrigieren.
4. Planung: Architektur und Aufgabenplan entstehen. Ein unabhängiger Agent im selben Loop verifiziert beides, bis das finale Architekturdesign und die Aufgabenliste stehen.
5. Umsetzung: Ein Goal-based Loop bekommt nur die Aufgabenliste und entwickelt, bis alle Akzeptanzkriterien erfüllt sind.
6. Unabhängige Prüfung: Ein komplett getrennter Reviewer-Agent sieht nur das Ergebnis. Der Clou: Er prüft mit Testszenarien, die vor der Umsetzung geschrieben wurden und die der entwickelnde Agent nie gesehen hat. Kennt der Entwickler die Prüfung, optimiert er womöglich auf die Prüfung statt auf die Anforderung.
7. Auslieferung: Automatisch wird ein Pull Request erstellt oder das Ergebnis direkt deployt.

Dazu kommen zwei Dinge, ohne die so eine Factory nicht funktioniert:

• Eskalation: ein direkter Draht zu dir. Steckt die Factory fest, muss sie den Durchlauf stoppen und dir Bescheid geben können. Das verhindert endlose Loops, und du kannst dir den Zwischenstand anschauen.
• Ein gemeinsames Gedächtnis: Der Zustand jedes Features muss irgendwo verwaltet werden, zum Beispiel in einer Datenbank mit Statusfeldern. Das ist das Minimum, das alle Loops kennen müssen.

Loops und Graphen sind kein Gegensatz

Es geht nicht um die Frage, ob du Loops oder Graphen entwickeln solltest. Beides greift ineinander, es ist eine Verschachtelung: Jeder Knoten in einem Graph kann ein Loop, ein Agent oder ein Subagent sein. Der Loop sorgt dafür, dass eine Aufgabe zuverlässig fertig wird. Der Graph sorgt dafür, dass mehrere Aufgaben sauber zusammenspielen, ohne dass ein einzelner Kontext überläuft.

Abgrenzen solltest du das von der Frage, wie du Claude Code technisch rund um die Uhr laufen lässt. Loop und Graph Engineering beschreiben, wie du Arbeit strukturierst und wer wann was prüft. Wo und wie lange der Agent läuft, ist ein separates Thema.

Einordnung: Ist das für dich schon relevant?

Ehrlich gesagt: Wenn du gerade eine einzelne Anwendung entwickelst, kommen für dich vor allem zwei Dinge in Frage. Erstens ein unabhängiges Review deiner Ergebnisse durch einen separaten Agent. Zweitens ein Goal-based Loop, mit dem du ganze Features oder Teile davon gegen klare Akzeptanzkriterien umsetzen lässt.

Wenn du dagegen regelmäßig Projekte entwickelst, etwa als Inhaber:in einer Softwareagentur, kann es sich lohnen, schon in Graphen zu denken. Dann lagerst du einen Großteil der Entwicklung und des Testings an möglichst autonome Abläufe aus.

In beiden Fällen gilt: Arbeite mit Spezifikationen und Akzeptanzkriterien. Sie sind die beste Grundlage für Erfolgskriterien, an denen ein Loop sich messen kann. Und je größer dein Projekt wird, desto weniger kommst du ohne einen strukturierten Entwicklungsprozess aus, in dem genau festgelegt ist, wer baut, wer prüft und was als „fertig“ gilt.