Non c'è più tempo per capire quello che stiamo creando
Ho finito da poco un nuovo POC e già mentre lo scrivevo mi chiedevo se non fosse da rifare. Niente fa più in tempo a sedimentare e ormai faccio fatica a capire davvero quello che costruisco.

Il dubbio arriva dopo pochi passi
Qualche settimana fa ho tirato su un nuovo POC: un agente che si comporta come un sommelier della birra, con un RAG dietro che gli dà le risposte. L’ho finito, funziona decentemente e me lo sono tenuto, quindi non vi parlerò del solito progetto iniziato e buttato via. È la storia di un dubbio arrivato troppo presto: quello di doverlo rifare, che mi è venuto quando ero ancora a metà.
Avevo scelto le tecnologie con una certa cura: tutto in locale con Ollama e llama3.1, LanceDB come indice vettoriale, un RAG classico con un system prompt che tiene il modello agganciato alle fonti. Poi, nel giro di pochi giorni: un paper, “Don’t Retrieve, Navigate”, che proponeva di saltare il retrieval e far navigare l’agente direttamente tra i documenti, processo che funziona meglio proprio quando i documenti sono pochi e ben organizzati, come i miei; graphify, che trasforma una cartella di documenti in un grafo navigabile invece che in una lista di vettori; l’ultimo Qwen open, che gira in locale come llama3.1 e sui benchmark lo fa sembrare di un’altra epoca. Nessuna di queste tre cose modificava il risultato che avrebbe prodotto il mio progetto, semplicemente io, mentre lo scrivevo, avevo già la sensazione di guardare qualcosa di vecchio.
Tra l’altro ho una nota sul telefono che si chiama “da guardare”. Ci finiscono le cose che mi riprometto di approfondire con calma, che ovviamente non arriva mai. A un certo punto ho smesso di considerarla una lista di cose da fare (non l’ho mai svuotata, non ci riuscirei) e ho iniziato a considerarla per quello che è: un contatore di quanto sono indietro, aggiornato ogni sera.
Il ciclo si è accorciato
Che nel nostro mestiere bisogna aggiornarsi o si resta indietro non è una novità. Ho visto passare framework, paradigmi e mode a sufficienza. Ogni volta ci si è adattati. La differenza è che prima il giro durava abbastanza da farci stare dentro un progetto intero: sceglievi una cosa, ci lavoravi per settimane, vedevi quali erano i suoi punti deboli e alla fine ti creavi una tua opinione. La volta dopo sceglievi meglio.
Il termine di paragone che ho sempre avuto per capire quando una tecnologia era “finita” è la riscrittura. Un software si riscriveva dopo anni: era in produzione da un pezzo, aveva accumulato patch su patch e modifiche incrementali che lo avevano reso faticoso da manutenere mentre nel frattempo erano uscite librerie e versioni troppo distanti da quelle su cui era nato. Arrivati lì, la domanda “lo rifacciamo?” era legittima: bisognava valutare quanto costava ogni modifica, quanto ci si metteva a rilasciare e quali erano le cose che ormai non si riuscivano più a fare.
Oggi quella domanda mi si presenta mentre sto ancora scrivendo la prima release. Non su un codice appesantito da anni di manutenzione, ma su una cosa che nessuno ha mai messo in produzione e che non ha un solo giorno di debito tecnico alle spalle. Il ragionamento è lo stesso di sempre, è la scala dei tempi che è impazzita: il momento della riscrittura si è sovrapposto a quello della scrittura. In mezzo non c’è più lo spazio in cui mi creavo la mia opinione.
La sindrome dell’impostore, versione senior
Dopo un po’ di anni di mestiere ti aspetti di avere il tuo bagaglio di conoscenze. Non sai tutto, ma sai abbastanza da non sentirti mai del tutto spiazzato. Ecco, non basta più. Mi capita sempre più spesso di essere in una conversazione in cui qualcuno nomina una cosa che non ho mai sentito e di fare la faccia di chi la conosce mentre penso “stasera me la cerco”. Poi finisce nella nota “da guardare” e sappiamo come va a finire.
La parte strana è che è proprio l’esperienza a farmelo pesare. Chi inizia adesso non sa di non sapere e non si pone nemmeno il problema. Io invece ho ben chiaro cosa vuol dire conoscere una cosa per davvero. Proprio per questo vedo bene quanto ne sono lontano su gran parte dei nuovi strumenti che sto usando.
In aggiunta, negli ultimi anni, è cambiato anche il modo in cui le informazioni ti arrivano addosso. Dieci anni fa, per sapere che era uscito qualcosa di nuovo, dovevi andartelo a cercare: un blog che seguivi, una conferenza, un collega che ne aveva sentito parlare da qualche parte. Se non lo cercavi non lo sapevi. Forse si campava bene lo stesso. Oggi non cerco più niente, mi arriva tutto addosso mentre scorro il telefono e ogni cosa che passa è il promemoria di qualcosa che non so. Non sono sicuro che oggi escano più strumenti di dieci anni fa, ma sono sicuro che prima potevo tranquillamente non accorgermene. Adesso no.
Mi consolo pensando che anche gli altri non sono aggiornati. Per qualche minuto funziona. Chi sembra esperto magari ha letto un thread mezz’ora prima di me e ha messo su una demo che gira sul suo portatile; come si comporti quel codice in un progetto vero, con i vincoli veri e con altre persone che ci dovranno mettere le mani, non lo sa nemmeno lui. Far vedere che una cosa funziona è diventato facile, ma per capire se regge in produzione ci si mette lo stesso tempo di dieci anni fa.
Le cose non fanno in tempo a sedimentare
Quello che so davvero l’ho imparato tutto nello stesso modo: usando una tecnologia abbastanza a lungo da vederla rompersi e poi diventare obsoleta. Non nella demo, ma in produzione, magari risolvendo un bug di venerdì sera con qualcuno che aspetta. Le cose che so spiegare bene le so spiegare perché a un certo punto mi sono esplose in mano e ho dovuto capire il perché.
Quel passaggio non si può comprimere. Non è sufficiente il tempo per documentarsi, è necessario il tempo per sperimentare: settimane in cui una scelta mostra i suoi pregi e i suoi difetti e ti costringe eventualmente a tornarci sopra. È la cosa che distingue un senior da uno sviluppatore meno esperto che ha solo letto la documentazione, ed è esattamente quello che non posso più permettermi di fare.
Oggi, prima che una tecnologia mostri i suoi difetti, è già stata sostituita con la successiva. Il risultato è uno strato sottilissimo di tutto e uno strato spesso di quasi niente. Le cose le so fare e per consegnare un progetto è sufficiente. Ma se qualcuno mi chiedesse di spiegare perché una certa scelta funziona, o ancora peggio perché NON funziona, in parecchi casi farei scena muta. Da quando il codice lo scrive un coding agent la distanza tra quello che so e quello di cui mi devo fidare è aumentata: leggo, provo e approvo, ma non passo più dagli errori, che erano il modo in cui capivo. E questa è una delle cose che faccio più fatica ad accettare.
A luglio, nel post in cui raccontavo di aver ritrovato l’entusiasmo, scrivevo che il rischio era per chi parte adesso: se salti la fatica, salti anche l’apprendimento. Era facile da accettare, perché era un rischio degli altri. La cosa di cui mi sono reso conto è che in realtà riguarda anche me, solo che nel mio caso si vede meno: ho le basi sotto, quindi il buco è più piccolo.
Conclusioni
Una strategia non ce l’ho. Una direzione forse sì. Viene da una cosa che avevo già scritto nel post di Luglio: con gli anni mi sono spostato dal come sono fatte le cose al valore di quello che costruisco. Se ci credo davvero, la conseguenza è scomoda ma accettabile: conta il risultato, non aver preso la strada migliore con lo strumento più efficiente del mese.
Sempre lì dicevo di aver fatto pace con l’idea di lasciare il volante sul come, tenendomi la destinazione. Non avevo messo in conto che il come include anche il pretendere di averlo fatto bene. Rinunciare a quello è parecchio più difficile che rinunciare a scrivere il codice riga per riga. Eppure è probabilmente la parte su cui devo mollare: se una cosa funziona, sta in piedi e la so mantenere, che fosse pure la soluzione ottimale è una domanda che mi sto facendo soltanto io.
Il fatto è che mi dà fastidio, è la mia forma mentis. Un fastidio che non passa nemmeno se so che mollare è la scelta razionale. Mi sono costruito dentro l’idea che capire come funzionano le cose sia il mestiere, non un extra da concedersi quando avanza tempo. Lasciarlo andare è come arrendersi, anche quando i risultati dicono il contrario.
Costruire cose nuove, comunque, mi diverte come prima, forse di più: quella parte non si tocca. È cambiato il rapporto con quello che costruisco e non ho ancora deciso se questo fastidio sia un residuo da smaltire o l’unica cosa sensata che mi è rimasta da ascoltare.
Voi come ve la cavate? Di tutto quello che avete usato quest’anno, quanto sapreste spiegare davvero a qualcuno che vi chiede il perché? O avete smesso di provarci anche voi?
Commenti
I commenti sono moderati: li leggo io prima che diventino pubblici. Il riquadro si carica solo se lo chiedi tu, così finché non premi il pulsante nessuna richiesta parte verso servizi esterni.