Quando Walter, sviluppatore in una delle due aziende che si contendevano lo strano mercato delle poesie per celebrazioni e delle fiction a esse ispirate, si ritrovò a dover migrare da Python 2 a Python 3, l’umore in ufficio era tutt’altro che festoso. L’ultima ondata di licenziamenti aveva risparmiato lui, ma falciato la fiducia di chi restava. «Nessuno era disposto a farsi le nottate necessarie per sistemare quel 20 percento di macchine che si rifiutava di collaborare», ha raccontato Walter a The Register. Così, in un mattino alimentato da caffè pessimo e dall’ennesima intervista rimandata, ebbe un’idea che lui stesso definisce terribile: puntare Python 3 direttamente a Python 2, con un semplice collegamento simbolico.

ln -s /usr/bin/python2 /usr/bin/python3

Aspettava fuoco, allarmi, email infuocate. Invece funzionò. Silenziosamente. Così bene che nessuno se ne accorse. E Walter, con un misto di sollievo e autoironia, lasciò nel codice un commento che è un monumento alla sindrome dell’impostore: «Yeah, yeah, yeah. I know, I know. At least I was mostly sober so it can’t be THAT dumb!»

La storia sarebbe finita lì, se non fosse che otto anni dopo, ormai altrove, Walter ricevette su LinkedIn un messaggio da un ex collega: l’ultimo aggiornamento Linux era finalmente completo. E con esso avevano scovato il symlink, sopravvissuto alla migrazione dallo script artigianale a un playbook Ansible. Una reliquia rimasta sepolta nell’infrastruttura per quasi un decennio.

Questo episodio, sebbene umoristico, contiene una verità scomoda su ogni architettura on-premise, soprattutto quando è gestita da squadre sotto organico e stressate. Le scorciatoie tecniche — i «funziona, non toccare» — si depositano come strati geologici. Finché il sistema regge, diventano invisibili. Ma l’automazione (Ansible, in questo caso) non le elimina: le eredita, le riproduce e, a volte, le rende più difficili da scovare, perché inglobate in una configurazione dichiarativa che nessuno mette più in discussione.

Chi oggi orchestra pipeline di LLM in self-hosting conosce bene la tentazione. Un mismatch tra versioni di librerie, un driver CUDA che non si allinea con il runtime containerizzato, una quantization del modello che funziona solo se teniamo attivo un flag deprecato. La soluzione rapida è a portata di commit: un symlink, un alias, un workaround documentato a metà. In ambienti dove si ha il controllo totale, e quindi anche la responsabilità totale, il debito tecnico non si paga mai da solo. Sopravvive finché qualcuno, magari durante una migrazione importante, lo disseppellisce.

Il caso di Walter è emblematico per un altro motivo: il confine tra ciò che è sostenibile e ciò che è precario non è sempre netto. Il suo trucco ha retto su un parco macchine eterogeneo per otto anni, senza incidenti. Questo non lo rende un buon pattern, ma segnala qualcosa di profondo sulla resilienza dei sistemi on-premise: quando il controllo è completo, anche gli abusi possono sopravvivere a lungo, proprio perché manca l’orchestrazione esterna tipica del cloud che tende a invalidare le configurazioni fuori standard con aggiornamenti forzati. Nel cloud, il symlink sarebbe probabilmente saltato al primo aggiornamento gestito dell’ambiente operativo. In un datacenter privato, invece, la vostra anomalia può diventare un’istituzione.

Ecco allora che la lezione si allarga: l’automazione fine a se stessa — «abbiamo messo tutto su Ansible» — non è sufficiente a garantire igiene architetturale. Occorrono pratiche di revisione continua, test di integrazione che simulino condizioni variate, e un’attenzione quasi maniacale alla rimozione delle eccezioni. Per chi valuta deployment on-premise di LLM, è una riflessione critica: il prezzo della sovranità e del controllo si paga anche con la necessità di una disciplina interna che nessun vendor impone. Il debito tecnico, in questi contesti, non è solo un ritardo: è un rischio sistemico che può restare latente fino a quando qualcuno, da un messaggio su LinkedIn, ti ricorda che esiste.