Simon Willison ha rilasciato sqlite-utils 4.1, il primo dot-release dopo la versione 4.0rc2 scritta quasi interamente con Claude Fable. L’aggiornamento introduce cinque funzionalità minori: l’opzione --code per generare righe da inserire direttamente da codice Python, --type per forzare il tipo di colonna (utile per codici postali che sembrano interi ma vanno conservati come testo), un metodo per eliminare indici, la possibilità di leggere query SQL da standard input, e il supporto per cambiare una tabella da strict a non-strict e viceversa.

Perché ti riguarda: il codice scritto da un agente quattro giorni fa regge il primo ciclo di sviluppo vero. Willison ha usato GPT-5.6 Sol xhigh Codex per implementare le feature, e ha chiesto esplicitamente al modello di testare manualmente il proprio lavoro fuori dai test automatici. Questo giro ha individuato due bug minori che i test unitari non avevano colto. Non è la prima volta che shippa codice assistito dall’AI, ma è la prima volta che la base di codice intera è stata riscritta da un agente e il primo aggiornamento successivo conferma che quella base regge.

Dove guardare: Willison pubblica sempre i transcript completi delle sessioni con Codex. Il prompt più interessante è «use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs», che delega al modello il test esplorativo manuale.

Nel dettaglio

Il contesto

Quattro giorni fa Willison aveva spedito sqlite-utils 4.0rc2, una release candidate scritta quasi interamente da Claude Fable in 37 prompt per circa 149 dollari. Quella riscrittura aveva toccato gran parte della base di codice, aggiungendo migrazioni di schema e altre feature strutturali. La 4.1 è il primo dot-release dopo quella riscrittura, e il test vero di quanto quel codice sia mantenibile.

Le feature nuove

Cinque aggiunte, tutte piccole ma richieste da tempo:

1. --code per insert e upsert: invece di importare dati da file, puoi passare un blocco di codice Python (o il path a un .py) che definisce una funzione rows() o un iterabile di righe. Estende il pattern che sqlite-utils già usava per sqlite-utils convert, dove passi blocchi di codice come argomento CLI.

2. --type per override del tipo di colonna: quando crei una tabella da CSV o TSV, puoi forzare il tipo di una colonna. Utile per codici postali o identificativi che sembrano numeri ma devono restare testo per conservare gli zeri iniziali. Una feature richiesta nel 2019 (issue #131), implementata ora perché Codex l’ha evidenziata come “facile” durante una revisione di tutte le issue aperte.

3. Eliminare indici: nuovo metodo table.drop_index(name) e comando sqlite-utils drop-index, entrambi con opzione ignore=True/--ignore per non fallire se l’indice non esiste.

4. Query da stdin: sqlite-utils query ora accetta - al posto della query SQL, per leggerla da standard input. Permette echo "select * from dogs" | sqlite-utils query dogs.db -.

5. Cambiare strict mode: table.transform() e il comando sqlite-utils transform ora accettano --strict e --no-strict per convertire una tabella da strict a non-strict e viceversa. Ispirato da un post di Evan Hahn che osservava come non esista un ALTER TABLE per cambiare strict mode: il meccanismo transform di sqlite-utils, che copia i dati in una nuova tabella, è esattamente ciò che serve.

Il metodo di lavoro

Willison ha usato GPT-5.6 Sol xhigh tramite Codex. Il prompt più significativo della sessione è stato: «use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs». Delega al modello non solo la scrittura del codice, ma anche il test esplorativo manuale, fuori dai test automatici. Questo giro ha trovato due bug minori che i test unitari non avevano intercettato, e che sono stati corretti nella stessa sessione.

Cosa significa

La 4.0 era stata una riscrittura profonda. La 4.1, spedita quattro giorni dopo, dimostra che quella base di codice regge il primo ciclo di sviluppo vero: l’agente che l’ha scritta non ha lasciato debito tecnico nascosto, e un secondo agente (modello diverso) ha potuto lavorarci sopra senza incidenti. Il codice scritto da un agente shippa, e il codice successivo continua a shippare.

Willison pubblica sempre i transcript completi, permettendo di vedere esattamente quali prompt hanno prodotto cosa. Questo è il filo che stiamo seguendo: agenti che scrivono codice che arriva in produzione, con il costo e i limiti documentati ogni volta.