L'era dei vibe fork: quando la AI ricostruisce il software dal nulla

Qualche giorno fa ho assistito a una demo che tre anni fa sarebbe sembrata fantascienza. Un sistema di AI ha generato un compilatore funzionante, capace di targeting su diverse architetture processore. Non un giocattolo. Non un prototipo. Un compilatore vero che ha superato il 99% dei test suite standard del settore.

Questo è il punto in cui siamo.

La traiettoria della generazione di codice tramite AI è stata vertiginosa. Abbiamo iniziato predendo la parola successiva in una riga, poi intere funzioni, poi file completi, e ora — sempre più — progetti interi. Con questa esplosione di capacità è emerso un effetto collaterale affascinante: l'ascesa di quello che la community chiama "vibe fork".

Un vibe fork, in parole povere, è ciò che succede quando qualcuno usa il vibe coding per creare una clean-room implementation di un software esistente. Non copiano il codice. Ricreano la funzionalità da zero, invocata da sistemi AI sempre più capaci. Il codice sorgente non è più il fossato difensivo — in fondo, non lo è mai stato davvero. La conoscenza di come funzionano le cose è stata assorbita nei dati di training e codificata nei pesi del modello.

L'esperimento del compilatore Carlini

L'esempio più impressionante arriva da una ricerca recente sull'AI. Sedici agenti AI sono stati liberati su un codebase condiviso per costruire un compilatore C da zero. Dopo quasi 2.000 sessioni e 20.000 dollari in costi API, hanno prodotto un compilatore da 100.000 righe capace di buildare Linux 6.9 su architetture x86, ARM e RISC-V. Riesce persino a compilare DOOM.

Lasciate che vi assorba per un momento.

Cento mila righe di codice compiler di qualità produttiva. Tre architetture processore distinte. Un kernel che bootta davvero. Non è un progetto hack del weekend — è software che ha richiesto anni ai ricercatori per essere costruito, riprodotto da agenti autonomi in quello che si riduce a qualche settimana di tempo computazionale.

La reazione immediata oscilla tra euforia e terrore esistenziale, a seconda di dove vi trovate. Ma credo che la realtà sia più sfumata, e onestamente, più interessante.

Perché non perdo il sonno sui vibe fork

Ecco la mia opinione forte: i vibe fork sono impressionanti, ma non sono la minaccia esistenziale per i maintainer di software che potrebbero apparire.

Considerate l'economia dell'abbondanza. Quando chiunque può invocare un compilatore C, l'artefatto smette di essere scarso. Ciò che diventa scarso è il giudizio — specificamente, il giudizio su quale delle molte alternative generate sia corretta, mantenuta, sicura, e degna di fiducia nei sistemi di produzione.

Questo pattern si è già verificato prima. Guardate gli app store. Il costo del cloning lì è già vicino allo zero. La barriera per pubblicare è bassa. Risultato? Un centinaio di habit tracker, mille app torcia, un oceano di strumenti di produttività quasi identici. I cloni esistono. Semplicemente non sembrano andare avanti.

Ciò che separa i vincitori dal mucchio non sono le feature. È la curation, la discovery, la trust e la reputation. Il featured editoriale, le recensioni degli utenti, le valutazioni a stelle, il brand recognition che ha richiesto anni per essere costruito. Potete replicare la lista delle feature in una notte. Non potete replicare la trust.

Il vantaggio nascosto dell'incumbent

Ecco qualcosa di controintuitivo: la stessa proprietà che rende possibili i vibe fork aiuta in realtà gli incumbent più di quanto aiuti i newcomers.

Il software ampiamente distribuito è stato nei training data infinite volte. È stato colpito da corner case e condizioni al limite che gli sviluppatori hanno impiegato anni a scoprire e correggere. Il modello è bravo a mantenere questo software precisamente perché il mondo ha già fatto il lavoro duro di trovare cosa è rotto.

Un vibe fork appena creato non ha nessuna di questa storia. Potrebbe funzionare magnificamente per l'happy path. Ma quel crash misterioso che succede solo quando processi un file con caratteri Unicode nel mezzo di un martedì pomeriggio di novembre? A qualcuno ci sono voluti tre mesi per rintracciarlo. Non è nella vostra prompt. È conoscenza istituzionale embedded nel codebase originale.

I modelli sono genuinamente migliori a mantenere ciò che il mondo ha già imparato a mantenere. Non è giusto, ma è vero.

L'elemento umano che non scala

E poi c'è il supporto. Questo è dove i vibe fork davvero vacillano, e credo sia il fossato più sottovalutato di tutto questo.

L'AI agentic può gestire assolutamente progetti greenfield. Costruire qualcosa di nuovo da zero? I modelli sono notevolmente capaci. Ma il software reale non è greenfield. Il software reale è brownfield. Ha dipendenze accumulate, integrazioni legacy, configurazioni strane, e il cruft accumulato di anni di "sistemiamo dopo".

Ogni progetto maturo porta con sé essential complexity — la difficoltà inerente del problema che risolve. Ma porta anche accidental complexity, il tipo che si insinua nel tempo attraverso requisiti che cambiano, turnover, e le mille piccole decisioni che sembravano ragionevoli al momento.

Ridurre quella accidental complexity? Questo è un compito profondamente umano. Richiede capire un contesto che potrebbe non essere mai stato scritto. Richiede conversazioni con gli utenti su cosa hanno realmente bisogno. Richiede decisioni su tradeoff che hanno senso solo data la storia organizzativa.

Gli agenti AI possono aiutare con tutto questo. Ma non possono farlo da soli, e certamente non possono farlo per un fork fresco che non ha quelle relazioni o quel contesto.

L'opportunità reale

Ecco cosa credo stia realmente succedendo con i vibe fork: non stanno eliminando il valore del grande software. Stanno democratizzando la capacità di costruire nuovo software.

Le persone che erano bloccate dal creare perché non conoscevano C o non avevano anni di esperienza con i compilatori? Sono sbloccate adesso. Le startup che non potevano permettersi di costruire infrastruttura da zero? Possono prototype e validare idee più velocemente che mai.

Ciò che i vibe fork non possono facilmente replicare è la trust accumulata, la community e la conoscenza istituzionale che rende il software prezioso nel tempo. Quella si costruisce ancora alla vecchia maniera: attraverso anni di shipping, ascolto, fixing e iterating.

Quindi sì, la barriera per ricreare software è crollata drammaticamente. Ma la barriera per creare software che conta — il tipo di cui le persone si fidano con le loro aziende e i loro mezzi di sussistenza — richiede ancora l'elemento umano. Lo richiederà sempre.

La domanda non è se l'AI può costruire i tuoi sogni. Può. La domanda è se puoi costruire qualcosa che valga la pena mantenere.