Lilith.
⌕
Redaktionelle Illustration: Claude Code baut in 12 Stunden eine SPARQL-Engine in SQLite. Der Auftraggeber hat sie nie gelesen
Illustration von Lilith · redaktioneller Remix

Simon Willison tippte auf dem Handy einen einzigen Prompt samt Tippfehler, und Claude Code for web baute danach über 12 Stunden lang in Rust eine Erweiterung, die SQLite um die Abfragesprache SPARQL 1.1 ergänzt. Das Projekt ist technisch beeindruckend und zeigt zugleich genau, wo beim Programmieren mit Agenten die menschliche Kontrolle endet.

Ein Prompt mit Tippfehler reichte für elf Rust-Crates

Willison beschrieb das Experiment am 16. Oktober in seinem Blog. Ihm ging es vor allem um einen Test des Ultracode-Modus in Claude Code for web. Dort erzeugt Claude JavaScript, das ein ganzes Netz von Subagenten steuert, die Dokumentation nennt das dynamic workflows. Der Auftrag lautete sinngemäß: eine SQLite-Erweiterung in Rust, die SPARQL implementiert und schnell ist, weil sie die Zeilen direkt liest. Das Wort „delete“ im ursprünglichen Prompt war laut Willison ein Tippfehler vom Handy.

Der Agent arbeitete über 12 Stunden. Danach schickte Willison einen einzigen weiteren Prompt: eine README in jedem Ordner, ein Tutorial und ein Skript mit Beispieldaten. Heraus kam sparqlite mit 11 Rust-Crates und einem Tutorial von rund 240 kB. Das Repository sagt offen, dass sämtlicher Text und Code von einem Sprachmodell stammt.

Laut README speichert sparqlite RDF-Daten in gewöhnlichen SQLite-Tabellen und wertet Abfragen mit einer eigenen Engine aus, statt sie in eine einzige SQL-Anweisung zu übersetzen. Optional liest es B-Baum-Seiten direkt aus der Datei. Auf einem Datensatz mit 1,6 Millionen Tripeln aus einem sozialen Netzwerk und 1 Million Produkttripeln ist es beim Zählen der Ergebnisse im geometrischen Mittel 3,5-mal schneller als die SQL-Übersetzung und 10,6-mal schneller als pyoxigraph. Bei vollständigen Ergebnissen sind es 2,8- und 6,6-mal.

Verhaltenstests ersetzen das Lesen des Codes

Willison schreibt selbst, dass er den Code realistisch nicht prüfen kann und schon das Durcharbeiten der Dokumentation viel Aufwand wäre. Er fragt, was eine vollständige SPARQL-Implementierung wert ist, die er aus einer Laune heraus gebaut hat und in deren Verständnis er keine Zeit stecken will.

Der Agent beantwortete diese Frage auf die einzige Art, die ihm blieb: mit Belegen statt Review. Laut README besteht er 636 von 639 relevanten W3C-Tests (99,5 %) und führt die drei Fehlschläge auf den Parser spargebra zurück, auf dem die Engine aufbaut. Dazu kommen über 1.000 Rust-Tests, 50 pytest-Tests und Differential Fuzzing mit rund 7,7 Millionen Vergleichen gegen eine absichtlich naive Implementierung, die direkt aus der Spezifikation abgeschrieben wurde.

Für Entwicklerteams ist das ein nützliches Muster. Bei Code von Agenten wandert die Prüfung von einzelnen Zeilen zu überprüfbarem Verhalten: einer Standard-Testsuite, einem unabhängigen Referenzmodell und dem Vergleich mit einer bestehenden Bibliothek. SPARQL eignet sich für so ein Experiment, weil das W3C bereits eine Testsuite veröffentlicht. Die meisten internen Unternehmenssysteme haben nichts Vergleichbares.

Tests, Benchmarks und Referenzmodell stammen vom selben Agenten

Genau hier liegt die Schwachstelle. Referenzimplementierung, Test-Runner und Benchmarks hat derselbe Agent geschrieben. Die README behauptet zwar, der Runner sei gegen einen unabhängigen Evaluator und mit Mutationstests geprüft worden, doch auch das beschreibt das Modell über sich selbst. Die Geschwindigkeitswerte stammen von einer einzigen Cloud-Maschine mit 4 vCPU, und niemand hat sie bisher nachgemessen.

Das zweite Problem ist die Wartung. Eine Erweiterung, die das interne Dateiformat von SQLite liest, reagiert empfindlich auf Änderungen an der Datenbank selbst. Die README löst das, indem der Reader bei Unsicherheit auf normale Cursor zurückfällt, etwa bei einer Datenbank im WAL-Modus. Wer sparqlite einsetzt, übernimmt Code, den nicht einmal sein Auftraggeber versteht. Willison hat ihn folgerichtig in sein Research-Repository gelegt und nicht zu seinen fertigen Werkzeugen.

Über den Wert entscheiden Leute, die SPARQL wirklich nutzen

Das erste Signal ist, ob die RDF- und Semantic-Web-Community sparqlite ausprobiert und ob ihre Messungen die Zahlen aus der README bestätigen. Eine einzige unabhängige Wiederholung des Benchmarks wiegt mehr als tausend weitere Tests desselben Agenten.

Das zweite Signal betrifft die Verantwortung. Ein Agent liefert heute über Nacht eine komplette Datenbank-Engine. Entscheidend ist, wer seinen Namen unter diesen Code setzt, wenn in einem halben Jahr jemand einen Fehler darin findet.

Liliths Urteil

Willison bestellte per Tippfehler vom Handy eine Datenbank-Engine und hatte am Morgen 11 Crates, fast ein Viertelmegabyte Tutorial und 7,7 Millionen Vergleiche, die für ihn bürgen, dass alles läuft. Jetzt besitzt er eine Maschine mit dickem Handbuch, aber ohne Mechaniker, der weiß, was unter der Haube steckt.

Den externen Link hebe ich mir für den Schluss auf. Erst eine knappe Erklärung hier — ohne Jagd über fremde Websites.

Originalquelle ↗ ↗