Claude Code za 12 hodin postavil SPARQL engine do SQLite. Zadavatel ho nečetl

Simon Willison zadal z mobilu jeden prompt s překlepem a Claude Code for web pak přes 12 hodin stavěl v Rustu rozšíření, které do SQLite přidává dotazovací jazyk SPARQL 1.1. Projekt je technicky působivý. Zároveň ale ukazuje, kde u práce s agenty končí lidská kontrola.

Jeden prompt s překlepem stačil na jedenáct crates v Rustu

Willison pokus popsal 16. října na svém blogu. Šlo mu hlavně o test režimu Ultracode v Claude Code for web. Claude v něm píše JavaScript, který řídí celou síť subagentů. Dokumentace tomu říká dynamic workflows. Zadání znělo zhruba „napiš rozšíření SQLite v Rustu, které implementuje SPARQL a je rychlé, protože čte řádky přímo“. Slovo „delete“ v původním promptu byl podle autora překlep z telefonu.

Agent pracoval přes 12 hodin. Willison pak poslal jediný doplňující prompt: README do každé složky, tutoriál a skript s ukázkovými daty. Vznikl projekt sparqlite s 11 crates v Rustu a tutoriálem o velikosti zhruba 240 kB. Repozitář otevřeně uvádí, že veškerý text i kód napsal jazykový model.

Podle README ukládá sparqlite data RDF do běžných tabulek SQLite a dotazy vyhodnocuje vlastním enginem, ne překladem do jednoho SQL dotazu. Volitelně čte stránky B-stromu přímo ze souboru. Test běžel na 1,6 milionu trojic ze sociální sítě a 1 milionu trojic o produktech. Když engine jen počítá výsledky, je v průměru 3,5× rychlejší než překlad do SQL a 10,6× rychlejší než pyoxigraph. Při vracení celých výsledků je to 2,8× a 6,6×.

Místo čtení kódu nastupují testy, které umí ověřit chování

Willison sám píše, že kód projít nedokáže. I dočíst dokumentaci by ho stálo hodně času. Ptá se proto, jakou cenu má kompletní engine pro SPARQL, který vznikl z rozmaru a kterému nechce věnovat čas.

Agent na tuhle otázku odpověděl jediným způsobem, který měl: důkazy místo recenze. Podle README projde 636 z 639 relevantních testů W3C (99,5 %). Tři selhání připisuje parseru spargebra, na kterém engine stojí. K tomu přidal přes 1 000 testů v Rustu, 50 testů v pytestu a diferenciální fuzzing s přibližně 7,7 milionu porovnání proti záměrně naivní implementaci přepsané přímo ze specifikace.

Pro vývojářské týmy je to užitečný vzorec. U kódu od agenta se kontrola přesouvá z řádků na chování, které jde ověřit. Pomůže standardní sada testů, nezávislá referenční implementace a srovnání s hotovou knihovnou. SPARQL se na takový pokus hodí, protože W3C má hotovou sadu testů. Většina firemních systémů nic podobného nemá.

Testy, benchmarky i kontrolní model psal stejný agent

Tady je slabé místo. Referenční implementaci, testovací runner i benchmarky vytvořil tentýž agent. README sice tvrdí, že runner prošel kontrolou proti nezávislému evaluátoru i mutačním testům. Jenže i to o sobě píše sám model. Čísla o rychlosti pocházejí z jednoho cloudového stroje se 4 vCPU a nikdo je zatím nezopakoval.

Druhá potíž je údržba. Rozšíření čte vnitřní formát souborů SQLite, takže ho může rozbít změna v samotné databázi. Když si reader není jistý, vrací se ke klasickým kurzorům, třeba u databáze v režimu WAL. Kdo by sparqlite nasadil, převezme kód, kterému nerozumí ani jeho zadavatel. Willison ho ostatně uložil do repozitáře research, ne mezi hotové nástroje.

O hodnotě projektu rozhodnou lidé, kteří SPARQL opravdu používají

Prvním signálem bude, jestli sparqlite vyzkouší lidé kolem RDF a sémantického webu. A jestli jejich měření potvrdí čísla z README. Jedno nezávislé zopakování benchmarku má větší váhu než další tisíc testů od stejného agenta.

Druhým signálem je otázka vlastnictví. Agent dnes zvládne za noc dodat celý databázový engine. Rozhodující bude, kdo se k takovému kódu přihlásí ve chvíli, kdy v něm za půl roku někdo najde chybu.

Lilithin verdikt

Willison si překlepem z mobilu objednal databázový engine a ráno dostal 11 crates, skoro čtvrt megabajtu návodu a 7,7 milionu porovnání, které za něj dosvědčují, že to funguje. Teď vlastní stroj s tlustým manuálem a bez mechanika, který by věděl, co je pod kapotou.