Perché alcune astrazioni mi appassionano e altre mi annoiano immediatamente

Questo articolo prosegue la riflessione iniziata nei miei due testi precedenti sul mio rapporto con lo sviluppo software e con l'intelligenza artificiale.

Da qualche tempo cerco di capire perché ho sempre fatto così fatica a interessarmi profondamente alla tecnica.

Non a usarla. Non a imparare abbastanza da far funzionare qualcosa. Ma a voler davvero capire che cosa succede dietro le quinte.

Me ne sono reso conto ancora una volta recentemente, mentre preparavo una discussione di progetto. Dovevo, per esempio, essere pronto a spiegare eventualmente che una build multi-stage con Docker permette di separare la fase di compilazione con Maven dall'immagine finale, che utilizza soltanto il JRE, in particolare per ridurre le dimensioni dell'immagine e limitare le potenziali vulnerabilità.

Posso imparare questa frase. Posso anche capire, a grandi linee, che cosa significa. Ma molto rapidamente, qualcosa comincia a infastidirmi.

Perché Maven è necessario durante la compilazione ma non dopo? Che cosa contiene esattamente il JRE? Che cosa scompare davvero dall'immagine finale? Perché questo ne riduce le dimensioni e, soprattutto, perché riduce le vulnerabilità?

Ogni risposta sembra aprire tre nuove porte. E a quel punto, la mia reazione è quasi sempre la stessa: va bene, vi credo, funziona, possiamo passare ad altro. Non ho né il tempo né la voglia di approfondire. E questo è solo un esempio tra centinaia.

Non è che non mi piaccia capire le cose in generale.

Posso passare moltissimo tempo a cercare di capire qualcosa quando l'argomento mi interessa: le filosofie, le religioni, la sociologia, la psicologia. Posso leggere diversi punti di vista, confrontare sistemi di pensiero, cercare di capire perché gli individui o le società funzionano in un certo modo, e continuare ad approfondire semplicemente perché ogni risposta genera una nuova domanda interessante.

In questi ambiti, l'astrazione non mi disturba. Al contrario. Posso trovare affascinante un'idea anche se non ha alcuna applicazione pratica immediata.

E questo rapporto non risale certo all'informatica. Ricordo di aver provato esattamente la stessa cosa al liceo, con la matematica e la fisica. Quando mi spiegavano perché la luce bianca poteva scomporsi in diversi colori, la mia reazione non era: è affascinante, voglio capire questo fenomeno fino in fondo. Era piuttosto: va bene, e quindi?

Potevo tranquillamente accettare che un fenomeno esistesse senza sentire il bisogno di esplorare tutta la fisica che c'era dietro. Al contrario, potrei passare ore a discutere del perché due società sviluppino norme morali differenti, o del perché due persone interpretino lo stesso evento in modi completamente opposti, oppure a immaginare scenari alternativi in cui un determinato condottiero avesse fatto una scelta diversa in un certo momento della storia.

Quindi non è davvero la complessità in sé a scoraggiarmi. È la natura della complessità.

Per molto tempo ho formulato male il problema dicendomi che ero semplicemente poco portato per le cose astratte. Eppure una religione è astratta. Anche un'ideologia lo è. E tuttavia posso passare ore a cercare di comprenderle.

La differenza è altrove. Quando approfondisco un'idea in psicologia, sociologia, filosofia o religione, l'astrazione finisce quasi sempre per ricondurmi agli esseri umani: perché qualcuno crede in questo, perché agisce in quel modo, perché una società considera normale un comportamento mentre un'altra no. Per quanto astratto possa essere, il concetto porta da qualche parte; mi aiuta a capire comportamenti, intenzioni, valori, conflitti o società reali.

Con la maggior parte dei concetti tecnici, invece, provo qualcosa di molto diverso. Perché bisogna mettere i layer Docker più stabili prima di quelli più volatili? Perché così si sfrutta meglio la cache. Perché? Perché Docker può riutilizzare determinati layer finché non vengono invalidati. E così via. Ogni risposta mi porta un po' più in profondità nel funzionamento del sistema, ma in fondo a questa discesa c'è ancora il sistema. Non scopro nulla sugli esseri umani, sui loro comportamenti o sulle loro convinzioni. Capisco semplicemente un po' meglio come funziona Docker, o un determinato linguaggio, o un determinato framework. Per alcune persone è chiaramente appassionante, ma per me non lo è mai stato.

E questo probabilmente spiega molte cose: perché ho sempre saputo sviluppare senza mai innamorarmi del codice; perché posso appropriarmi di uno strumento quel tanto che basta per costruire ciò di cui ho bisogno, senza cercare di esplorarne i livelli inferiori; perché le buone pratiche restano, per me, regole applicate più che intuizioni profondamente interiorizzate. E perché, dopo diversi anni di esperienza, non sono ancora diventato quel tipo di sviluppatore animato dal desiderio di dissezionare ogni sistema fino all'atomo.

In fondo, non si tratta di giudicare se questo approccio sia giusto o sbagliato, anche se per i puristi rimane probabilmente discutibile.

In fondo, l'intelligenza artificiale non ha inventato nulla nel mio rapporto con la tecnica: ha semplicemente accelerato un modo di fare che era già profondamente radicato. Molto prima degli LLM, progettavo applicazioni funzionanti assemblando documentazione, tutorial e componenti software per ottenere il risultato desiderato, senza cercare di svelare i misteri sotto il cofano. I framework mi avevano già preparato a questo, introducendo la loro quota di astrazione e convenzioni pronte all'uso.

Con l'IA, questa distanza si è semplicemente moltiplicata. Oggi posso formalizzare un bisogno, lasciare che un agente proponga e implementi una soluzione, validare il risultato e andare avanti senza padroneggiare ogni meccanismo interno. L'approccio comporta ovviamente dei rischi: è per questo che incrocio agenti e modelli, soprattutto durante le code review, per individuare i punti ciechi della prima versione, cosa che accade regolarmente. Ma per il momento il dato di fatto è questo: questo metodo funziona. Non ho bisogno di smontare tutto pezzo per pezzo per riuscire a consegnare.

E se, alla fine, il mio ruolo consistesse più nel progettare, orchestrare e consegnare che nel dissezionare l'infrastruttura invisibile dei sistemi, sarebbe davvero un problema?