Deine AI-Agents sind produktiv. Sie schreiben Code, aktualisieren Spezifikationen, führen Tests aus. Die Tokens fließen, die Commits landen, und alles sieht gut aus — bis jemand eine einfache Frage stellt: “Haben wir alles aktualisiert, was aktualisiert werden musste?”
Niemand kann es beantworten. Das ist das Problem.
Ein Benchmark, den man gelesen haben sollte
Erwin Roth von Audi hat einen Benchmark durchgeführt. Fünf Koordinations-Architekturen für Claude Code. Dieselbe Codebasis, dasselbe Szenario, vier parallele Agents. Die Aufgabe: eine einzelne Anforderungsänderung — Bremsansprechzeit von 100ms auf 50ms — über 15 verknüpfte Artefakte in einem ISO-26262-sicherheitskritischen Projekt propagieren. Anforderungen, Spezifikationen, Implementierungen, Tests, Architekturdiagramme. Alles verlinkt, alles aktualisierungsbedürftig.
Der einfachste Ansatz — Claude Code mit geteilter Aufgabenliste, ohne strukturelles Bewusstsein — verbrauchte 67.300 Tokens. Der strukturierteste Ansatz — Claude Code mit Pharaoh, gestützt auf sphinx-needs als Traceability-Graph — brauchte 11.200 Tokens.
Das ist ein Faktor 6. Und der teure Ansatz wurde nicht mal fertig: er verfehlte 4 von 15 Artefakten und erzeugte mehrdeutigen Zustand, der manuelle Intervention erforderte.
Drei Fehlermodi
Roths Benchmark identifizierte drei Fehlermodi. Sie kündigen sich nicht an. Sie belasten einfach das Budget und hinterlassen Lücken.
Token-Inflation. Jeder Agent-Turn lädt den vollständigen Projektkontext neu. Mit einer geteilten Aufgabenliste wächst dieser Kontext mit jedem abgeschlossenen Schritt. Die Kosten skalieren als O(Turns × Agents). Im Benchmark blieben die Input-Tokens pro Turn für Pharaoh nahezu konstant — circa 1.000 von Anfang bis Ende — während der unstrukturierte Ansatz von 2.000 auf über 5.500 pro Turn anstieg. Multipliziert mit vier Agents und dutzenden Turns zahlt man immer wieder für dieselbe Information.
Merge-Ambiguität. Mehrere Agents schreiben ins selbe Task-Log. “Agent REQ hat SW-SPEC-001 aktualisiert.” “Agent SPEC hat SW-SPEC-001 aktualisiert.” Jetzt braucht der Master-Agent zusätzliche Disambiguierungsläufe, um herauszufinden, wer was getan hat. Das passierte tatsächlich im Benchmark: zwei Agents beanspruchten dasselbe Artefakt, und der Koordinationszustand wurde während des Laufs mehrdeutig. Kein theoretisches Risiko. Eine dokumentierte Beobachtung.
Semantische Blindheit. Eine geteilte Aufgabenliste sagt Agents, was als nächstes zu tun ist. Sie sagt ihnen nicht, was es bedeutet, dass eine Aufgabe abgeschlossen ist. Ohne den Traceability-Graph — welche Anforderungen von welchen abgeleitet sind, welche Specs zu welcher Fahrzeugvariante gehören, welche Architekturdiagramme über Code-Links verbunden sind — können Agents keine Artefakte entdecken, von denen ihnen niemand erzählt hat. Sechs der 15 Artefakte erforderten Variantenbewusstsein oder Codelink-Traversierung, um gefunden zu werden. Ansätze ohne Graph-Traversierung verfehlten einige oder alle davon.
Die Lücke ist strukturell
Was die Zahlen unbequem macht: Die Lücke hat nichts mit Prompt-Qualität zu tun. Es geht um Architektur.
CC + Superpowers, mit sorgfältig erstellten Plan-Dokumenten, erreichte 14 von 15 — beeindruckend, aber es fehlte eine Motorrad-Varianten-Spec. Der Plan-Autor wusste nicht, dass sie einbezogen werden musste. CC + spec2cloud kam auf 13. CC + Gastown/Beads auf 12.
Pharaoh erreichte 15 von 15. Jedes Artefakt. Jede Variante. Jeder Architektur-Link.
Der Mechanismus ist einfach. Pharaoh verlässt sich nicht darauf, dass jemand aufzählt, was sich ändern muss. Es traversiert den Traceability-Graph in sphinx-needs und liefert die vollständige Impact-Menge deterministisch — bevor ein einziges LLM-Token ausgegeben wird. Ein geändertes Feld in SYS-REQ-001 erzeugt 13 Impact-Ketten, alle aufgezählt durch ubc diff --impact bei null Token-Kosten. Der Agent arbeitet diese eingegrenzte Menge ab und lädt nur den relevanten Teilgraph für jede Artefakt-Ebene.
Die Vollständigkeits-Obergrenze für plan-basierte Ansätze wird durch das bestimmt, was der Plan-Autor aufzuschreiben wusste. Die Vollständigkeits-Obergrenze für graph-basierte Ansätze wird durch die Struktur des Graphen bestimmt. Eines hängt von menschlicher Voraussicht ab. Das andere von Daten.
“Aber wir bauen keine sicherheitskritischen Systeme”
Die meisten Softwareprojekte brauchen kein ISO 26262. Aber das Szenario — eine Parameteränderung über verknüpfte Artefakte propagieren — ist universell. Jedes Projekt, bei dem Anforderungen auf Specs verweisen, die auf Code verweisen, der auf Tests verweist, hat dieses Problem. Der Unterschied: bei nicht-sicherheitskritischen Projekten prüft niemand, ob man es richtig gemacht hat. Die verpassten Artefakte werden zu Bugs, Inkonsistenzen oder technischen Schulden, die Wochen später auftauchen.
Georg Doll machte diesen Punkt auf der useblocks User Conference: Coding macht 14% der Arbeitszeit eines Entwicklers aus. Der Rest ist Verstehen, was ein System tun soll, Dokumentation mit Code und Tests synchron halten und Reviews und Audits abwickeln. AI-Agents können die 14% gut. Ohne strukturelles Bewusstsein arbeiten sie bei den anderen 86% blind.
Jedes Projekt, das AI-Agents einsetzt, zahlt bereits die unstrukturierte Steuer. Man verbrennt Tokens für Kontext-Neuladungen, Disambiguierungsdurchläufe und Verifikationsschritte, die nicht nötig wären, wenn die Agents einen Traceability-Graph abfragen könnten, statt eine wachsende Chat-Historie zu parsen.
Wie es in der Praxis aussieht
Wenn du Anforderungen in irgendeiner Form schreibst — Markdown-Dateien, Jira-Tickets, RST — bist du auf halbem Weg. sphinx-needs lässt dich diese Anforderungen als strukturierte, verknüpfte Objekte mit typisierten Beziehungen ausdrücken. ubcode gibt dir das Tooling, um diese Objekte von der Kommandozeile aus zu bauen, abzufragen und zu validieren. Zusammen machen sie aus deinen Specs einen Graph, den Menschen und Maschinen gleichermaßen traversieren können.
Sobald deine Specs in diesem Graph sind, ändern sich die Ökonomien. Der Pharaoh-Ansatz aus dem Benchmark — pharaoh — ist eine Möglichkeit, den Graph auszunutzen: er verwendet ubc diff --impact, um die vollständige Impact-Menge aufzuzählen, bevor ein einziges LLM-Token ausgegeben wird, und verteilt dann eingegrenzte Arbeit pro Artefakt-Ebene. So kam er auf 15 von 15 bei einem Sechstel der Token-Kosten.
Aber man braucht Pharaoh nicht, um zu profitieren. Der Graph ist der Punkt, nicht ein bestimmtes Tool, das darauf aufbaut. Man könnte die Ausgabe von ubc diff --impact in die bestehenden Agent-Prompts einspeisen — Superpowers-Pläne, spec2cloud-FRDs, welchen Koordinationsansatz man auch nutzt — und den Großteil der Vollständigkeitslücke schließen. Der Plan-Autor, der die Motorrad-Varianten-Spec verpasste, hätte sie gefunden, wenn die Impact-Menge im Prompt gewesen wäre. Die Agents, die Tokens für Kontext-Neuladungen verbrannten, hätten weniger geladen, wenn sie auf den relevanten Teilgraph eingegrenzt gewesen wären.
Nichts davon erfordert, dass deine Agents schlauer werden. Es erfordert, dass deine Daten strukturiert sind.
Dolls Einordnung trifft es: das beste Modell mit schlechtem Kontext verliert gegen ein mittelmäßiges Modell mit präzisen Specs. Der Benchmark beweist es mit Zahlen. sphinx-needs und ubcode machen aus deinen Specs den präzisen, abfragbaren Kontext, den Agents tatsächlich brauchen.
Das Fazit
Du zahlst eine 6×-Steuer. Nicht weil deine Agents schlecht sind, sondern weil sie keine Karte haben, was womit zusammenhängt.
Die Lösung ist Spec-Driven Development. Schreib deine Anforderungen als strukturierte, verknüpfte Objekte in sphinx-needs. Nutze ubcode zum Abfragen, Diffen und Validieren. Wenn sich eine Anforderung ändert, sagt dir ubc diff --impact — deterministisch, bei null Token-Kosten — was sich sonst noch ändern muss. Speise das in deine bestehende Agent-Koordination ein.
Man kann spezialisiertes Tooling auf dem Graph bauen — pharaoh tut genau das. Oder man fügt die Impact-Menge in seine Superpowers-Pläne ein und bekommt den Großteil des Vorteils ohne neue Tools in der Kette. Der Punkt ist derselbe: gib deinen Agents einen strukturierten Graph statt einer wachsenden Chat-Historie, und die Vollständigkeitslücke schließt sich.
Der Aufwand für die Einrichtung ist real. Die Alternative — Tokens für Kontext-Neuladungen verbrennen, variantenabgeleitete Artefakte verpassen, geteilten Zustand manuell disambiguieren — ist teurer und unzuverlässiger.
Probier es an einer echten Anforderungsänderung. Kein Demo. Kein Einzeldatei-Spielbeispiel. Eine Änderung, die Anforderungen, Specs, Code und Tests über Varianten hinweg berührt. Da zeigt sich der Unterschied.
Die Benchmark-Daten in diesem Beitrag stammen aus Erwin Roths Bericht “Structured Traceability at Scale” (Audi, März 2026). Das Spec-Driven-Development-Framework stammt aus Georg Dolls Präsentation auf der useblocks User Conference (Microsoft, April 2026). Beide sind öffentlich verfügbar.
