Ce qui s’est passé. Simon Willison a publié le graphique « Code frequency » de GitHub du projet Datasette, montrant une augmentation visible de l’activité de commit récemment. Willison la relie explicitement à l’arrivée des modèles Opus 4.8, GPT-5.5, Fable 5 et GPT-5.6 Sol : le pic final du graphique correspond au moment où il a commencé à utiliser ces modèles comme coding agents.

Pourquoi tu devrais t’y intéresser. C’est la suite de l’histoire sqlite-utils : comme nous le racontions le 5 juillet, Willison avait livré une release candidate écrite presque entièrement par Claude Fable, documentant coûts et nombre de prompts. Il documente maintenant l’impact à long terme avec une donnée vérifiable : la fréquence de commit sur GitHub, que n’importe qui peut contrôler. Ce n’est pas une impression, c’est une métrique publique qui montre combien de code est modifié au fil du temps. Pour qui se potentialise avec l’IA, c’est un exemple de comment mesurer l’effet de l’adoption : non pas « j’ai l’impression d’aller plus vite », mais « voici le graphique des modifications avant et après ».

Si tu veux essayer. Le graphique « Code frequency » est disponible pour chaque dépôt public sur GitHub : va sur github.com/<utilisateur>/<repo>/graphs/code-frequency et tu verras les ajouts et suppressions par semaine. Sur ton projet, le pic correspond-il à l’adoption des agents ?

En détail

Le contexte : de sqlite-utils à Datasette. Début juillet, Willison avait raconté avoir réécrit une grande partie de sqlite-utils 4.0rc2 avec Claude Fable, en dépensant 149 dollars et en documentant chaque étape. Cette histoire se terminait avec une release candidate fonctionnelle et une première dot-release qui confirmait : le code écrit par l’agent tient en production. Maintenant le récit se déplace sur Datasette, un autre projet open source de Willison, et change d’outil de mesure : non plus le coût d’une seule release, mais la tendance de l’activité de développement au fil du temps.

Ce que dit le graphique. Le graphique « Code frequency » de GitHub montre deux courbes : lignes ajoutées (vert) et lignes supprimées (rouge) pour chaque semaine. Willison signale un pic d’activité à la fin, qui s’aligne temporellement avec l’adoption d’Opus 4.8, GPT-5.5, Fable 5 et GPT-5.6 Sol. C’est un indicateur brut — il compte les lignes de code modifiées, non la qualité ou l’impact des modifications — mais il est public et vérifiable : n’importe qui peut ouvrir le lien et voir le même graphique. Ce n’est pas un benchmark synthétique : c’est le vrai travail sur un projet qui existe depuis 2017 et a un historique de commit constant.

Combien faire confiance. Willison lui-même écrit « out of curiosity » et présente le graphique comme une illustration, pas une démonstration rigoureuse. Le pic pourrait refléter d’autres facteurs : une phase du projet, un refactoring large, des feature qui touchent de nombreux fichiers. On ne sait pas quel pourcentage du code de ce pic a été écrit directement par l’agent et quel pourcentage a été modifié par Willison après la première version. Le graphique ne dit rien sur la qualité : plus de lignes modifiées peuvent signifier plus de valeur livrée, ou plus d’étapes pour arriver au même résultat. Mais comme signal de tendance — « l’activité de développement a augmenté pendant la période où j’ai adopté ces modèles » — c’est une donnée honnête et vérifiable.

Ce qu’il NE faut PAS conclure. Ce n’est pas un test contrôlé : il n’y a pas de groupe de contrôle, pas de baseline normalisée pour la complexité des feature. Tu ne peux pas prendre le graphique et dire « les agents doublent la productivité », parce que tu ne mesures pas la productivité : tu mesures le volume de modifications. Mais c’est un exemple de comment un professionnel documente l’impact sur son propre travail avec des métriques déjà disponibles, au lieu de se fier uniquement aux impressions. Pour qui adopte des agents de coding, la leçon pratique est : regarde tes graphiques de commit, tes temps de fermeture d’issue, le nombre de pull requests ouvertes. Si l’impact existe, il devrait apparaître là, pas seulement dans le récit.