Graft Review: Kann eine Repo-Map ein Team-Asset sein?

Graft löst ein echtes Problem, und die virale Version des Pitches liegt genau bei dem Punkt falsch, der Engineering-Verantwortliche am meisten interessiert. Das Problem ist real: Ein Coding-Agent startet die meisten Aufgaben blind, greppt sich durch dein Repository, baut ein Bild neu auf, das er gestern schon hatte, und stellt dir die Wiederentdeckung in Rechnung. Graft schreibt dieses Bild als verlinkte Markdown-Knoten auf die Platte, damit die nächste Aufgabe orientiert beginnt.

In den Feeds kursiert die Behauptung, die Map wandere danach über Git mit und das ganze Team erbe sie. Die eigene Dokumentation von Graft sagt das Gegenteil. Im offiziellen Graft-Repository steht im README, der Graph sei "a local, regenerable cache (like node_modules), not something you commit". graft build trägt graft/ automatisch in deine .gitignore ein, und jede Person im Team baut sich mit graft build die eigene Kopie.

Das ist kein Fehler, sondern das richtige Default, und es verändert, was du eigentlich einführst: eine gemeinsame Konvention plus einen billigen Rebuild, kein gemeinsames Dokument. Unser Fazit nach der Prüfung des Projekts am 18. August 2026: verdrahte Graft in einem Repository und miss es, aber plane die Team-Story um das, was wirklich in die Versionskontrolle gehört. Diese Seite besitzt die produktspezifische Frage "Graft Review" und "Repo-Map im Git". Unser Graphify Review besitzt die Entscheidung über einen abfragbaren Codebasis-Wissensgraphen, und der Leitfaden zu Graph Engineering besitzt die Frage, wann sich ein Graph überhaupt rechnet.

Was ist Graft?

Graft ist ein MIT-lizenziertes TypeScript-CLI, das ein Repository in einen Ordner verlinkter Markdown-Knoten plus einen Graphen pro Symbol verwandelt und dieses Ergebnis in die Agents verdrahtet, die du ohnehin nutzt. Die Installation sind zwei Befehle, npm install -g @nanonets/graft und graft init. Der Build läuft in zwei Stufen, und der Unterschied zwischen ihnen entscheidet über Kosten und Datenschutzprüfung.

Zwei Designentscheidungen sind wichtiger als die Benchmark-Tabelle. Erstens gibt es keinen Vektorstore: Die eigene Projektbeschreibung spricht von Dateien, die dein Agent liest, ohne Server, Datenbank oder Embeddings. Zweitens ist Frische eine Schleife statt eines Index: Jede Abfrage vergleicht den Arbeitsbaum mit dem Fingerprint des letzten Builds und baut nur nach, was sich bewegt hat, strukturell und ohne Tokenkosten. Damit beschreiben Antworten auch nicht committete Änderungen.

Diese zweite Entscheidung ist die eigentliche Ingenieursleistung. Eine veraltete Map ist schlimmer als keine Map, weil der Agent ihr vertraut. Vorgeschichte gehört dazu: Aider lieferte schon im Oktober 2023 eine per PageRank gewichtete tree-sitter-Repo-Map. Die gewichtete Repo-Map ist nicht neu. Neu sind die Refresh-Schleife und die Verdrahtung über mehrere Agents.

Committet Graft die Repo-Map ins Git?

Nein, und du solltest es auch nicht wollen. Was über die Versionskontrolle wandert, ist das Wiring: die Dateien, die graft init in .claude/ ablegt, der markierte Graft-Abschnitt in der AGENTS.md und die MCP-Konfiguration. Der generierte Graph unter graft/ ist gitignored und wird pro Clone neu gebaut.

Wir sind auf dem Repository dieser Website auf dieselbe Erkenntnis gestoßen, allerdings auf dem harten Weg. Wir betreiben Coding-Agents in parallelen Git-Worktrees, und generierte Graph-Ausgaben sind dort bewusst aus der Versionskontrolle ausgeschlossen, weil die generierten Dateinamen zwischen gleichzeitigen Branches kollidieren und ein Konflikt in einer maschinell geschriebenen Datei Review-Zeit kostet, ohne Review-Wert zu liefern. Eine eingecheckte Map veraltet außerdem im Tempo des jeweiligen Branches, also genau dann, wenn ein Agent am ehesten darauf reagiert.

Die ehrliche Formulierung des Team-Nutzens ist also enger als die virale, und nützlicher. Graft gibt deinem Kollegen nicht das Wissen, das dein Agent aufgebaut hat. Es gibt ihm einen Befehl von zwei Sekunden, der eine gleichwertige Map aus derselben Quelle der Wahrheit neu baut: dem Code. Das ist eine bessere Garantie als eine gemeinsame Datei, weil sie nicht driften kann. Es ist damit aber eine Rollout-Aufgabe und keine Dokumentationsaufgabe.

Was gehört dann ins Git?

Die brauchbare Regel ist kurz: committe, wofür ein Mensch verantwortlich ist, und generiere neu, was ein Parser wiederherstellen kann. Generierte Struktur ist billig und selbstkorrigierend. Absicht ist beides nicht.

1. Entscheidungen und Randbedingungen. Build- und Testbefehle, Grenzen, die der Agent nicht überschreiten darf, warum das hässliche Modul hässlich bleibt, welche Schnittstelle ein Vertrag ist. Genau dafür existiert AGENTS.md, ein Format, das über 60.000 Open-Source-Projekte nutzen und das inzwischen von der Agentic AI Foundation unter der Linux Foundation betreut wird. Es ist handgeschrieben, wird im Pull Request reviewt und ist die Pflege wert.
2. Abgeleitete Struktur. Call-Graphen, Symbol-Maps, gewichtete Dateilisten. Neu baubar, also gitignore sie und mach den Rebuild schnell und automatisch.
3. Institutionelles Wissen, das kein Code ist. Runbooks, Domänenregeln, Entscheidungen mit Owner und Review-Datum. Das gehört in einen governten Speicher, was ein anderer Bau mit anderen Regeln ist. Unsere Architektur für ein KI-taugliches Firmenwiki deckt das ab.

Teams scheitern hier meist in eine von zwei Richtungen. Sie committen generierte Ausgaben und erben Merge-Rauschen plus selbstbewusst veraltete Antworten. Oder sie schreiben gar nichts auf und erwarten, dass das Tool eine Absicht ableitet, die nie irgendwo festgehalten wurde. Eine Repo-Map kann einem Agent nicht sagen, dass eine Tabelle gerade migriert wird und keine Spalten bekommen darf. Das kann nur ein Mensch. Dieselbe Disziplin steckt in unserer Checkliste für die Software-Übergabe, die für die menschliche Variante desselben Problems geschrieben wurde: Was muss aufgeschrieben sein, bevor die Person geht, die es weiß.

Wie belastbar sind die Zahlen von Graft?

Der Mechanismus ist glaubwürdig und jede veröffentlichte Zahl stammt vom Hersteller. Diese Kombination verdient einen Pilot, keine Beschaffungsentscheidung. Graft veröffentlicht drei getrennte Messreihen, und sie sind nicht gleich stark.

Der SWE-bench-Arm ist der stärkste, weil die Bewertung deterministisch ist. Er ist auch der, den du am genauesten lesen solltest. Das vollständige SWE-bench Verified enthält 500 von Menschen validierte Instanzen; 50 sind ein Zehntel davon, und der Bericht sagt nicht, welches Zehntel. Die zwei namentlich diskutierten Instanzen sind Django, und eine verbreitete 50er-Teilmenge, SWE-bench-verified-mini, zieht nur aus Django und Sphinx. Keine dieser beiden Tatsachen sagt dir, was Graft tatsächlich gezogen hat, und genau diese Lücke ist die Einschränkung, die man benennen sollte: ohne die Instanzliste ist die Projekt- und Sprachabdeckung hinter der Zahl unbekannt. Sechs zusätzliche Instanzen auf einer nicht offengelegten Stichprobe von 50, einmal gelaufen, sind ein Richtungssignal. Sie sind keine Leaderboard-Position und kein Beweis über deinen Kotlin-Service.

Der praktisch wichtigste Befund steht nicht im Marketing vorne. Die Messreihe hatte eine dritte Variante: pull, bei der der Agent die Graft-Tools bekommt, aber nichts vorab injiziert wird, sodass Kontext nur bei Bedarf bezahlt wird. Pull gab den größten Teil des Geschwindigkeitsgewinns ab und erreichte 98% Korrektheit gegen 93% bei einem kalten Agent. Wenn Richtigkeit wichtiger ist als Tempo, ist das die Konfiguration, die du zuerst testen solltest, und sie ist das Gegenteil des Vorab-Bundles, das die Schlagzeilen-Latenz erzeugt.

Was kostet Graft wirklich?

Es gibt keine Lizenzgebühr. Danach endet das Kostenlose, und das echte Budget hat vier Posten.

• Strukturelle Builds sind tatsächlich gratis. tree-sitter-Parsing, die Refresh-Schleife und die strukturellen Abfragen rufen nie ein Modell. In einem großen Repository liegt darin der größte Teil des Nutzens bei null Grenzkosten.
• Die Konzeptebene ist ein Tokenposten. graft build --deep fasst Dateien und Symbole unter deinem Key zusammen, gecacht über den Body-Hash, sodass die Kosten an der Änderungsrate hängen. Kalkuliere sie pro aktiver Person und Clone, nicht einmal pro Repository.
• Reifegrad kostet. Das Projekt wurde am 3. Juli 2026 angelegt, der aktuellste Tag ist v0.9.0, bei rund 3.500 Stars und dutzenden offenen Issues zum Zeitpunkt dieses Textes. Eine Pre-1.0-Abhängigkeit im Kontextpfad deines Agents verdient eine gepinnte Version und einen getesteten Upgrade-Pfad wie jedes andere Build-Tool.
• Review-Zeit ist der Posten, den man vergisst. Maschinell geschriebene Summaries sind ungeprüfter Text über deine Architektur. Wenn ein Agent auf ein falsches Summary hin handelt, zahlt eine erfahrene Person das im Review. Unser Framework für Kosten pro Aktion liefert den richtigen Nenner: Kosten pro akzeptierter Änderung inklusive Review-Minuten und Nacharbeit, nicht gesparte Tokens pro Abfrage.

Tokens sind das am leichtesten Messbare und das am wenigsten Interessante zum Optimieren. Die systematische Version dieses Arguments steht in unserem Playbook für Token-Budgets, das Caching, Routing und Kompression in der Reihenfolge behandelt, die die Qualität schützt.

Was müssen EU-Teams vor dem Rollout prüfen?

Die Trennung der Ebenen passt praktischerweise sauber auf die Compliance-Frage.

Ein einfaches graft build ist lokal und deterministisch, und das Projekt gibt an, keine Telemetrie zu senden; die einzigen Netzwerkaufrufe sind die Modellanfragen, die du selbst konfigurierst. Für regulierte Arbeit ist das eine starke Position: Du bekommst Orientierung, Symbol-Maps und Call-Graphen, ohne dass Code die Maschine verlässt.

graft build --deep ist eine andere Entscheidung. Es schickt Datei- und Symbolinhalte an den Anbieter, auf den du es richtest, und macht diesen Anbieter damit zum Auftragsverarbeiter für deinen Quellcode. Kläre Auftragsverarbeitungsvertrag, Region, Aufbewahrungsdauer und Trainingsnutzung vor dem ersten Deep-Build, nicht nachdem jemand ihn auf dem Zahlungsservice ausgeführt hat. Unser Leitfaden zur EU-Datenresidenz deckt die Anbieterseite ab, und Redaktion vor dem Prompt deckt Repositories ab, in denen Fixtures und Logs Personendaten tragen.

Eine Kontrolle noch, die früh gesetzt werden sollte: Der generierte Graph ist eine kompakte, lesbare Beschreibung deines Systemaufbaus. Behandle ihn wie Quellcode. Er hat in keinem Support-Bundle, keinem öffentlichen CI-Artefakt und keinem Screenshot in einem Ticket etwas zu suchen.

Graft, Repo-Map oder Wissensgraph: welches Problem löst du?

Die meisten Teams, die zu so einem Tool greifen, haben eines von fünf verschiedenen Problemen, und nur zwei davon löst eine Repo-Map.

Wenn du noch überlegst, ob sich davon überhaupt etwas rechnet, fang eine Ebene höher an. Unsere Analyse zu Kontext als echtem Engpass erklärt, warum diese Kategorie existiert, und der Feldbericht zur Kontextkompression zeigt, wie gemessene Einsparungen in unserer eigenen Projektarbeit aussehen statt in einer Herstellertabelle.

Ein zweiwöchiger Graft-Pilot, der eine Entscheidung liefert

1. Nimm ein Repository, das weh tut. Groß, mehrsprachig, schlecht dokumentiert, aktiv bearbeitet. Ein sauberer Service mit 40 Dateien zeigt keinen Unterschied.
2. Friere das Aufgabenset ein, bevor du irgendetwas installierst. Zehn echte Orientierungs- und Lokalisierungsfragen plus fünf Änderungen, die du schon gemergt hast, zurückgesetzt auf ihren Base-Commit.
3. Fahre drei Arme, nicht zwei. Kalt, Push (Bundle vorab) und Pull (Tools auf Abruf). Die eigenen Daten des Herstellers sagen, dass sich diese bei der Korrektheit unterschiedlich verhalten.
4. Bewerte Änderungen mit Tests, nicht mit Dateiüberdeckung. Die richtigen Dateien anzufassen ist ein schwacher Proxy. Deine Testsuite ist der Prüfer, dem du schon vertraust.
5. Zähle Kosten pro akzeptierter Änderung. Tokens, Wall-Clock, Retries und Review-Minuten, geteilt durch die Änderungen, die das Review überlebt haben.
6. Greif die Frische an. Fahre Abfragen auf einem dirty Tree, mitten im Rebase, nach einem großen Rename und auf einem Branch, der ein Subsystem gelöscht hat. Eine Map, die selbstbewusst lügt, ist das Hauptrisiko dieser Kategorie.
7. Entscheide den Anbieter für den Deep-Build bewusst. Route ihn über deinen bestehenden freigegebenen Modellpfad, oder lass die Konzeptebene im Pilot aus und miss nur die kostenlose strukturelle Ebene.
8. Prüfe, was im Git landet. Reviewe den Wiring-Diff, bestätige, dass graft/ ignoriert wird, und dass nichts Generiertes in einen Commit gerutscht ist.
9. Pinne die Version. Und mach dann während des Piloten absichtlich ein Upgrade, um zu sehen, was das Upgrade kostet.
10. Lege das Skalierungskriterium vorher fest. Übernimm nur, wenn sich verifizierte Korrektheit oder Kosten pro akzeptierter Änderung genug verbessern, um Rebuild, Review und eine Pre-1.0-Abhängigkeit zu bezahlen.

Zwei Wochen reichen, weil die Messung mechanisch ist, sofern jemand sie verantwortet. Wavects KI-Enablement-Service fährt diesen Vergleich in deinem Repository und übergibt die Messumgebung, damit das Ergebnis die Beratung überlebt. Die Twinsoft-AI-Case-Study zeigt, wie wir nachvollziehbare KI-Ausgaben und Reviewer-Kontrolle in Produktionsarbeit handhaben. Wenn du Umsetzung gegen ein Strategiepapier abwägst, vergleiche zuerst KI-Enablement mit generischer KI-Beratung und sag uns dann, welches Repository das schmerzhafte ist.

Grenzen dieser Recherche

Stand geprüft am 18. August 2026 gegen das öffentliche Repository und die Projektseite von Graft. Dies ist ein unabhängiges Architektur- und Buyer-Review, kein Sponsored Post, kein Sicherheitsaudit und kein eigener kontrollierter Benchmark des Tools. Jede hier zitierte Leistungszahl ist vom Hersteller veröffentlicht und mit dessen Messumgebung erhoben, wobei der SWE-bench-Arm den offiziellen Grader verwendet. Das Projekt ist Pre-1.0 und bewegt sich schnell, also pinne eine Version und lies die aktuelle Dokumentation, bevor du dich darauf standardisierst.