sqlite-utils 4.0 napisany głównie przez Claude Fable za 149 dolarów

Simon Willison wykorzystał Claude Fable do przygotowania stabilnej wersji 4.0 swojej biblioteki sqlite-utils, wydając na to około 149,25 dolara. Proces ten ujawnił kilka krytycznych błędów, które mogłyby spowodować utratę danych w produkcyjnych zastosowaniach. Pełny opis procesu autor opublikował na swoim blogu.

Kluczowe wnioski

• Claude Fable znalazł 5 krytycznych błędów kategoryzowanych jako „release blockers”, w tym poważny problem z metodą delete_where() powodujący utratę danych.
• Cały proces zajął 37 promptów, 34 commity i zmiany w 30 plikach (+1,321 -190 linii kodu).
• Biblioteka sqlite-utils 4.0 wprowadza nowy model transakcji, gdzie każda metoda zapisująca do bazy automatycznie tworzy własną transakcję i zatwierdza zmiany.
• Willison dodatkowo wykorzystał GPT-5.5 do dodatkowej weryfikacji pracy Claude'a, co pozwoliło znaleźć kolejne problemy.
• Koszt całego procesu wyniósł około 149,25 dolara za użycie Claude Fable w ramach subskrypcji Max.

Najpoważniejszy błąd w kodzie

Najgorszym problemem okazała się metoda delete_where(), która nie zatwierdzała transakcji i „zatruwała” połączenie z bazą danych. W przeciwieństwie do metody delete(), która prawidłowo opakowywała operację w transakcję, delete_where() wykonywała DELETE bez odpowiedniego wrappera atomic().

Błąd powodował, że połączenie pozostawało w stanie in_transaction=True, co sprawiało, że wszystkie kolejne operacje atomic() wykorzystywały mechanizm savepoint i nigdy nie zatwierdzały zmian. W praktyce oznaczało to, że po zamknięciu i ponownym otwarciu bazy danych wszystkie operacje wykonane po delete_where() były tracone.

Nowy model transakcji

Biblioteka sqlite-utils 4.0 wprowadza znaczące zmiany w obsłudze transakcji. Każda metoda zapisująca do bazy — insert(), upsert(), update(), delete(), delete_where(), transform(), create_table(), create_index(), enable_fts() — automatycznie tworzy własną transakcję i zatwierdza ją przed zakończeniem.

Użytkownicy nie muszą już wywoływać commit() ani zamykać bazy danych, aby utrwalić zmiany. Transakcje wymagają uwagi tylko w dwóch przypadkach: gdy chcemy zgrupować kilka operacji razem (używając db.atomic()) lub gdy sami zarządzamy transakcją za pomocą db.begin().

Weryfikacja przez konkurencyjny model

Interesującym aspektem procesu była dodatkowa weryfikacja przez GPT-5.5. Willison przyznał, że wcześniej uważał ideę recenzowania pracy jednego modelu przez drugi za „absurdalną i dziwnie przesądną”, ale praktyka pokazała jej skuteczność. GPT-5.5 znalazł dwa dodatkowe problemy priorytetowe, w tym nieoczekiwane efekty uboczne w metodzie db.query().

Proces pokazuje rosnące możliwości AI w rozwoju oprogramowania oraz wartość wykorzystania różnych modeli do wzajemnej weryfikacji kodu. Za stosunkowo niewielką kwotę Willison otrzymał kompleksową analizę i implementację poprawek, które znacząco poprawiły jakość biblioteki przed stabilnym wydaniem.