De ce vibe coding-ul e o bombă cu ceas (și cum am putea-o dezamorsa)

Să fim sinceri: vibe coding-ul sună extraordinar. Descrii ce vrei, privești cum agentul construiește totul, testele devin verzi, și livrezi. Magie curată — până când nu mai e.

Momentul acela "până când" apare de obicei pe la 3 noaptea. Aplicația ta pornește frumos, procesează câteva requesturi cu grație, apoi este ucisă abrupt de un OOM reaper. Sau deschide zece mii de file descriptors și se prăbușește. Sau rulează perfect pe datele tale de test și pică rău când apar utilizatori reali.

Codul era corect. Rezolva problema exact cum fusese specificată. Doar că presupunea memorie infinită și file handles infinite — pentru că nimic în prompt-ul tău nu spunea altfel.

Asumpțiile Tacite: Dușmanul Invizibil

Asta e partea nasoală a vibe coding-ului pe care nimeni nu o discută la conferințe. Când scrii cod singur, porți modelele mentale ale constraint-urilor peste tot. Știi că rulezi pe un laptop cu 16GB RAM. Știi că serverul de producție are limite pe file descriptors. Știi că acel CSV de 400GB nu e ceva ce poți încărca în memorie.

Dar când o AI îți scrie codul, aceste constraint-uri nu există. AI-ul vede "încarcă fișierul, sortează-l, scrie rezultatul" și thinks: perfect, voi încărca tot. Funcționează perfect la testare. Fișierul de test are 50KB.

Nici code reviews nu te salvează. Liniile problematice arată complet rezonabil. Nimic nu ridică un steag roșu când scanezi după erori de logică — pentru că nu sunt erori de logică. Bug-ul nu e în logica în sine, ci în cutia invizibilă în care logica a fost proiectată să se potrivească.

Ce-ar fi dacă Compilerul Ar Ști?

Aici lucrurile devin interesante. Un dezvoltator pe nume Nicolas Grislain experimentează cu o idee provocatoare: ce-ar fi dacă constraint-urile de resurse ar fi tipuri, nu comentarii?

În loc să speri că AI-ul respectă limitele de memorie, ce-ar fi dacă compilerul ar refuza literal să compileze cod care le încalcă? Ce-ar fi dacă "această funcție nu ține niciodată mai mult de 100 de înregistrări în memorie" și "acest program nu are niciodată mai mult de 3 fișiere deschise simultan" ar fi fapte verificate de compiler, nu rugăciuni șoptite în timpul code review-ului?

Nu e doar teorie. Experimentul folosește Lean 4 — da, același Lean care face valuri în matematica formală — pentru a codifica bugete de resurse direct în tipurile funcțiilor. Compilerul devine un auditor de resurse, verificând automat că totul rămâne în limite înainte să ruleze vreodată.

Cum Funcționează

Trucul central e surprinzător de elegant: se pasază contoare de resurse prin sistemul de tipuri. În loc să track-uiești "câte fișiere sunt deschise" ca o variabilă runtime care poate fi ignorată, sistemul de tipuri îl track-uiește ca parametru fantomă care trebuie să se balanseze.

Când deschizi un fișier, signatura tipului reflectă schimbarea: intri în funcție cu N fișiere deschise și ieși cu N+1. Când îl închizi, revii de la N+1 la N. Compilerul urmărește asta la fiecare pas, și literalmente nu poți compila cod care deschide un fișier fără să-l închidă, sau care deschide fișiere peste un plafon definit.

Memoria funcționează similar, dar cu o răsucire. Înregistrările nu plutesc liber în memorie — ele trăiesc într-un pool mărginit cu un număr fix de sloturi. Nu ții un obiect Event; ții o referință în acel pool. Tipul track-uiește câte referințe live există în orice moment, iar alocarea necesită dovada că e loc.

Magia se întâmplă la entry point: programul trebuie să înceapă cu zero resurse în uz și să se termine cu zero. Nu poți scurge handle-uri sau referințe. Nu poți depăși capacele. Compilerul pur și simplu nu te lasă.

De Ce Contează pentru Vibe Coding

Această abordare transformă modul în care gândim prompting-ul pentru AI assistants. Azi, ai putea adăuga o notă de tipul "fii atent cu utilizarea memoriei" sau "închide toate file handles" — sperând că AI-ul face ce trebuie. Cu tipuri aware de resurse, specifici constraint-urile formal, și implementarea trebuie să se reorganizeze pentru a le satisface.

AI-ul primește întâi versiunea neconstraint-uită. Testele trec. Apoi activezi limitele. Compilerul respinge imediat implementarea. AI-ul trebuie să-și restructureze abordarea — poate procesând fișierul în chunk-uri în loc să încarce tot odată, sau folosind un connection pool în loc să deschidă fișiere direct.

Implementarea nu doar că se întâmplă să funcționeze; ea funcționează demonstrabil în limitele bugetului.

Realitatea Practică

Să fim clari: nu e încă un tool production-ready pentru majoritatea echipelor. Abordarea Lean 4 necesită setup semnificativ, și e overhead în a gândi în termeni de indexed types. Dar insight-ul de bază e valoros indiferent de implementare.

Când faci vibe coding, externalizezi nu doar scrierea codului, ci și modelul mental al sistemului tău. AI assistant-ul tău nu știe mediul tău de producție. Nu știe că containerul tău are 512MB RAM. Nu știe că kernelul Linux limitează file descriptors la 1024.

Până avem metode mai bune de a codifica aceste constraint-uri, avem câteva opțiuni pragmatice:

1. Fii explicit în prompturi — "Fișierul de input poate conține până la 10 milioane de rânduri" e mai bun decât "procesează fișiere mari eficient"

2. Testează cu date de dimensiune production — Dacă datele tale de training sunt minuscule, AI-ul nu va învăța pattern-uri de resurse

3. Folosește API-uri bounded — Arhitectura care limitează natural utilizarea resurselor (connection pools, streaming în loc de încărcare) e mai greu de folosit greșit

4. Urmărește tool-urile aware de resurse — Industria începe să exploreze modalități de a face constraint-urile explicite în codul generat de AI

Concluzia

Secretul murdar al vibe coding-ului nu e că scrie cod cu bug-uri — e că scrie cod corect într-un spațiu de constraint-uri invizibil. acel spațiu se întâmplă să includă laptopul tău, mediul tău de test, și poate primii tăi o mie de utilizatori. Nu include cu siguranță "producție la scară."

Sistemele de tipuri aware de resurse, ca acest experiment Lean 4, indică spre un viitor unde "corect" înseamnă mai mult decât "logically right." Înseamnă "demonstrabil că rămâne în limitele care chiar există."

E un viitor worth building toward. Până atunci, ține datele de test aproape de dimensiunea production, și poate adaugă o notă extra în prompturi despre limitele alea de file descriptors.

Viitorul tău eu de on-call îți va mulțumi.