Il mio grafico dei contributi GitHub del 2025 sembra appartenere a due sviluppatori diversi. La prima metà dell’anno è quasi vuota. Nella seconda ci sono più di 4.000 commit.
Non avevo improvvisamente più tempo libero. Continuavo a conciliare un lavoro full-time con i side project. Quello che era cambiato era l’attrito tra un’idea e una versione funzionante: avevo iniziato a usare gli strumenti di AI coding in modo molto più serio.
Quel numero, però, va interpretato con precisione. Il numero di commit non è di per sé una metrica di produttività. Quattromila commit non dimostrano quattromila miglioramenti utili, né che il codice fosse buono. Il grafico mostra però un cambiamento reale nel mio modo di lavorare: costruivo, iteravo e arrivavo a versioni funzionanti con molta più continuità di prima.
Il vero collo di bottiglia era l’energia necessaria per iniziare
Nei side project incontravo spesso lo stesso problema: la prima versione utile si trova dietro una quantità di lavoro ordinario. Routing, validazione, script, test, configurazione e cleanup possono consumare lo slancio prima ancora di capire se un’idea merita di essere sviluppata.
In passato rimandavo gli esperimenti quando il primo risultato sembrava richiedere diverse serate di setup. Gli strumenti di AI coding non hanno eliminato quel lavoro, ma hanno ridotto il costo del first pass e accorciato il percorso verso una versione testabile.
Il vantaggio più importante quindi non è stato digitare più velocemente. È stata la riduzione dell’activation energy: più idee arrivavano davvero al punto in cui potevo raccogliere evidenza.
Come è cambiato il mio workflow Node.js
Non ho sostituito il processo di sviluppo con una finestra di chat. Nei side project Node.js ho usato DeepSeek come un secondo paio di mani per task ben delimitati: preparare una prima implementazione, leggere codice non familiare, proporre test, analizzare stack trace, dividere refactor grandi e rivedere assunzioni di deployment.
- Scaffolding: creare la prima versione noiosa di handler, validation, script o test.
- Code reading: seguire il percorso di una request o di un valore prima di modificare.
- Refactoring: trasformare cambiamenti meccanici in piccoli diff facili da controllare.
- Debugging: generare più ipotesi dai log invece di fermarsi alla prima.
- Verification: cercare edge case e regressioni dopo il happy path.
Più erano chiari input, output, vincoli e convenzioni esistenti, più era semplice verificare il risultato. Un task vago produceva più facilmente un’astrazione plausibile ma sbagliata.
Per questo trattavo l’output AI come un candidate patch, non come una soluzione finale. Type checking, test, build e flusso reale erano evidenza; una spiegazione sicura di sé non lo era.
Dove DeepSeek mi ha aiutato di più — e dove no
DeepSeek mi era utile soprattutto perché potevo usarlo ripetutamente su task di programmazione concreti. Potevo chiedere un first pass, scartare una parte, fornire l’errore reale, restringere lo scope e iterare rapidamente.
Non lo presento come un benchmark. Non ho svolto uno studio controllato contro ogni modello concorrente e le lineup cambiano rapidamente. L’affermazione sostenibile è più semplice: DeepSeek si adattava abbastanza bene al mio workflow da farmi usare l’assistenza AI molto più spesso.
Era più forte quando il feedback costava poco: funzione, test ed errore reale. Era meno affidabile quando servivano contesto di prodotto non scritto o trade-off architetturali sottili. In quei casi una risposta fluida poteva far sembrare completa una cattiva assunzione.
L’AI ha cambiato il costo della sperimentazione
Il miglioramento principale non era “l’AI scrive codice, quindi lo sviluppo è automatico”. Molti piccoli pezzi erano semplicemente diventati abbastanza economici da valere un tentativo. Una feature che prima sembrava richiedere troppo setup poteva diventare un prototipo finché l’idea mi interessava ancora.
La distinzione è importante. L’AI ha ridotto il costo per arrivare a una versione testabile. Non ha eliminato architettura, giudizio di prodotto, deployment o correttezza. Un’implementazione generata può essere sbagliata; una build riuscita può fallire a runtime; un prototipo deployato può comunque essere un cattivo prodotto.
Per me il vantaggio pratico era lo slancio. Una volta visto l’intero sistema funzionare, diventava molto più facile continuare a migliorarlo.
Che cosa richiederebbe un benchmark più solido
Per un benchmark riproducibile registrerei versioni esatte dei modelli, task di programmazione fissi, snapshot del repository, prompt, output grezzi, tempo impiegato, patch accettate e rifiutate, review time, risultati dei test e rework.
Misurerei anche più dei commit: tempo dall’idea a una versione verificata, difetti, rollback e lavoro riscritto. Senza questo contesto, 4.000 commit mostrano attività e un cambiamento di comportamento, non qualità del software.
Che cosa è cambiato per me
Il 2025 è stato l’anno in cui ho smesso di vedere ogni side project come una montagna di setup da scalare manualmente. L’AI ha reso la prima versione funzionante abbastanza economica da farmi arrivare più spesso al punto in cui contano davvero le decisioni di prodotto.
È per questo che la seconda metà del mio grafico GitHub appare così diversa. Non perché l’AI mi abbia dato più ore al giorno e non perché ogni riga generata fosse buona. Ha ridotto l’attrito che in passato aveva ucciso alcune idee prima che diventassero reali.
Nel 2026 mi interessa soprattutto la parte meno appariscente dell’equazione: affinare il workflow, misurare la qualità con più serietà e fare in modo che sviluppare più velocemente produca software migliore, non semplicemente più commit.