Cos’è successo. Simon Willison ha pubblicato il grafico “Code frequency” di GitHub del progetto Datasette, mostrando un aumento visibile dell’attività di commit nell’ultimo periodo. Willison lo collega esplicitamente all’arrivo dei modelli Opus 4.8, GPT-5.5, Fable 5 e GPT-5.6 Sol: il picco finale del grafico corrisponde a quando ha iniziato a usare questi modelli come coding agents.

Perché ti riguarda. È la continuazione della storia sqlite-utils: come raccontavamo il 5 luglio, Willison aveva spedito una release candidate scritta quasi interamente da Claude Fable, documentando costi e numero di prompt. Ora documenta l’impatto a lungo termine con un dato verificabile: la frequenza di commit su GitHub, che chiunque può controllare. Non è un’impressione, è una metrica pubblica che mostra quanto codice viene modificato nel tempo. Per chi si potenzia con l’AI, è un esempio di come misurare l’effetto dell’adozione: non solo “mi sembra di andare più veloce”, ma “ecco il grafico delle modifiche prima e dopo”.

Se vuoi provarci. Il grafico “Code frequency” è disponibile per ogni repository pubblico su GitHub: vai su github.com/<utente>/<repo>/graphs/code-frequency e vedrai aggiunte e rimozioni per settimana. Sul tuo progetto, il picco corrisponde all’adozione degli agenti?

Nel dettaglio

Il contesto: da sqlite-utils a Datasette. A inizio luglio Willison aveva raccontato di aver riscritto gran parte di sqlite-utils 4.0rc2 con Claude Fable, spendendo 149 dollari e documentando ogni passaggio. Quella storia finiva con una release candidate funzionante e un primo dot-release che confermava: il codice scritto dall’agente regge in produzione. Ora la narrazione si sposta su Datasette, un altro progetto open source di Willison, e cambia strumento di misura: non più il costo di una singola release, ma l’andamento dell’attività di sviluppo nel tempo.

Cosa dice il grafico. Il grafico “Code frequency” di GitHub mostra due curve: righe aggiunte (verde) e righe rimosse (rosso) per ogni settimana. Willison segnala un picco di attività alla fine, che allinea temporalmente con l’adozione di Opus 4.8, GPT-5.5, Fable 5 e GPT-5.6 Sol. È un indicatore grezzo — conta le righe di codice modificate, non la qualità o l’impatto delle modifiche — ma è pubblico e verificabile: chiunque può aprire il link e vedere lo stesso grafico. Non è un benchmark sintetico: è il lavoro reale su un progetto che esiste dal 2017 e ha una storia di commit costante.

Quanto fidarsi. Willison stesso scrive “out of curiosity” e presenta il grafico come un’illustrazione, non una dimostrazione rigorosa. Il picco potrebbe riflettere altri fattori: una fase del progetto, un refactoring ampio, feature che toccano molti file. Non sappiamo quale percentuale del codice in quel picco sia stata scritta direttamente dall’agente e quale sia stata modificata da Willison dopo la prima bozza. Il grafico non dice niente sulla qualità: più righe modificate possono significare più valore consegnato, oppure più passi per arrivare allo stesso risultato. Ma come segnale di tendenza — “l’attività di sviluppo è aumentata nel periodo in cui ho adottato questi modelli” — è un dato onesto e controllabile.

Cosa NON concludere. Questo non è un test controllato: non c’è un gruppo di controllo, non c’è una baseline normalizzata per la complessità delle feature. Non puoi prendere il grafico e dire “gli agenti raddoppiano la produttività”, perché non stai misurando produttività: stai misurando volume di modifiche. Ma è un esempio di come un professionista documenta l’impatto sul proprio lavoro con metriche già disponibili, invece di affidarsi solo a impressioni. Per chi sta adottando agenti di coding, la lezione pratica è: guarda i tuoi grafici di commit, i tuoi tempi di chiusura issue, il numero di pull request aperte. Se l’impatto c’è, dovrebbe comparire lì, non solo nel racconto.