Costruire per durare

Qualche giorno fa ho ascoltato una conversazione tra Jeremy Howard (fast.ai) e Chris Lattner, il creatore di LLVM, Swift e Mojo. Un’ora di dialogo pacato e concreto. Niente slide, niente hype. Solo due ingegneri che non si lasciano trascinare dal panico generale.

L’ho ascoltata tutta d’un fiato. Cosa che mi capita di rado.

Perché quello che dice Lattner mi ha toccato da vicino. Non come una conferenza lontana sul «futuro dello sviluppo». Piuttosto come uno specchio davanti a 18 anni di scelte progettuali, refactoring e app mantenute, abbandonate o riscritte da zero.

La domanda centrale è semplice. Quasi banale.

Come si costruisce un sistema che duri più di sei mesi?

La risposta, invece, non è affatto semplice.

LLVM: il compilatore che nessuno aveva chiesto

Natale 2000. Chris Lattner, dottorando, comincia a scrivere LLVM per conto suo. Non per risolvere un problema specifico. Non per rispondere a un incarico. Per affrontare una domanda fondamentale: che cosa dovrebbe essere, alla base, un’infrastruttura di compilazione?

Vent’icinque anni dopo LLVM è ovunque. Rust, Swift, Julia: interi linguaggi sono stati costruiti sopra di esso. Clang, il compilatore C/C++/Objective-C creato dallo stesso Lattner, è il frontend ufficiale. È dentro Xcode dal 2013, dietro ogni build di ogni app iOS.

Non è fortuna. È architettura.

Per capire perché regge così bene, bisogna conoscere un concetto chiave del design di LLVM: la rappresentazione intermedia, o LLVM-IR.

L’idea è elegante. Invece di compilare C++ (o Swift, o Rust) direttamente in codice macchina — cosa che richiederebbe di riscrivere tutto per ogni processore e architettura — LLVM introduce un passaggio intermedio universale. Ogni linguaggio viene prima tradotto in LLVM-IR. Poi LLVM trasforma quella IR in codice macchina ottimizzato per la destinazione: un iPhone, un Mac con Apple Silicon, un server Linux.

È come usare una lingua ponte. Parli francese, inglese, spagnolo: non importa. Prima si passa tutti dall’esperanto, poi si traduce verso la destinazione finale.

Questa pipeline in tre fasi — sorgente → IR → codice macchina — ha permesso a Rust di esistere senza riscrivere un compilatore completo, a Swift di girare su iPhone fin dal primo giorno e a Xcode di usare LLVM in produzione per anni. Si collega un nuovo linguaggio davanti, un nuovo processore dietro. Il nucleo non si tocca.

Questo significa partire dai principi fondamentali. Non una soluzione per oggi, ma una base per linguaggi che ancora non esistono.

«I sistemi che crollano sotto il proprio peso hanno un’architettura sbagliata fin dall’inizio. Quelli che durano esistono perché qualcuno si è preso il tempo di capire che cosa stava costruendo e perché.» — Chris Lattner

Riconosco questo modo di pensare. È proprio ciò che distingue un’app iOS che dura due anni da una che dopo sei mesi devi riscrivere da zero. Non è una questione di qualità del codice in senso sintattico. È la qualità del ragionamento che viene prima del codice.

L’architettura non si vede, ma decide tutto.

Vibe coding: il sintomo di un’epoca

Oggi il messaggio è chiaro: rilascia in fretta, rilascia spesso, usa l’IA per andare dieci volte più veloce. Alcuni CEO si vantano pubblicamente del fatto che i loro team producano 10.000 righe di codice scritto dall’IA ogni giorno.

10.000 righe al giorno.

Lattner la definisce una metrica inutile. O peggio, pericolosa.

«Non sono un CEO che si vanta del numero di righe generate dall’IA. Lo considero un rischio, non un vantaggio. Le domande giuste sono: il prodotto sta migliorando? Le persone capiscono quello che stanno costruendo?»

Il vibe coding — avviare un ciclo di agenti e sperare che ne esca qualcosa di utile — è gioco d’azzardo travestito da produttività. Howard lo dice così: «È come tirare la leva di una slot machine. Perdi, la tiri di nuovo. Perdi, la tiri di nuovo.»

La storia che mi ha gelato

Lattner racconta un caso concreto. Un ingegnere senior segnala un bug, parte un ciclo agentico e viene generata una PR. La PR supera i test. Il bug «scompare».

Solo che non è sparito. Il sintomo è stato mascherato. Sotto la superficie, il codebase ha appena ingoiato una bomba a orologeria: codice nel posto sbagliato, che fa la cosa sbagliata e sta per generare tre nuovi bug, più sottili del primo.

Il codice è stato integrato senza che nessuno capisse davvero cosa facesse.

Non è un problema degli strumenti. È un problema di cultura. Una cultura che ha imparato a far sparire i sintomi invece di capirne le cause.

Cosa significa per chi sviluppa app iOS

Sviluppo app iOS dal 2007. Ho visto arrivare e scomparire diversi paradigmi: Objective-C, ARC, Swift, SwiftUI, MVC/MVVM/TCA. Ho riscritto app intere e ne ho mantenute altre per anni.

Posso dirlo: il debito tecnico non dorme mai.

Aspetta. Si accumula. E si fa sentire nel momento peggiore: quando c’è una scadenza, quando Apple pubblica una nuova versione di iOS, quando un utente segnala un bug che ormai non capisci più perché chi aveva scritto quel codice non c’è. Oppure eri tu, tre anni fa, e non ricordi più il ragionamento.

L’IA non ha cambiato questa realtà. L’ha accelerata.

Con Onyria ho fatto una scelta consapevole: usare l’IA come acceleratore, non come architetto. Le decisioni strutturali — come gestire i crediti degli utenti, orchestrare le chiamate all’API di Reve e sincronizzare i dati tra dispositivi con SwiftData senza un server esterno — le prendo io. L’IA può aiutarmi a scrivere boilerplate, esplorare alternative e individuare casi limite. Ma non può capire al posto mio i vincoli dell’ecosistema Apple.

Sono 18 anni di esperienza a parlare. E questo non si automatizza.

La biforcazione

Howard fa una diagnosi che mi ha colpito:

«Ci saranno due gruppi. Quelli che avranno sviluppato un’impotenza appresa, che senza l’IA non sapranno più bene cosa fare. E quel gruppo più piccolo, davanti al quale tutti si chiederanno: “Come fa a sapere tutte queste cose? È incredibile.”»

Lo stiamo già vedendo. I tempi di revisione dell’App Store si allungano perché le submission aumentano a dismisura, ma la qualità no. Apple sta rendendo più severe le linee guida (4.1, 4.2, 4.3) contro le app-clone create con i prompt. L’asticella si alza.

Per chi capisce davvero ciò che sta costruendo, è una buona notizia. L’ecosistema si sta ripulendo. La competenza torna a essere un vantaggio competitivo concreto, non solo teorico.

La domanda che Lattner pone a ogni ingegnere è diretta:

«Quando l’hype si sarà calmato — e succede sempre — tu dove sarai? Sarai cresciuto? O avrai passato due anni a tirare leve, sperando che l’IA ti rendesse migliore per osmosi?»

Come uso davvero l’IA

Lattner usa l’IA. Parla di un aumento di produttività del 10–20%. Ma mantiene quello che chiama un ciclo di iterazione stretto: modificare, compilare, eseguire, fare debug. In ogni momento sa cosa sta facendo il suo codice.

È esattamente il mio approccio.

L’IA mi aiuta a:

• esplorare un’API che ancora non conosco;
• generare boilerplate che non voglio scrivere a mano;
• mettere alla prova la mia architettura prima di impegnarmi;
• individuare casi limite che potrei aver trascurato.

Quello che non fa al posto mio:

• decidere l’architettura;
• capire i vincoli di business;
• mantenere la coerenza nel tempo;
• verificare che il risultato abbia senso nel contesto più ampio.

La differenza è quella tra uno strumento e una stampella. Uno strumento amplifica ciò che sai già fare. Una stampella compensa ciò che non sai fare — e ti impedisce di imparare.

Cosa mi porto via

L’intervista a Lattner non è un manifesto contro l’IA. Ricorda che i fondamentali non sono superati.

Architettura. Comprensione. Mestiere.

Gli stessi principi hanno permesso a LLVM di funzionare per 25 anni dalla sua creazione. E sono quelli che aiutano un’app iOS ben progettata a durare, evolversi e superare i cambiamenti della piattaforma.

L’IA è uno strumento straordinario. Ma gli strumenti non hanno mai sostituito il giudizio.

Il giudizio si costruisce sul campo: nei bug che hai impiegato tre giorni a capire, nei refactoring dolorosi che hai portato a termine, nelle decisioni architetturali di cui ti sei assunto la responsabilità nel tempo.

A definire il tuo valore come sviluppatore non è ciò che genera l’IA. È ciò che capisci di quello che genera.

L’intervista completa è disponibile sufast.ai. La consiglio davvero. Ecco il video.