Legacy dal giorno zero

Bun funziona. È in produzione da oltre un mese e il team che lo mantiene sta ancora imparando a leggere il codice che distribuisce.

La runtime JavaScript che ha sfidato Node.js su velocità e compatibilità è stata riscritta da Zig a Rust. Non da un team che conosceva Rust, né da sviluppatori che hanno passato mesi a studiare. La traduzione è stata fatta quasi interamente da Claude, partendo dalla codebase Zig originale. Il risultato è già in produzione: decine di migliaia di sviluppatori ci lavorano sopra ogni giorno, e come ha dichiarato il fondatore del progetto, quasi nessuno se n'è accorto. I test passano. Le performance ci sono.

Qui finisce la storia di successo.

Il team è nuovo a Rust. Sta costruendo i modelli mentali per un codebase che sta già distribuendo. Non ha scritto il codice. Non l'ha revisionato. Non c'è mai stato, non ancora, il momento in cui qualcuno guarda una funzione e dice ah, ecco perché. Questo è il primo caso documentato di legacy software dal giorno zero: infrastruttura critica che nasce già ereditata, già opaca, già fuori dalla portata della comprensione di chi la possiede.

Non è un fallimento dell'AI coding, è una mutazione del rapporto tra sviluppatore e codice.

Opacità strutturale

La parola "legacy" nel software ha sempre indicato qualcosa di preciso: codice scritto da qualcuno che se n'è andato, pieno di decisioni di cui si è persa la memoria, difficile da modificare senza rompere qualcosa. Ma la parola conteneva anche una premessa rassicurante. Qualcuno, a un certo punto, lo capiva. C'era stato un momento originario in cui quel codice era trasparente a chi lo scriveva. Poi il tempo, i commit, i team che cambiano lo avevano reso opaco. L'opacità era un sedimento, non una condizione di partenza.

Qui quel momento originario non esiste. Non è mai esistito. Il codice Rust di Bun è nato opaco: non perché è scritto male, ma perché è stato generato senza che nessuno dovesse mai formare i modelli mentali necessari a produrlo. Il modello ha tradotto pattern da Zig a Rust, ha risolto problemi di ownership, ha gestito la complessità del porting. Ma la comprensione di perché quelle scelte funzionano non è stata trasferita. Non poteva esserlo. Un LLM non capisce: produce output che un umano, con sufficiente sforzo, può decifrare. Solo che in questo caso l'umano non era presente al momento della scrittura.

Non è la prima volta che automatizziamo la produzione di qualcosa e perdiamo comprensione del processo. È successo con la catena di montaggio, con i compilatori, con ogni ondata di astrazione. Ma il software è diverso da un oggetto fisico. Il software è comprensione cristallizzata. Un martello puoi usarlo senza sapere come è stato forgiato. Una runtime no: devi farla evolvere, e per farla evolvere devi poterla simulare mentalmente, devi avere categorie per anticipare cosa succede quando cambi qualcosa.

Il codice Rust di Bun non ha un autore che lo capisce. Ha un generatore che lo ha prodotto e un team che lo sta decifrando.

Questo cambia tutto. Non stiamo parlando di codice generato per una landing page. Stiamo parlando di un runtime: il tipo di infrastruttura dove un errore di memory management non è un'eccezione 500, è una superficie d'attacco. Dove far evolvere il progetto richiede decisioni architetturali che presuppongono una familiarità con il sistema.

Cosa succede quando arriva il primo bug serio: non un errore di compilazione, ma un comportamento anomalo nel garbage collector, una race condition nel loop degli eventi? Si può chiedere al modello di correggerlo. Ma per valutare se la correzione è giusta, per capire se non introduce altri problemi, per decidere se la direzione ha senso: devi capire il sistema. E se non lo capisci, stai accumulando patch su una base che nessuno ha mai veramente posseduto.

Bun non sarà l'ultimo. È probabilmente il primo di una nuova categoria: software infrastrutturale generato, funzionante, distribuito, e strutturalmente opaco a chi lo mantiene. La tentazione è forte. Perché passare mesi a imparare Rust quando un modello può tradurre tutto in pochi giorni? Perché soffrire con il borrow checker quando l'AI gestisce ownership e lifetimes meglio di uno sviluppatore alle prime armi?

La trappola non è che il codice generato sia scadente. È che è abbastanza buono da funzionare, e abbastanza opaco da non poter essere veramente posseduto. È la differenza tra usare uno strumento e abitare un'architettura. Puoi vivere in una casa senza sapere come è stata costruita. Ma non puoi ristrutturarla senza capire dove passano i muri portanti.

Il nuovo regime

Non si tratta di fermare questa tendenza: non si ferma, e forse non dovrebbe. Il punto è riconoscere che stiamo entrando in un paradigma nuovo. Un paradigma in cui "funziona" non è più la domanda che conta. La risposta a "funziona?" è sempre più spesso sì.

Stiamo costruendo cattedrali che nessun architetto ha mai visto.

Per ora, stanno in piedi.