Claude Code w 12 godzin zbudował silnik SPARQL w SQLite. Zamawiający go nie przeczytał

Simon Willison wpisał na telefonie jeden prompt, w dodatku z literówką, a Claude Code for web przez ponad 12 godzin budował w Ruście rozszerzenie, które dodaje do SQLite język zapytań SPARQL 1.1. Projekt robi wrażenie technicznie i jednocześnie dobrze pokazuje, gdzie w programowaniu z agentami kończy się ludzka kontrola.

Jeden prompt z literówką wystarczył na jedenaście crate'ów w Ruście

Willison opisał eksperyment 16 października na swoim blogu. Chodziło mu głównie o sprawdzenie trybu Ultracode w Claude Code for web. Claude generuje w nim JavaScript, który koordynuje całą sieć subagentów, a dokumentacja nazywa to dynamic workflows. Polecenie brzmiało mniej więcej tak: napisz w Ruście rozszerzenie SQLite, które implementuje SPARQL i działa szybko, bo czyta wiersze bezpośrednio. Słowo „delete” w oryginalnym prompcie było według autora literówką z telefonu.

Agent pracował ponad 12 godzin. Potem Willison wysłał tylko jeden dodatkowy prompt: README w każdym katalogu, tutorial i skrypt generujący przykładowe dane. Tak powstał sparqlite, czyli 11 crate'ów w Ruście i tutorial o objętości około 240 kB. Repozytorium otwarcie informuje, że cały tekst i kod napisał model językowy.

Według README sparqlite przechowuje dane RDF w zwykłych tabelach SQLite i wykonuje zapytania własnym silnikiem, zamiast tłumaczyć je na jedno zapytanie SQL. Opcjonalnie czyta strony B-drzewa prosto z pliku bazy. Na danych z 1,6 miliona trójek z sieci społecznościowej i 1 miliona trójek produktowych jest przy zliczaniu wyników średnio (geometrycznie) 3,5 raza szybszy od tłumaczenia na SQL i 10,6 raza szybszy od pyoxigraph. Przy zwracaniu pełnych wyników to odpowiednio 2,8 i 6,6 raza.

Zamiast czytania kodu wchodzą testy, które sprawdzają zachowanie

Willison sam pisze, że realnie nie jest w stanie przejrzeć tego kodu, a nawet przebrnięcie przez dokumentację wymagałoby sporo pracy. Zastanawia się, ile jest warta pełna implementacja SPARQL, którą zrobił z kaprysu i w której zrozumienie nie zamierza inwestować czasu.

Agent odpowiedział na to jedynym dostępnym sposobem: dowodami zamiast code review. Według README przechodzi 636 z 639 odpowiednich testów W3C (99,5 %), a trzy porażki przypisuje parserowi spargebra, na którym opiera się silnik. Do tego dochodzi ponad 1000 testów w Ruście, 50 testów w pyteście i differential fuzzing z około 7,7 miliona porównań z celowo naiwną implementacją przepisaną wprost ze specyfikacji.

Dla zespołów programistycznych to przydatny wzorzec. Przy kodzie pisanym przez agenta weryfikacja przesuwa się z pojedynczych linijek na sprawdzalne zachowanie: standardowy zestaw testów, niezależny model referencyjny i porównanie z istniejącą biblioteką. SPARQL nadaje się do takiego eksperymentu, bo W3C ma gotowy zestaw testów. Większość firmowych systemów nie ma niczego podobnego.

Testy, benchmarki i model kontrolny napisał ten sam agent

I tu jest słaby punkt. Implementację referencyjną, runner testów i benchmarki stworzył ten sam agent. README twierdzi wprawdzie, że runner sprawdzono z niezależnym ewaluatorem i testami mutacyjnymi, ale to też jest opis, który model wystawił sam sobie. Dane o wydajności pochodzą z jednej maszyny w chmurze z 4 vCPU i nikt ich jeszcze nie powtórzył.

Drugi problem to utrzymanie. Rozszerzenie, które czyta wewnętrzny format plików SQLite, jest wrażliwe na zmiany w samej bazie. README rozwiązuje to powrotem do zwykłych kursorów, gdy czytnik nie ma pewności, na przykład przy bazie w trybie WAL. Kto wdroży sparqlite, przejmie kod, którego nie rozumie nawet osoba, która go zamówiła. Willison zresztą wrzucił projekt do repozytorium research, a nie do gotowych narzędzi.

O wartości projektu przesądzą ludzie, którzy naprawdę używają SPARQL

Pierwszym sygnałem będzie to, czy sparqlite przetestuje społeczność RDF i sieci semantycznej i czy jej pomiary potwierdzą liczby z README. Jedno niezależne powtórzenie benchmarku waży więcej niż kolejny tysiąc testów od tego samego agenta.

Drugi sygnał dotyczy odpowiedzialności. Agent potrafi dziś w jedną noc dostarczyć cały silnik bazodanowy. Liczy się to, kto podpisze się pod tym kodem, gdy za pół roku ktoś znajdzie w nim błąd.

Werdykt Lilith

Willison zamówił silnik bazodanowy literówką z telefonu, a rano dostał 11 crate'ów, prawie ćwierć megabajta tutoriala i 7,7 miliona porównań, które ręczą za to, że wszystko działa. Ma teraz maszynę z grubą instrukcją i bez mechanika, który wie, co siedzi pod maską.