«Funziona. Adesso non la tocco più.»
È la frase che segue quasi sempre la prima applicazione costruita con l’AI. E il ragionamento è sensato: se va, perché metterci le mani?
Con un tavolo funziona così. Lo costruisci, e fra dieci anni è lo stesso tavolo.
Un programma somiglia di più a un’auto. La lasci ferma un anno in garage e non le hai fatto niente. Però la batteria è a terra, la revisione è scaduta, e nel frattempo hanno cambiato il senso unico sotto casa.
Un’applicazione invecchia perché cambia tutto quello che ha intorno.
Di cosa è fatta
Quando chiedi all’AI di costruirti un programma, lei non scrive tutto da zero.
Prende dei pezzi già pronti, scritti da altri e messi a disposizione di tutti, e li monta insieme. Si chiamano librerie. C’è quella che gestisce le date, e quella che parla con il database.
È il modo normale di lavorare. Lo fanno tutti i programmatori, da sempre.
Un’applicazione anche piccola ne usa centinaia. E ciascuna, a sua volta, si appoggia ad altre.
Tu non ne hai scelta nessuna. Le ha scelte l’AI, mentre tu le descrivevi cosa doveva fare il pulsante.
Quando in una libreria si scopre una falla
Succede di continuo, ed è normale anche questo.
Qualcuno trova un difetto di sicurezza in una libreria molto usata. Chi la mantiene pubblica una versione corretta. Chi segue queste cose aggiorna.
La tua applicazione, intanto, resta con la versione di prima. A te non arriva nessun avviso. E sullo schermo non cambia niente, perché il programma funziona esattamente come ieri.
Solo che da quel giorno il difetto è pubblico, descritto per filo e per segno. E c’è chi passa le giornate a cercare, con programmi automatici, chi non ha ancora aggiornato.
È lo stesso meccanismo dei plugin di WordPress, che ho raccontato in Come bucano un sito WordPress. Lì almeno il pannello ti mostra il numerino rosso degli aggiornamenti. Un’applicazione su misura quel numerino non ce l’ha.
Gli strumenti per saperlo esistono, e molti sono gratuiti. Il servizio dove sta archiviato il codice può controllare le librerie e avvisarti quando una ha un problema noto.
Qualcuno però deve averlo attivato. E qualcuno deve leggere quegli avvisi.
Aggiornare, e ogni quanto
Aggiornare una libreria a volte è un attimo. A volte la versione nuova funziona in modo un po’ diverso, e un pezzo del tuo programma smette di andare.
Per questo c’è una regola che vale più di tutte: poco e spesso.
Chi aggiorna ogni mese fa piccoli passi, e se qualcosa si rompe sa dov’è il problema. Chi aspetta due anni si trova davanti un salto. A quel punto ogni aggiornamento è un rischio, quindi si rimanda ancora.
Ad esempio. Su un server che mi hanno affidato c’era uno strumento rimasto 204 versioni indietro. Nessuno lo aveva deciso: semplicemente, prima, quel controllo non l’aveva mai fatto nessuno.
Prima di aggiornarlo ho controllato una per una le novità che potevano rompere qualcosa, e ho fatto una copia. Poi è andato liscio.
Ma il particolare interessante è un altro. Nei registri di quello strumento, a ogni avvio, c’era una riga che diceva che la versione del database non era più supportata.
Era lì da mesi. L’avviso c’era, mancava qualcuno che lo leggesse.
I servizi collegati cambiano, in silenzio
Quasi ogni applicazione parla con qualcun altro. Il servizio dei pagamenti, quello delle email, il CRM, un modello di intelligenza artificiale.
Quel dialogo passa da un’API, che è lo sportello attraverso cui due programmi si scambiano i dati.
Gli sportelli cambiano. Un campo viene rinominato. Una versione vecchia viene ritirata. Una chiave scade dopo un anno. Un limite di utilizzo viene abbassato.
Chi gestisce il servizio di solito avvisa, mesi prima, con un’email. All’indirizzo con cui è stato aperto l’account.
Qual è il problema? Che quell’indirizzo spesso è di chi ha fatto la prima installazione, o è una casella che nessuno apre.
Con l’AI c’è un caso in più. Se la tua applicazione usa un modello di intelligenza artificiale, sta chiamando una versione precisa di quel modello. Le versioni vengono ritirate, con una data annunciata. Quel giorno la funzione smette di rispondere.
«Non si è rotto niente»
Questa è la parte più insidiosa, ed è il motivo per cui scrivo l’articolo.
Quando si rompe una cosa che si vede, qualcuno telefona. Lo schermo bianco fa rumore.
I guasti di cui parlo non fanno rumore.
Il cliente compila il modulo e legge «grazie, ti ricontattiamo». Il dato doveva finire nel CRM, e non ci arriva più. Oppure l’applicazione mostra i numeri di ieri, perché l’aggiornamento notturno si è fermato.
Da fuori è tutto a posto. Te ne accorgi dopo settimane, quando un cliente chiede perché nessuno l’ha richiamato.
Mi è capitato un collegamento in cui l’errore stava nel servizio di un terzo, due passaggi più in là. Il nostro pezzo era a posto. Quello subito dopo, pure. Per trovarlo è servito leggere la risposta completa che tornava indietro, invece di fermarsi al fatto che «non va».
È parente stretto di quello che ho raccontato in Analytics installato, ma sta misurando qualcosa?: uno strumento che non fa più il suo lavoro, e nessun segnale che te lo dica.
Come si tiene d’occhio
Servono poche cose, e la più importante è una persona.
Un controllo che prova il giro intero. Ogni giorno un invio di prova passa dal modulo fino al CRM, e se non arriva parte un avviso. Si costruisce con uno strumento di automazione come n8n o Make.
Un indirizzo email vero su tutti gli account dei servizi collegati. Una casella che qualcuno legge.
Gli avvisi sulle librerie attivati, e mandati a quella stessa casella.
Un appuntamento fisso. Una volta al mese, mezz’ora.
In quella mezz’ora puoi farti aiutare dall’AI che ha costruito il programma. Le domande sono queste.
Quali librerie di questo progetto hanno falle di sicurezza note, e quali aggiorneresti subito? Cosa rischia di rompersi se le aggiorno? Quali servizi esterni usa questa applicazione, e ce n’è qualcuno che ha annunciato modifiche o ritiri? Cosa succede se uno di questi servizi non risponde: l’utente lo vede, e io vengo avvisato?
L’ultima è la più utile. Quasi sempre la risposta è «no», ed è lì che si mette mano.
Quanto costa
Meno di una volta, e più di zero.
Le stime che si trovano online parlano di un 15 o 20 per cento del costo iniziale ogni anno, per la manutenzione di un’applicazione. Le ho riprese in Quanto costa farsi fare un’app nel 2026.
Con l’AI la parte manuale si è ridotta parecchio. Un aggiornamento che prendeva una giornata adesso prende un’ora.
Resta il fatto che qualcuno deve farlo partire. L’AI non si sveglia il primo del mese per controllare le tue librerie.
E conta dove gira l’applicazione. Su una piattaforma una parte di questo lavoro la fa la piattaforma, e ne ho parlato in Lovable o Claude Code, se non sei un programmatore. Su un server tuo è tutto in carico a te, come ho scritto in «Mi sono preso un VPS e Claude fa tutto da solo».
In tutti e due i casi le librerie dentro la tua applicazione restano tue.
Cosa farei io
Faccio l’elenco dei servizi esterni a cui l’applicazione è collegata, e per ognuno controllo a quale indirizzo arrivano gli avvisi.
Attivo il controllo automatico sulle librerie.
Costruisco la prova giornaliera del giro più importante, quello da cui dipendono i clienti o i soldi.
Metto in calendario la mezz’ora mensile, con le quattro domande.
E decido chi lo fa. Se nessuno ha quel compito, fra sei mesi l’applicazione funzionerà ancora. O almeno così sembrerà.
Se hai un’applicazione in uso da qualche mese e nessuno l’ha più guardata, sentiamoci mezz’ora.
