Simon Willison a livré sqlite-utils 4.1, la première mise à jour mineure après la version 4.0rc2 écrite presque entièrement avec Claude Fable. Cette mise à jour introduit cinq petites fonctionnalités : l’option --code pour générer des lignes à insérer directement depuis du code Python, --type pour forcer le type de colonne (utile pour les codes postaux qui ressemblent à des entiers mais doivent rester du texte), une méthode pour supprimer des index, la capacité de lire des requêtes SQL depuis l’entrée standard, et le support pour basculer une table de strict à non-strict et inversement.

Pourquoi ça t’intéresse : le code écrit par un agent il y a quatre jours tient le premier cycle de développement réel. Willison a utilisé GPT-5.6 Sol xhigh Codex pour implémenter les fonctionnalités, et a explicitement demandé au modèle de tester manuellement son travail en dehors des tests automatisés. Cette fois, il a repéré deux bugs mineurs que les tests unitaires n’avaient pas attrapés. Ce n’est pas la première fois qu’il livre du code assisté par l’IA, mais c’est la première fois que toute la base de code a été réécrite par un agent et la première mise à jour suivante confirme que cette base tient bon.

À regarder : Willison publie toujours les transcriptions complètes de ses sessions avec Codex. Le prompt le plus intéressant est « use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs », qui confie au modèle le test exploratoire manuel.

En détail

Le contexte

Il y a quatre jours, Willison avait livré sqlite-utils 4.0rc2, une version candidate écrite presque entièrement par Claude Fable en 37 prompts pour environ 149 dollars. Cette réécriture avait touché une grande partie de la base de code, ajoutant des migrations de schéma et d’autres fonctionnalités structurelles. La 4.1 est la première mise à jour mineure après cette réécriture, et le vrai test pour savoir si ce code est maintenable.

Les nouvelles fonctionnalités

Cinq ajouts, tous petits mais demandés depuis longtemps :

1. --code pour insert et upsert : au lieu d’importer des données depuis un fichier, tu peux passer un bloc de code Python (ou le chemin vers un .py) qui définit une fonction rows() ou un itérable de lignes. Cela étend le modèle que sqlite-utils utilisait déjà pour sqlite-utils convert, où tu passes des blocs de code en argument CLI.

2. --type pour override du type de colonne : quand tu crées une table depuis un CSV ou TSV, tu peux forcer le type d’une colonne. Utile pour les codes postaux ou identifiants qui ressemblent à des nombres mais doivent rester du texte pour conserver les zéros initiaux. Une fonctionnalité demandée en 2019 (issue #131), implémentée maintenant parce que Codex l’a signalée comme « facile » lors d’un examen de tous les problèmes ouverts.

3. Supprimer des index : nouvelle méthode table.drop_index(name) et commande sqlite-utils drop-index, toutes deux avec l’option ignore=True/--ignore pour ne pas échouer si l’index n’existe pas.

4. Requêtes depuis stdin : sqlite-utils query accepte maintenant - au lieu de la requête SQL, pour la lire depuis l’entrée standard. Permet echo "select * from dogs" | sqlite-utils query dogs.db -.

5. Changer le mode strict : table.transform() et la commande sqlite-utils transform acceptent maintenant --strict et --no-strict pour convertir une table de strict à non-strict et inversement. Inspiré par un article d’Evan Hahn qui remarquait qu’il n’existe pas de ALTER TABLE pour changer le mode strict : le mécanisme transform de sqlite-utils, qui copie les données dans une nouvelle table, c’est exactement ce qu’il faut.

La méthode de travail

Willison a utilisé GPT-5.6 Sol xhigh via Codex. Le prompt le plus significatif de la session a été : « use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs ». Il confie au modèle non seulement l’écriture du code, mais aussi le test exploratoire manuel, en dehors des tests automatisés. Cette fois, il a trouvé deux bugs mineurs que les tests unitaires n’avaient pas interceptés, et qui ont été corrigés dans la même session.

Ce que ça signifie

La 4.0 a été une réécriture profonde. La 4.1, livrée quatre jours plus tard, démontre que cette base de code tient le premier cycle de développement réel : l’agent qui l’a écrite n’a pas laissé de dette technique cachée, et un second agent (modèle différent) a pu travailler dessus sans incident. Le code écrit par un agent arrive en production, et le code suivant continue d’arriver en production.

Willison publie toujours les transcriptions complètes, permettant de voir exactement quels prompts ont produit quoi. C’est le fil que nous suivons : des agents qui écrivent du code qui arrive en production, avec le coût et les limitations documentés à chaque fois.