Reinventare la ruota ormai costa poco

"Non reinventare la ruota" è una delle prime cose che mi hanno detto sulla programmazione, e per quasi tutta la mia carriera è stato giusto. Scrivere codice era lento, e qualcun altro aveva già speso quelle ore. Installare il suo pacchetto era il modo più economico per prendersele in prestito.

Gli agenti di coding hanno cambiato un lato di questo scambio. Scrivere un pezzo di codice piccolo e ben specificato oggi richiede minuti. L'altro lato, quello che una dipendenza ti costa dopo averla installata, non è cambiato per niente. Quindi il consiglio oggi è sbagliato per un'intera classe di problemi, quelli piccoli e noiosi, che sono la maggior parte dei motivi per cui installiamo pacchetti.

Il consiglio è sempre stato un confronto di prezzi

"Non reinventare la ruota" è una stima: le mie ore per scrivere e debuggare questa cosa valgono più del costo di dipendere dalla versione di qualcun altro. Per dieci anni quella stima è venuta fuori allo stesso modo quasi sempre, e l'ecosistema npm è quello che ottieni quando un'intera industria la segue fino in fondo.

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

Quella era la versione da barzelletta. Quelle serie sono arrivate dopo. Nel marzo 2024 qualcuno ha trovato una backdoor in xz, una libreria di compressione che sta sotto SSH su quasi tutte le macchine Linux. L'attaccante aveva passato circa due anni a contribuire con pazienza, fino a ottenere la fiducia necessaria per pubblicare le release. L'hanno scoperta perché Andres Freund, uno sviluppatore di Microsoft, si è accorto che i login SSH impiegavano mezzo secondo più del dovuto. Nel settembre 2025 una mail di phishing ha preso il controllo dell'account npm del maintainer di chalk e debug, e le versioni pubblicate da lì riscrivevano gli indirizzi dei wallet crypto nel browser. Quei pacchetti vengono scaricati miliardi di volte a settimana, per lo più da gente che voleva l'output colorato nel terminale.

Quanto costa una dipendenza dopo averla installata

Una dipendenza è uno sconosciuto con accesso in scrittura alla tua build di produzione. La fiducia è solo una parte di quello che costa.

Erediti il suo calendario di release. Il suo breaking change diventa il tuo sprint di migrazione, con i suoi tempi. Lo so dall'altro lato: quando abbiamo rilasciato PandasAI 2.0 abbiamo rimosso funzioni su cui la gente contava, per buoni motivi, e ognuna di quelle rimozioni era un conto mandato a persone che non ci avevano mai incontrato.

Con la dipendenza arriva anche la sua astrazione. Un pacchetto è costruito per chiunque potrebbe usarlo, quindi ti ritrovi con la configurazione per trenta casi d'uso quando ne hai uno. Finisci per scriverci intorno degli adattatori, e spesso l'adattatore è più lungo del codice che ti serviva.

E arriva tutto quello da cui dipende. Installi un pacchetto e ne arrivano quaranta, ognuno con un maintainer diverso, un account diverso a cui si può fare phishing, una persona diversa che può annoiarsi o farsi comprare.

Nessuno di questi costi è sceso con l'AI. Semmai sono saliti, perché anche gli agenti che attaccano costano poco, e un account npm è più facile da violare del tuo server di build.

Cosa è cambiato: la ruota piccola è gratis

Quello che è sceso è il prezzo di scrivere la cosa da te, quando la cosa è piccola.

Questo sito è un buon esempio. Il feed RSS è generato da uno script di 76 righe. La sitemap ne ha 75. La versione italiana gira su un file di 63 righe con traduzioni e qualche funzione di supporto, non su un framework di i18n. Per ognuna di queste cose c'era un pacchetto noto che avrei potuto installare, e ognuna l'ho scritta con un agente in meno tempo di quanto ci avrei messo a leggere la documentazione del pacchetto.

In più, posso leggere tutto. Quando la sitemap ha dovuto includere i post in italiano, non ho aperto una issue né cercato un plugin. La modifica è finita in un file che avevo già letto da cima a fondo. Il codice che possiedi e capisci per intero costa meno da cambiare del codice in affitto, e gli agenti hanno reso economico produrre quel tipo di codice.

Dove il consiglio vale ancora

Lo stesso sito dipende ancora da remark per leggere il markdown, da shiki per colorare il codice e da three per la forma 3D in home page. Non riscriverò nessuna di queste, a meno che una non diventi il cuore di quello che sto costruendo.

Il test che uso adesso sono tre domande.

Riesco a descrivere tutto il lavoro in un paragrafo? "Leggi ogni file markdown, prendi titolo e data dal frontmatter, scrivi un feed XML" ci sta. "Fai il parsing del markdown" no, perché il markdown è un decennio di casi limite e di discussioni su cosa significhi una lista annidata. Quando la specifica sta in un paragrafo, un agente la può implementare e io la posso verificare.

La correttezza sta nel codice o negli anni? Date e fusi orari, crittografia, parser, driver di database, qualsiasi cosa tocchi soldi: il valore di quelle librerie sono le segnalazioni di bug che hanno assorbito, non le righe. Un agente ti scriverà un convertitore di fusi orari che sembra perfetto ed è sbagliato per un giorno all'anno in un paese in cui non sei mai stato. Usa la libreria che quella segnalazione l'ha già ricevuta.

Lo leggerei tutto? Se la risposta onesta è no, scriverlo da solo mi dà i costi di una dipendenza senza gli anni di correzioni. Anche il codice generato che non leggi mai è una dipendenza da uno sconosciuto, solo che non ha utenti né issue tracker.

Se la risposta a tutte e tre è sì, scrivilo. Un file piccolo, leggibile e testato, senza dipendenze transitive, batte un pacchetto che non controllerai mai.

Le ruote hanno misure diverse

C'è un caso in cui sostituirei anche una libreria profonda: quando la versione generica è lenta per il mio lavoro specifico. Una bici, un camion e una macchina da corsa hanno tutti le ruote, e nessuno monta le ruote di un camion su una macchina da corsa. La maggior parte delle librerie sono la ruota del camion. Sono costruite per portare il carico di tutti, quindi gestiscono input che non manderai mai ed eseguono controlli che non ti servono. Una libreria CSV deve gestire campi tra virgolette, encoding strani e a capo dentro le celle. Se ogni file che leggi esce dal tuo stesso exporter con le stesse dodici colonne numeriche, un parser scritto esattamente per quel file può saltare gran parte di quel lavoro, e su un percorso critico la differenza può essere grande.

Prima era un progetto che iniziavi solo con l'output di un profiler in mano e una settimana libera. Oggi un agente scrive la versione su misura in un pomeriggio, quindi il rischio si è spostato da "troppo costoso per provarci" a "rilasciato senza controllare". Prima che la versione su misura sostituisca la libreria, voglio tre cose. Primo, un benchmark su dati reali contro l'ultima release della libreria, configurata bene, perché spesso le librerie hanno una modalità veloce che nessuno ha attivato. Secondo, una differenza che conti per qualcuno: 40 millisecondi in meno su un job notturno non valgono un file da mantenere, 40 millisecondi in meno su ogni richiesta forse sì. Terzo, i casi limite della libreria eseguiti contro la mia versione, perché gli input cambiano, e un giorno il mio exporter scriverà una virgola dentro un campo.

Costruisci le cose piccole, dipendi da quelle profonde

A luglio ho scritto che costruire a basso costo ha spostato il valore lontano dal codice. Questo è lo stesso cambiamento visto da dentro una codebase. Quando scrivere costa poco, le parti costose sono quelle che non controlli: i calendari di release degli altri e gli account degli altri.

Così il mio default si è ribaltato. Prima installavo e scrivevo solo quando nessun pacchetto andava bene. Ora scrivo per prima cosa tutto quello che sta in un paragrafo, e installo quando il problema è abbastanza profondo che la storia della libreria vale più del controllo sul codice.

Se pensi che il costo di manutenzione di tutto quel codice piccolo mi raggiungerà fra due anni, mi interessa saperlo, soprattutto se l'hai già pagato. Scrivimi.