Il problema non è mai stato il codice

Negli ultimi anni mi è capitato spesso di ripensare a una convinzione che, per molto tempo, avevo dato quasi per scontata.

Che il mio lavoro fosse costruire software.

È una frase che suona perfettamente ragionevole.

Dopotutto faccio il software architect. Progetto sistemi, discuto di architetture distribuite, Domain-Driven Design, cloud, eventi, AI, microservizi. Sembra naturale pensare che il centro del mio lavoro sia il software.

Eppure, più passa il tempo, più mi convinco che il software arrivi sempre per ultimo.

Il software è il risultato.

Non è il punto di partenza.

Negli ultimi vent’anni abbiamo assistito a un’evoluzione straordinaria.

Sono cambiati i linguaggi, i framework, il modo di distribuire le applicazioni, le architetture. Abbiamo imparato a costruire sistemi distribuiti, a utilizzare il cloud, a orchestrare container, a sviluppare applicazioni event-driven.

Oggi, grazie all’intelligenza artificiale, possiamo persino delegare la scrittura di una parte significativa del codice.

Se guardassimo soltanto gli strumenti, dovremmo concludere che sviluppare software non è mai stato così semplice.

Ma allora perché continuiamo a costruire sistemi che, dopo pochi anni, diventano difficili da comprendere?

Perché continuiamo a riscrivere software che, dal punto di vista tecnologico, funziona perfettamente?

Perché le discussioni più lunghe di un progetto raramente riguardano il framework da utilizzare?

La mia esperienza è che le conversazioni davvero importanti iniziano molto prima.

Cominciano quando qualcuno pronuncia una frase apparentemente banale:

Da quel momento inizia una discussione che, spesso, dura settimane.

Che cos’è esattamente un ordine?

Quando nasce?

Quando termina?

Può essere modificato?

Chi ne è responsabile?

Due persone possono utilizzare la stessa parola attribuendole significati completamente diversi, senza accorgersene.

Ed è proprio lì che nasce la complessità.

Non nel codice.

Nel significato.

Negli ultimi mesi questa sensazione è diventata ancora più forte.

L’arrivo dell’AI generativa ha alimentato una domanda che tutti ci siamo posti almeno una volta:

---

Se una macchina può scrivere il codice, quale sarà il ruolo di uno sviluppatore? E di un software architect?

---

Non ho una risposta definitiva.

Ma ho una convinzione sempre più forte.

L’intelligenza artificiale non ha reso meno importante il nostro lavoro.

Ha semplicemente spostato l’attenzione sul punto in cui il nostro contributo è davvero indispensabile.

Comprendere il problema.

Perché quando il contesto è ambiguo, anche il codice generato dall’AI sarà ambiguo.

Quando il dominio è compreso male, anche la soluzione migliore sarà costruita sulle fondamenta sbagliate.

L’AI ha reso il codice più economico.

Non ha reso più economica la comprensione.

Ed è proprio questa riflessione che mi ha portato a una domanda inattesa.

Se il cuore del nostro lavoro consiste nel comprendere la realtà prima ancora di rappresentarla in un sistema software…allora siamo davvero sicuri che il nostro sia soltanto un mestiere tecnico?

Forse le domande che ci poniamo ogni giorno sono molto più antiche di quanto immaginiamo.

Quando decidiamo che cosa rappresentare in un sistema, stiamo scegliendo quali aspetti della realtà considerare importanti.

Quando definiamo un modello, stiamo stabilendo quali differenze meritano di esistere e quali possono essere ignorate.

Quando assegniamo un nome a qualcosa, non ci limitiamo a descriverla. Influenzamo il modo in cui le persone la comprenderanno, ne parleranno e costruiranno software attorno a essa.

Queste non sono soltanto decisioni tecniche.

Sono decisioni sulla realtà, sulla conoscenza e sul significato.

Ed è forse per questo che le tecnologie cambiano continuamente, mentre alcune difficoltà rimangono sempre le stesse.

Possiamo sostituire un framework.

Possiamo migrare un database.

Possiamo riscrivere un’applicazione.

Possiamo persino chiedere a un’intelligenza artificiale di generare il codice.

Ma nessuno strumento può decidere al posto nostro che cosa il sistema debba davvero rappresentare.

Il codice può essere automatizzato.

La comprensione no.

Ed è lì, molto prima della prima riga di codice, che comincia davvero l’architettura.