Il lato oscuro del vibe coding: quando il codice funziona solo nel tuo-head

Siamo onesti: il vibe coding è una rivoluzione. Descrivi cosa vuoi, guardi l'agent costruirlo, vedi i test diventare verdi, e fai il deploy. Sembra magia, finché non lo è.

Quel "finché non lo è" di solito arriva alle tre di notte. La tua app parte bene, gestisce qualche richiesta senza problemi, poi viene killata senza complimenti da un OOM killer. Oppure apre diecimila file descriptor e collassa. O funziona perfettamente con i tuoi dati di test e si inchioda quando arrivano gli utenti veri.

Il codice era corretto. Risolveva il problema esattamente come specificato. Assumeva solo che memoria e file handle fossero infiniti — perché niente nel tuo prompt diceva il contrario.

L'assassino silenzioso: le assunzioni non dette

Questa è la parte insidiosa del vibe coding che nessuno menziona ai conference talk. Quando scrivi codice tu stesso, i vincoli li porti sempre in mente. Sai che stai girando su un laptop con 16GB di RAM. Sai che il production server ha limiti sui file descriptor. Sai che quel CSV da 400GB non è qualcosa che puoi caricare tutto in memoria.

Ma quando è un'AI a scrivere il codice, questi vincoli non esistono. L'AI legge "carica il file, ordinalo, scrivi il risultato" e pensa: perfetto, carico tutto. Funziona benissimo nei test. Il file di test è 50KB.

Le code review non catturano nemmeno questo. Le righe incriminate sembrano completamente ragionevoli. Niente fa suonare campanelli d'allarme quando cerchi errori logici — perché non ce ne sono. Il bug non è nella logica; è nel box invisibile dentro cui quella logica è stata progettata.

E se il compilatore conoscesse i limiti?

Qui le cose si fanno interessanti. Uno sviluppatore di nome Nicolas Grislain sta sperimentando un'idea provocatoria: e se i vincoli sulle risorse fossero tipi, non commenti?

Invece di sperare che il codice generato dall'AI rispetti i limiti di memoria, cosa succederebbe se il compilatore si rifiutasse letteralmente di compilare codice che li viola? E se "questa funzione non tiene mai più di 100 record in memoria" e "questo programma non ha mai più di 3 file aperti contemporaneamente" fossero fatti verificati dal compilatore, non preghiere sussurrate durante la code review?

Non è solo teoria fumosa. L'esperimento usa Lean 4 — sì, lo stesso Lean che sta facendo rumore nella matematica formale — per codificare i budget delle risorse direttamente nei tipi delle funzioni. Il compilatore diventa un revisore delle risorse, che controlla automaticamente che il tuo codice resti nei limiti prima ancora che giri.

Come funziona in pratica

Il trucco核心 è sorprendentemente elegante: si passa il conteggio delle risorse attraverso il sistema di tipi. Invece di tracciare "quanti file sono aperti" come variabile runtime che potrebbe essere ignorata, il sistema di tipi lo traccia come parametro fantasma che deve tornare a zero.

Quando apri un file, la firma del tipo riflette il cambiamento: entri nella funzione con N file aperti ed esci con N+1. Quando lo chiudi, torni da N+1 a N. Il compilatore traccia questo a ogni passo, e non puoi letteralmente compilare codice che apre un file senza chiuderlo, o che apre file oltre un tetto definito.

La memoria funziona in modo simile, ma con una variazione. I record non fluttuano liberi in memoria — vivono in un pool con un numero fisso di slot. Non tieni un oggetto Event; tieni un riferimento a quel pool. Il tipo traccia quanti riferimenti vivi esistono in ogni momento, e l'allocazione richiede la prova che c'è spazio.

La magia succede al punto di ingresso: il programma deve iniziare con zero risorse in uso e finire con zero. Non puoi perdere handle o riferimenti. Non puoi superare i tetti. Il compilatore semplicemente non te lo permette.

Perché conta per il vibe coding

Questo approccio trasforma come pensiamo di prompting gli assistenti AI. Oggi potresti aggiungere una nota come "fai attenzione con l'uso della memoria" o "chiudi tutti i file handle" — sperando che l'AI ci presti attenzione. Con i tipi che conoscono le risorse, specifichi i vincoli formalmente, e l'implementazione deve riorganizzarsi per soddisfarli.

L'AI ottiene prima la versione senza vincoli. I test passano. Poi abiliti i limiti. Il compilatore rifiuta immediatamente l'implementazione. L'AI deve ristrutturare l'approccio — magari processando il file a chunk invece di caricarlo tutto in una volta, o usando un connection pool invece di aprire file direttamente.

L'implementazione non funziona per caso; funziona provabilmente entro il budget.

La realtà pratica

Siamo chiari: non è ancora tooling production-ready per la maggior parte dei team. L'approccio Lean 4 richiede setup significativo, e c'è un overhead nel pensare in termini di tipi indicizzati. Ma l'insight sottostante è prezioso indipendentemente dall'implementazione.

Quando fai vibe coding, stai facendo outsourcing non solo della scrittura del codice ma del modello mentale del tuo sistema. Il tuo assistente AI non conosce il tuo ambiente di produzione. Non sa che il tuo container ha 512MB di RAM. Non sa che il tuo Linux kernel limita i file descriptor a 1024.

Finché non avremo modi migliori per codificare questi vincoli, abbiamo qualche opzione pragmatica:

1. Sii esplicito nei prompt — "Il file di input può contenere fino a 10 milioni di righe" è meglio di "gestisci file grandi in modo efficiente"

2. Testa con dati di dimensione production — Se i tuoi dati di training sono minuscoli, la tua AI non imparerà i pattern di risorse

3. Usa API con limiti incorporati — L'architettura che limita naturalmente l'uso delle risorse (connection pool, streaming invece di caricamento) è più difficile da usare male

4. Tieni d'occhio tooling che conosce le risorse — L'industria sta iniziando a esplorare modi per rendere espliciti i vincoli nel codice generato dall'AI

Il punto chiave

Il segreto sporco del vibe coding non è che scriva codice pieno di bug — è che scriva codice corretto dentro uno spazio di vincoli invisibile. Quello spazio include il tuo laptop, il tuo ambiente di test, e forse i tuoi primi mille utenti. Non include sicuramente "produzione a scala."

Sistemi di tipi consapevoli delle risorse come questo esperimento Lean 4 puntano verso un futuro dove "corretto" significa più di "logicamente giusto." Significa "provato per restare entro i confini che esistono davvero."

È un futuro degno di essere costruito. Nel frattempo, tieni i tuoi dati di test vicini alla dimensione production, e magari aggiungi una nota in più nei tuoi prompt su quei limiti dei file descriptor.

Il tuo futuro io on-call te ne sarà grato.