Gestern sollte ein Coding Agent in einem Repository einen Tastatur-Shortcut ergänzen. Heute soll er eine ähnliche Funktion ändern. Gut möglich, dass er wieder dieselben Dateien sucht, die gleichen Tests liest und erneut auf bekannte Hindernisse stößt. Dass die erste Erkundung Zeit und Tokens kostet, ist verständlich. Warum sollte die zweite Aufgabe denselben Preis haben?

Über einen Show-HN-Beitrag bin ich auf Singularity gestoßen. Das Open-Source-Projekt will abgeschlossene Codeänderungen in wiederverwendbare Workflows verwandeln: Wo wurde etwas geändert? Wie lässt es sich überprüfen? Welche Fallstricke gab es schon? Für eine neue Aufgabe werden passende Schritte aus dem Gedächtnis gesucht und dem Agenten zur Verfügung gestellt.

Eine reizvolle Idee. Mich interessiert allerdings eine andere Frage: Nur weil sich eine Erinnerung abrufen lässt, woher wissen wir, dass sie zur heutigen Aufgabe und zum aktuellen Repository passt?

Ich habe Singularity auf Commit 9d241f2 festgelegt, den Code untersucht und einen kleinen, modellfreien synthetischen Test durchgeführt. Die Grenze ist wichtig: Ich habe Singularity nicht vollständig installiert oder als CLI end-to-end getestet und keinen Token-Kostenvergleich mit Claude Code oder Codex ausgeführt. Geprüft wurde eine eigenständig nachgebildete Teilmenge der Matching-Regeln und deren mögliche Fehlentscheidungen.

Kein Chatprotokoll, sondern ein Weg durch den Code

Laut README des fixierten Quellstands sammelt Singularity Erfahrungen aus erfolgreichen Änderungen. Ein Modell verdichtet wiederkehrende Erfahrungen anschließend zu Workflows. Darin könnte stehen, welche Dateien bei bestimmten Funktionen üblicherweise angefasst werden, welche Testbefehle wichtig sind und an welchen Stellen frühere Versuche gescheitert sind.

Das ist etwas anderes als ein ganzes Gespräch dauerhaft zu speichern. Ein Chat enthält viel Suche und Experimentieren, das nur in jener Situation nützlich war. Ein Workflow versucht dagegen, wiederholbare Handgriffe festzuhalten. Hier geht es um die Wiederverwendung von Schritten und ihren Suchhinweisen; ich behaupte nicht, sämtliche sonstigen Caching-Verfahren des Projekts untersucht zu haben. Selbst ein früher korrekter Dateipfad muss nach Repository-Änderungen erneut geprüft werden.

Außerdem entstehen Kosten an zwei verschiedenen Stellen. Das Lernen eines Workflows kann Modellaufrufe erfordern. Die Auswahl von Schritten anhand bereits erzeugter Hinweise kann dagegen ohne Modell auskommen. workflows-cues ist auf den zweiten Fall ausgerichtet.

Daraus folgt ausdrücklich nicht, dass Singularity überall ohne Modellkosten arbeitet. Die Evaluierungsdatei StepSelector.ts ruft ein Modell auf, um passende Schritte auszuwählen. Dagegen beschreibt Memory.ts workflows-cues als modellfreie Auswahl anhand textueller Hinweise. Das sind zwei unterschiedliche Evaluierungswege mit anderen Kostenstrukturen. Einen belastbaren Vergleich von Laufzeit oder Tokenverbrauch an echten Aufgaben habe ich nicht durchgeführt.

Was gleicht die modellfreie Suche tatsächlich ab?

Als Nächstes habe ich apps/cli/src/workflows/Cues.ts gelesen.

Die Grundidee ist recht einfach. Die Aufgabenbeschreibung wird hinsichtlich Groß- und Kleinschreibung normalisiert. Anschließend versucht der Code, verneinte Satzteile mit Wörtern wie not, never oder without zu entfernen. Im verbleibenden Text sucht er nach zuvor generierten Auslösephrasen. Ein Workflow wird ausgewählt, wenn ein positiver Hinweis vorkommt und kein ausschließender Hinweis greift. Auch einzelne Workflow-Schritte lassen sich zusätzlich filtern.

Das Modul fragt kein Modell: „Sind diese beiden Aufgaben semantisch ähnlich?“ Es verhält sich eher wie eine gepflegte Tabelle mit Regeln für Zeichenketten. Das ist schnell, günstig und reproduzierbar. Die Kehrseite: Gleiche Wörter bedeuten nicht automatisch die gleiche Absicht.

Angenommen, der Auslöser lautet keyboard shortcut. „Add a keyboard shortcut“ sollte zu einem Treffer führen. „Review keyboard shortcuts in documentation only“ enthält dieselbe Phrase, verlangt aber keine Implementierungsänderung.

Einige ausdrückliche Verneinungen werden im Code behandelt. Das ist jedoch kein vollständiges Verständnis komplizierter Negation, impliziter Bedingungen oder von Absichten über mehrere Sätze. Der Matcher liefert mögliche Erinnerungen; er beweist nicht, dass die darin beschriebenen Schritte für die aktuelle Aufgabe richtig sind.

Fünf künstliche Eingaben und zwei bewusst problematische Treffer

Ich habe die zentralen Teile aus dem fixierten Cues.ts — Textnormalisierung, das Entfernen von Verneinungen sowie erlaubende und ausschließende Hinweise — manuell und unabhängig als kleinen Test mit der Node.js-Standardbibliothek nachgebaut. Es ist keine offizielle Upstream-Testsuite; die Abdeckung aller Randfälle ist nicht garantiert. Singularity wurde dafür nicht installiert, kein Modell verbunden und kein echtes Code-Repository verändert.

Skript und maschinenlesbare Ergebnisse liegen in privaten Forschungsaufzeichnungen und stehen nicht als öffentliche Downloads bereit. Die folgende Tabelle zeigt alle fünf Beobachtungen. Es handelt sich um eine synthetische Reproduktion von Quellcode-Regeln, nicht um einen vollständigen CLI-Lauf.

Künstlicher Aufgabentext	Matchergebnis	Aussage
Tastatur-Shortcut hinzufügen	Treffer	Erwarteter relevanter Abruf
Datenbankverbindung reparieren	Kein Treffer	Unpassende Aufgabe aussortiert
Ausdrücklich keinen Shortcut hinzufügen	Kein Treffer	Einfache Verneinung wirkt
Nur die Shortcut-Beschreibung in der Dokumentation prüfen	Treffer	Gleicher Wortlaut kann falsch abrufen
Shortcut hinzufügen, aber die gemerkte alte Datei wurde gelöscht	Treffer	Matcher prüft Dateiexistenz nicht

Die Erwartungen hatte ich vor der Ausführung aus den vereinfachten Regeln abgeleitet: Passende Aufgaben sollten treffen, unpassende und ausdrücklich verneinte Aufgaben nicht. Eine reine Dokumentationsaufgabe mit der Auslösephrase sollte dagegen einen Treffer ergeben. Auch die gelöschte Datei sollte am Textvergleich nichts ändern, da keine Dateisystemprüfung stattfindet.

Alle fünf Assertions lieferten das vorhergesagte Ergebnis. Dabei sind die letzten beiden Fälle absichtlich unerwünschte Resultate. „5 von 5 bestanden“ beschreibt weder die Präzision des echten Systems noch fünf erfolgreich erledigte Aufgaben. Es bestätigt lediglich die Vorhersagen für diesen synthetischen Matcher.

Der letzte Fall ist besonders wichtig. Die Textsuche in cueChoice weiß nicht, ob eine Datei inzwischen verschoben, gelöscht oder umstrukturiert wurde. Ein nachgelagerter Agent könnte das prüfen und den Fehler entdecken. Trotzdem kann eine veraltete Route bereits vorgeschlagen worden sein. Ein Treffer im Gedächtnis ist ein Hinweis, kein Beleg für den aktuellen Zustand des Repositories.

Wie belastbar sind die Token-Einsparungen im README?

Der Autor veröffentlicht einen Vergleich mit Excalidraw-Aufgaben. Bei einer längeren Aufgabe, die besonders gut zum erlernten Gedächtnis passte, sank die berichtete Tokenzahl von etwa 1,90 Millionen auf 423.000, der berichtete Preis von etwa 0,81 auf 0,30 US-Dollar und der Median der Gesprächsrunden von 28,5 auf 9,5. Pro Bedingung gab es allerdings nur ungefähr drei bis vier Läufe, und die Untersuchung konzentrierte sich auf wenige Repositories.

Das sind interessante Hinweise, aber weiterhin vom Autor gemeldete Werte für bestimmte Aufgaben. Bei unbekannten Änderungen oder einer winzigen einmaligen Korrektur kann der Nutzen nahe null liegen. Auch das Lernen der Workflows kostet etwas.

Weniger Tokens für das Lesen von Dateien bedeuten nicht zwangsläufig geringere Gesamtkosten. Eine falsche Erinnerung kann neue Recherchen auslösen. Nach einem größeren Refactoring kann ein alter Workflow die Fehlersuche erschweren statt verkürzen.

Ich habe den Modellvergleich des Autors nicht wiederholt und weder echte Tokens noch Dollarbeträge gemessen. Deshalb nenne ich keine unabhängig bestätigte Einsparquote. Dafür müsste man dieselben realen Aufgaben mit und ohne Gedächtnis durchlaufen lassen und Lernaufrufe, Korrekturen falscher Treffer sowie die Kosten bis zum endgültigen Abschluss mitrechnen. Diese Daten liefert mein Test nicht.

Wie ich ein solches Gedächtnis einsetzen würde

In Repositories mit vielen ähnlichen Änderungen, stabiler Verzeichnisstruktur und klaren Testbefehlen würde ich Workflow-Gedächtnis ausprobieren. Ich würde es aber als Index zur Überprüfung betrachten, nicht als Befehl, den ein Agent blind ausführen darf.

Eine Erinnerung könnte den Quell-Commit, betroffene Pfade, den Zeitpunkt der letzten Verifikation und Anwendungsbedingungen enthalten. Vor dem Einsatz sollten die Dateien noch existieren und die Testbefehle funktionieren. Führt ein Workflow wiederholt zu Korrekturen von Hand, sollte man ihn neu lernen oder deaktivieren. Das ist mein Vorschlag, nicht die Behauptung, dass Singularity in der untersuchten Version eine vollständige Gültigkeitsprüfung besitzt.

Auch die Installationsentscheidung sollte sich nach der Wiederholbarkeit der eigenen Aufgaben richten, nicht nach einer spektakulären Tokenzahl. Wer jedes Mal an anderen Repositories, Sprachen und Problemen arbeitet, gewinnt möglicherweise weniger, als die Pflege der Erinnerungen kostet.

Ich würde gern einen öffentlichen Versuch mit denselben realen Aufgaben sehen, der nützliche Treffer, falsche Treffer, veraltete Erinnerungen, Lernaufwand und gesamte Fertigstellungskosten gemeinsam ausweist. Erst dann lässt sich beurteilen, ob das Gedächtnis wiederholte Arbeit spart — oder nur einen Teil der Erkundungskosten in Wartungsaufwand verwandelt.

Quellen: Singularity-Repository · fixierte Cue-Matching-Implementierung · Evaluierung und Einschränkungen laut Autor