Ne oldu?
Simon Willison, 12 Ağustos 2026 tarihinde kendi geliştirdiği sqlite-utils kütüphanesinin veritabanı bağımsız (database agnostic) bir versiyonu olan alchemy-utils 0.1a0 alfa sürümünü duyurdu. Willison, projeyi "sabah duş projesi" olarak nitelendirerek görevi Codex ve GPT-5.6 Sol Ultra modeline verdiğini belirtti.
Görev tanımı, sqlite-utils'teki insert, upsert, insert_all, upsert_all, create ve update metotlarıyla tablo içgözlem özelliklerinin aynısını sunan ama SQLAlchemy üzerine kurulu, çoklu veritabanı motoruyla çalışan bir kütüphane oluşturmaktı. Willison, birkaç takip komutunun projeyi alfa olarak yayınlanabilecek olgunluğa getirdiğini aktardı.
Neden önemli?
Proje, kırmızı/yeşil test güdümlü geliştirme (TDD) ve pytest kullanılarak inşa edildi; referans olarak Willison'ın mevcut sqlite-utils ve django-sql-dashboard depoları kullanıldı. Kütüphane, PostgreSQL, SQLite ve DuckDB veritabanlarına karşı test edildi.
Willison, örnek olarak PostgreSQL'de barındırdığı blog veritabanındaki bir tablonun satırlarını tek bir uvx komutuyla listeleyebildiğini gösterdi. Ayrıca San Francisco'daki ağaçların listesini içeren bir CSV dosyasını, şeması otomatik oluşturulan bir DuckDB veritabanına aktarabildi.
- Kütüphane SQLAlchemy tabanlı olduğu için PostgreSQL, SQLite ve DuckDB dahil birden fazla veritabanı motorunu destekliyor.
- İlk CSV aktarımı yaklaşık bir saat sürerken, Codex tarafından yapılan optimizasyon sonrası bu süre 35 saniyeye indi.
- Proje uv init ile başlatıldı ve git deposunda erken ve sık commit prensibiyle geliştirildi.
Sırada ne var?
Willison, alchemy-utils'in şu anda alfa aşamasında olduğunu belirtti ve projeyi geliştirmeye devam edeceğine dair bir işaret verdi. Kütüphanenin gelecekte sqlite-utils'in tüm temel özelliklerini kapsayıp kapsamayacağı veya ek veritabanı motorlarının desteklenip desteklenmeyeceği henüz netleşmedi.
Asıl sayı: çalışan kod ile kullanılabilir kod arasındaki fark
Deneyin en çok konuşulan yanı kütüphanenin birkaç komutla ortaya çıkması oldu ama en öğretici rakam başka: ilk sürüm doğru çalışıyordu ve aynı işi yaklaşık bir saatte yapıyordu. Optimizasyondan sonra 35 saniye. Yani ilk çıktı ile kullanılabilir çıktı arasında yüz katına yakın bir performans farkı vardı ve bu fark testlerden geçen bir koda rağmen duruyordu.
Bu, model üretimi kodun az bildirilen bir özelliği. Doğruluk denetimi kolay — testler ya geçer ya geçmez. Performans denetimi ise ancak gerçek veriyle, gerçek boyutta çalıştırınca ortaya çıkıyor. Willison'ın deneyinde bunu yakalayan şey bir test değil, San Francisco ağaç listesini gerçekten aktarmaya kalkması oldu.
Bu deney neyi gösteriyor, neyi göstermiyor
Koşullar alışılmadık biçimde elverişliydi. Willison, taklit edilecek API'yi kendisi tasarlamıştı; modele referans olarak kendi iki deposunu verebiliyordu; kırmızı/yeşil test disiplinini baştan uyguluyordu ve çıktının doğru olup olmadığını anlayacak uzmanlığa sahipti. Bu dördü aynı anda elinde olmayan biri aynı süreçten aynı sonucu çıkarmayabilir.
Paylaşılmayanlar da var: aynı kütüphaneyi elle yazmanın ne kadar süreceğine dair bir karşılaştırma, alfa sürümünde kalan hata sayısı, ya da üretimde kullanıldığında ne olacağına dair bir veri yok. Willison'ın kendisi de sürümü alfa olarak etiketliyor. Yani ortada bir üretkenlik ölçümü değil, iyi belgelenmiş tek bir vaka var — ve değerinin çoğu, komut geçmişinin baştan sona yayımlanmış olmasından geliyor.