Reinventare la ruota oggi costa pochissimo

"Non reinventare la ruota" è una delle prime cose che mi sono sentito dire quando ho iniziato a programmare, e per quasi tutta la mia carriera è stato un consiglio giusto. Scrivere codice richiedeva tempo, qualcun altro quelle ore le aveva già spese, e installare il suo pacchetto era il modo più economico per farsele prestare.

Gli agenti di coding hanno cambiato uno dei due piatti della bilancia. Oggi scrivere un pezzo di codice piccolo e ben specificato è questione di minuti. L'altro piatto, cioè quanto ti costa una dipendenza dopo che l'hai installata, è rimasto dov'era. Per un'intera classe di problemi il consiglio è quindi diventato sbagliato: quelli piccoli e noiosi, che poi sono il motivo per cui installiamo la maggior parte dei pacchetti.

È sempre stato un confronto tra prezzi

Dietro "non reinventare la ruota" c'è una stima: le ore che passerei a scrivere e a debuggare questa cosa valgono più di quanto mi costi dipendere dalla versione di qualcun altro. Per dieci anni quel calcolo ha dato quasi sempre lo stesso risultato, e l'ecosistema npm è ciò che succede quando un intero settore lo porta alle estreme conseguenze.

Nel marzo 2016 uno sviluppatore ha ritirato left-pad da npm dopo una lite per il nome di un pacchetto. Erano undici righe che riempivano di spazi una stringa a sinistra. Le build si sono rotte in mezzo internet, progetti come Babel e React compresi, perché migliaia di codebase avevano deciso che undici righe non valeva la pena di scriverle.

Quella era la versione comica; quelle serie sono arrivate dopo. Nel marzo 2024 qualcuno ha scoperto una backdoor in xz, una libreria di compressione su cui poggia SSH su quasi tutte le macchine Linux. L'attaccante aveva passato circa due anni a contribuire con pazienza, finché non si era guadagnato abbastanza fiducia da poter pubblicare le release. La cosa è venuta fuori solo perché Andres Freund, uno sviluppatore di Microsoft, aveva notato che i login SSH ci mettevano mezzo secondo di troppo. Nel settembre 2025 è bastata una mail di phishing per prendere il controllo dell'account npm del maintainer di chalk e debug, e le versioni pubblicate da quell'account sostituivano nel browser gli indirizzi dei wallet crypto. Sono pacchetti scaricati miliardi di volte a settimana, perlopiù da gente che voleva soltanto un po' di colore nel terminale.

Quanto costa una dipendenza dopo l'installazione

Una dipendenza è uno sconosciuto con i permessi di scrittura sulla tua build di produzione, e la fiducia è solo una delle voci del conto.

Ti ritrovi addosso i suoi tempi di rilascio: il suo breaking change diventa il tuo sprint di migrazione, quando decide lui. Lo so bene, perché sono stato dall'altra parte. Con PandasAI 2.0 abbiamo tolto funzionalità su cui la gente faceva affidamento, per ottimi motivi, e ognuna di quelle rimozioni era una fattura spedita a persone che non ci avevano mai visto in faccia.

Poi c'è l'astrazione che ti porti in casa. Un pacchetto è pensato per chiunque possa usarlo, per cui ti becchi le opzioni di configurazione per trenta casi d'uso quando a te ne serve uno. Finisci per scriverci attorno degli adattatori, e capita spesso che l'adattatore sia più lungo del codice che ti serviva davvero.

E infine c'è tutto ciò da cui quel pacchetto dipende. Ne installi uno e te ne arrivano quaranta: quaranta maintainer diversi, quaranta account esposti al phishing, quaranta persone che possono stufarsi o farsi comprare.

Con l'AI nessuno di questi costi è sceso. Semmai sono saliti, perché anche attaccare con gli agenti costa poco, ed entrare in un account npm è più facile che entrare nel tuo server di build.

Oggi la ruota piccola non costa niente

Quello che è sceso davvero è il prezzo di scrivertela da solo, quando si tratta di una cosa piccola.

Questo sito ne è un buon esempio. Il feed RSS lo genera uno script di 76 righe, la sitemap ne ha 75, e la versione italiana si regge su un file di 63 righe tra traduzioni e funzioni di supporto, senza nessun framework di i18n. Per ciascuna di queste cose esisteva un pacchetto noto da installare, e le ho scritte tutte con un agente in meno tempo di quanto mi ci sarebbe voluto per leggerne la documentazione.

In più le posso leggere per intero. Quando ho dovuto aggiungere alla sitemap i post in italiano non ho aperto una issue né sono andato a caccia di un plugin: ho modificato un file che conoscevo già riga per riga. Il codice che possiedi e capisci fino in fondo costa meno da cambiare di quello che prendi in affitto, e gli agenti hanno reso economico produrlo.

Dove il consiglio regge ancora

Lo stesso sito continua a dipendere da remark per il parsing del markdown, da shiki per l'evidenziazione del codice e da three per la forma 3D in home page. Non ho intenzione di riscrivere nessuna di queste librerie, a meno che una non diventi il cuore di quello che sto costruendo.

Adesso, prima di decidere, mi faccio tre domande.

Riesco a descrivere tutto il lavoro in un paragrafo? "Leggi ogni file markdown, prendi titolo e data dal frontmatter, genera un feed XML" ci sta. "Fai il parsing del markdown" no, perché il markdown è un decennio di casi limite e di litigi su cosa voglia dire una lista annidata. Se la specifica sta in un paragrafo, un agente può implementarla e io posso verificarla.

La correttezza sta nel codice o negli anni? Date e fusi orari, crittografia, parser, driver di database, tutto ciò che maneggia soldi: il valore di queste librerie sta nelle segnalazioni di bug che hanno assorbito. Un agente ti scriverà un convertitore di fusi orari dall'aspetto impeccabile che sbaglia un giorno all'anno in un paese dove non hai mai messo piede. Meglio usare la libreria che quella segnalazione l'ha già ricevuta.

Me lo leggerei tutto? Se la risposta sincera è no, scrivermelo da solo mi lascia i costi di una dipendenza senza gli anni di correzioni. Anche il codice generato che non leggi mai è una dipendenza da uno sconosciuto, con l'aggravante che non ha utenti né un issue tracker.

Se rispondi sì a tutte e tre, scrivilo. Un file piccolo, leggibile e testato, senza un albero di dipendenze transitive, è meglio di un pacchetto che non verificherai mai.

Le ruote non sono tutte uguali

C'è un caso in cui sostituirei perfino una libreria profonda: quando la versione generica è lenta per il lavoro specifico che devo fare io. Una bici, un camion e un'auto da corsa hanno tutti le ruote, ma a nessuno verrebbe in mente di montare quelle del camion su una macchina da corsa. La maggior parte delle librerie sono ruote da camion: costruite per reggere il carico di chiunque, gestiscono input che non manderai mai e fanno controlli di cui non avrai mai bisogno. Una libreria CSV deve fare i conti con campi tra virgolette, encoding strani e a capo dentro le celle. Se però ogni file che leggi esce dal tuo stesso exporter, sempre con le stesse dodici colonne numeriche, un parser scritto apposta per quel formato può saltare buona parte di quel lavoro, e su un percorso critico la differenza può essere notevole.

Un tempo era un progetto da avviare solo con il report di un profiler in mano e una settimana libera. Oggi un agente ti scrive la versione su misura in un pomeriggio, e il rischio è passato da "troppo caro per provarci" a "messo in produzione senza controllare". Prima di sostituire la libreria con la versione su misura pretendo tre cose. La prima è un benchmark su dati reali contro l'ultima release della libreria, configurata come si deve, perché spesso le librerie hanno una modalità veloce che nessuno si è preso la briga di attivare. La seconda è una differenza che conti per qualcuno: 40 millisecondi risparmiati su un job notturno non giustificano un file in più da mantenere, 40 millisecondi su ogni richiesta forse sì. La terza è far girare sulla mia versione i casi limite della libreria, perché gli input cambiano, e prima o poi il mio exporter scriverà una virgola dentro un campo.

Le cose piccole scrivile, da quelle profonde dipendi

A luglio ho scritto che, ora che costruire costa poco, il valore non sta più nel codice. Questo è lo stesso spostamento, visto dall'interno di una codebase. Quando scrivere costa poco, le parti care sono quelle che non controlli: i tempi di rilascio degli altri e gli account degli altri.

E così il mio default si è capovolto. Prima installavo, e scrivevo solo se non trovavo un pacchetto adatto. Adesso scrivo subito tutto ciò che sta in un paragrafo, e installo quando il problema è abbastanza profondo da rendere la storia della libreria più preziosa del controllo sul codice.

Se pensi che fra due anni il conto della manutenzione di tutto questo codice piccolo mi arriverà comunque, mi piacerebbe sentirlo, soprattutto se tu l'hai già pagato. Scrivimi.