Graph Engineering Claude Code 2026: mehr als der nächste Loop

Constantin, Platform Engineering bei Pexon Consulting | 8 Min. Lesezeit | 12.09.2026

TL;DR: Graph Engineering Claude Code in fünf Sätzen

Graph Engineering ersetzt einen einzelnen Agent-Loop durch mehrere Knoten, die parallel arbeiten und über feste Kanten verbunden sind: ein Planer, mehrere Prüfer, ein Gate. Das Konzept dahinter, die Dark Software Factory, stammt nicht aus einem Kurs, sondern aus der Softwareentwicklung selbst. Wir setzen es nur ein, wo Verifikation billig und der Schaden bei einem Fehler klein ist.

Direkt danach eine kurze Einordnung als Tabelle, weiter unten der Praxisteil.

Gerade kursieren wieder etliche Videos, die erklären, warum Sie aufhören sollen, Ihren Agenten zu prompten, und stattdessen auf Loops und Graphen setzen sollen. Ein Teil davon ist berechtigt. Ein Teil ist Verpackung für einen Kurs, der 699 Euro kostet und im Kern dieselben drei Konzepte drei Stunden lang dehnt.

Wir haben keinen Kurs zu verkaufen. Was wir haben, sind 14 KI-Agenten im eigenen produktiven Betrieb und die Frage, ob Graph Engineering für Sie schon relevant ist oder erst in einem Jahr. Die kurze Antwort: für die meisten noch nicht, aber der Begriff lohnt sich trotzdem, weil er eine Grenze markiert, die Sie in einem Loop nicht sehen. Wo genau die Ebene „Loop“ aufhört, haben wir in unserem Artikel zu Loop Engineering mit Claude Code im Detail beschrieben, hier geht es um die Stufe darüber.

Graph Engineering Claude Code: was ein Graph tatsächlich ist

Graph Engineering Claude Code beschreibt keinen neuen Modus im Werkzeug, sondern eine Architektur darüber. Ein Loop ist ein Kreis: beobachten, entscheiden, handeln, prüfen, von vorn. Ein Graph ist eine Landkarte mit festen Knoten und Kanten, durch die eine Aufgabe läuft. Statt eines Agenten, der alles nacheinander erledigt, verzweigt die Arbeit auf mehrere Agenten, die gleichzeitig laufen und deren Ergebnisse an einem Gate wieder zusammenlaufen.

Ein typisches Muster: ein Planer-Knoten zerlegt die Aufgabe, ein Worker-Knoten baut die Lösung, drei Prüfer-Knoten (Sicherheit, Logik, Stil) laufen parallel dagegen, ein Synthese-Knoten fasst zusammen, ein Gate entscheidet Weiter oder Zurück. In eigenen Tests mit parallelisierten Review-Läufen war ein solcher Graph rund dreimal schneller fertig als derselbe Review sequenziell im Loop, allerdings bei spürbar höheren Tokenkosten pro Durchlauf. Das lohnt sich erst ab einer gewissen Trefferquote der Prüfer, nicht bei jedem Task.

Unsere Empfehlung: Frieren Sie einen Loop erst dann zu einem Graphen ein, wenn Sie den Pfad schon kennen. Ein Graph für eine Aufgabe zu bauen, deren Ablauf sich noch wöchentlich ändert, ist verschwendete Ingenieursarbeit. Claude Code bietet dafür mindestens seit Version v2.1.248 (Stand August 2026) kein natives Graph-Objekt, Teams bauen das heute über parallele Sub-Agent-Aufrufe plus eine Skill, die als Gate fungiert, technisch näher an einem gerichteten Ablaufplan als an einem klassischen Knowledge-Graphen. Dass das kein Nischenwerkzeug ist, zeigt allein das öffentliche Repository dahinter: über 144.000 Sterne auf GitHub, Stand 06.09.2026.

Die Dark Software Factory: wo Autonomie aufhört, Vertrauen wert zu sein

Der Begriff, um den sich gerade die meiste Aufregung dreht, ist die „Dark Software Factory“. Er kommt ursprünglich aus einem Vergleich mit der Fertigungsindustrie: eine „Dark Factory“ ist eine Fabrikhalle, in der Roboter ohne Licht und ohne Menschen arbeiten, weil keiner mehr hinschauen muss. Übertragen auf Code heißt das: Code wird generiert, getestet und gemergt, ohne dass ein Mensch ihn je gelesen hat, nur Maschinen prüfen Maschinen.

Das klingt nach dem Ziel jeder Automatisierung. Ist es aber nur unter engen Bedingungen. Ein dokumentiertes Experiment ließ eine solche Fabrik vier Monate ohne jede menschliche Code-Review laufen, das Ergebnis war ein Berg an vergrabenen Architekturproblemen, den am Ende niemand mehr auf Anhieb verstand. Der Fachbegriff dafür ist Comprehension Debt, die Lücke zwischen der Menge an Code, die existiert, und der Menge, die noch irgendjemand versteht.

Drei Bedingungen entscheiden, ob eine Dark Factory bei Ihnen ein Risiko oder ein Gewinn ist:

1. Verifikation ist billig und zuverlässig. Tests, Typsystem, statische Analyse, ein Ergebnis, das eine Maschine ohne Interpretationsspielraum als richtig oder falsch einstufen kann.
2. Der Schaden bei einem Fehler ist begrenzt. Ein nächtlicher Job, der genau ein Lint-Problem behebt und einen kleinen Pull Request öffnet, darf dunkel laufen. Authentifizierung, Zahlungslogik oder öffentliche API-Verträge nicht, dort ist ein falsches Ergebnis teuer und nur ein Mensch erkennt es zuverlässig.
3. Die Aufgabe ist eng geschnitten. Je enger der Radius, desto verlässlicher lässt sich Autonomie rechtfertigen. Ein Graph mit sechs Knoten für eine breite Aufgabe verteilt das Risiko nur, er beseitigt es nicht.

Die Faustregel, die wir Kunden mitgeben: Ein Loop oder Graph darf so viel Autonomie bekommen, wie Sie günstig und zuverlässig prüfen können, keinen Zentimeter mehr. Das deckt sich mit einem Befund aus Anthropics eigener Forschung zu Reward Hacking: Modelle, die bei schwierigen Aufgaben unter Druck geraten, verändern eher die Testassertion als den fehlerhaften Code selbst. Prüfbedingungen wie „die Tests laufen grün“ sind dagegen anfällig, prüfbare Bedingungen wie „genau diese eine Assertion mit diesem Wert“ sind es viel weniger.

Genau hier setzt auch eine Frage an, die uns häufig gestellt wird: warum Regeln in einer Claude-Skill stehen und nicht in einer durchgängigen, hierarchischen Policy-Architektur. Beides existiert parallel, nicht als Ersatz füreinander. CLAUDE.md auf Unternehmens-, Projekt- und Nutzerebene ist die hierarchische Policy-Schicht, sie lädt immer und gilt für alles. Eine Skill ist etwas anderes: eine Prozedur, die nur dann in den Kontext kommt, wenn sie zur Aufgabe passt. Würden Sie jede bedingte Prozedur dauerhaft in die Policy-Ebene packen, würde der Kontext mit jeder neuen Regel wachsen, und mit ihm das Risiko von Context Rot, also nachlassender Antwortqualität, weil zu viel Irrelevantes mitgeschleppt wird. Eine Skill mit klar prüfbaren Schritten lässt sich dagegen einzeln testen, eine globale Policy nicht. Das folgende Beispiel zeigt den Unterschied konkret, ein Gate als Skill statt als Absatz in einer allgemeinen Richtlinie:

---
name: gate-billing-changes
description: Jede Änderung an Abrechnungslogik vor dem Merge gegen feste Kriterien prüfen.
---

1. Betroffene Testsuite vollständig ausführen, keine übersprungenen Tests akzeptieren
2. Diff auf veränderte oder gelöschte Assertions prüfen, nicht nur auf neue
3. Grenzwerte (Rundung, Währung, Steuer) gegen die Referenztabelle abgleichen
4. Bei Abweichung: ablehnen und an einen Menschen eskalieren, nicht selbst reparieren

Praxis: Graph Engineering Claude Code zum Nachbauen

Kein Framework nötig, um Graph Engineering Claude Code im Kleinen zu testen. Ein enger, ungefährlicher Anwendungsfall reicht: ein Pull Request wird von drei unabhängigen Sub-Agents gegen unterschiedliche Kriterien geprüft, bevor ein viertes Gate entscheidet.

# Drei Prüfer parallel gegen denselben Diff starten, ein Gate wertet aus
claude -p "Prüfe diesen Diff auf Sicherheitslücken. Antworte nur mit PASS oder FAIL plus Begründung." < diff.patch > review_security.txt &
claude -p "Prüfe diesen Diff auf Logikfehler. Antworte nur mit PASS oder FAIL plus Begründung." < diff.patch > review_logic.txt &
claude -p "Prüfe diesen Diff gegen den Styleguide. Antworte nur mit PASS oder FAIL plus Begründung." < diff.patch > review_style.txt &
wait
grep -L "^PASS" review_*.txt && echo "GATE: Zurück an den Autor" || echo "GATE: Merge freigegeben"

Kein einziger dieser drei Prüfer-Agenten teilt sich den Kontext mit dem Autor-Agenten, das ist keine Nebensächlichkeit, sondern der Punkt. Ein Prüfer, der im selben Gespräch entstanden ist wie der Code, den er bewertet, sieht seine eigene Begründung statt des Ergebnisses. Für den Gate-Knoten lohnt sich seit dem Release von Claude Opus 5 am 24.07.2026 das stärkere Modell, für die drei parallelen Prüfer reicht oft claude-haiku-4-5-20251001, schnell und günstig genug, um drei Meinungen statt einer einzuholen. Für den produktiven Betrieb kommt darüber noch ein Budget-Deckel pro Durchlauf und eine Zustandsdatei, die festhält, welcher Pull Request welchen Knoten schon durchlaufen hat, sonst fängt jeder Neustart bei null an.

Häufig gestellte Fragen

Was ist eine Dark Software Factory?

Eine Softwarepipeline, in der Code generiert, getestet und gemergt wird, ohne dass ein Mensch ihn liest. Der Name kommt aus der Fertigung, wo vollautomatisierte Werkshallen ohne Licht und Personal laufen. In der Softwareentwicklung ist das nur für eng geschnittene, günstig prüfbare Aufgaben sinnvoll, nicht für Authentifizierung, Zahlungslogik oder öffentliche Schnittstellen.

Warum stehen Regeln in einer Claude-Skill und nicht in einer hierarchischen Policy?

Beides existiert nebeneinander. CLAUDE.md ist die hierarchische Ebene und lädt immer, eine Skill ist eine Prozedur, die nur bei passender Aufgabe in den Kontext kommt. Alles dauerhaft in die Policy-Ebene zu packen, lässt den Kontext wachsen und begünstigt Context Rot. Eine Skill mit klaren Prüfschritten lässt sich zudem einzeln testen, eine globale Richtlinie kaum.

Ist Graph Engineering Claude Code nur der nächste KI-Hype?

Der Begriff ist neu, das dahinterliegende Prinzip nicht. Parallele Pfade mit einem Gate am Ende sind ein Muster, das die Softwareentwicklung seit Jahrzehnten aus CI/CD-Pipelines kennt, jetzt eben mit Agenten statt Skripten als Knoten. Skepsis ist trotzdem berechtigt, wenn ein Video das Konzept an einen Kurs koppelt, den Sie kaufen müssen, um es zu verstehen. Die zugrunde liegenden Quellen sind frei zugänglich.

Was kostet der Umstieg von einem Loop auf einen Graphen?

Kein Lizenzkosten, aber mehr Tokens pro Durchlauf, weil mehrere Agenten parallel statt ein einziger sequenziell arbeiten. In eigenen Vergleichsläufen lohnt sich der Umstieg erst ab einer gewissen Trefferquote der Prüfer, darunter zahlen Sie für Parallelität, die kein Ergebnis beschleunigt. Rechnen Sie in Kosten pro angenommener Änderung, nicht in Tokenverbrauch.

Wie kann ich zu diesem Thema mit Pexon zusammenarbeiten?

Am direktesten über unser Kontaktformular. Wir bauen Agenten-Setups für Unternehmen, die über den einzelnen Loop hinauswollen, von der ersten Skill bis zur mehrstufigen Orchestrierung mit Gates, keine Kurse, sondern Projektarbeit am eigenen Code.

Nächster Schritt

Bevor Sie einen Graphen bauen, lohnt sich der ehrliche Check, ob Sie überhaupt schon einen Loop haben, der zuverlässig läuft. Wenn Ihr Team das gemeinsam durcharbeiten will, von der ersten Skill bis zum Gate: In unserer Claude Code Schulung gehen wir genau diesen Weg praktisch durch.

Verwandte Themen