Programerica otvara funkciju da popravi sitan bug prijavljen prošli tjedan. Funkcija ima 300 linija. Radi četiri potpuno nepovezane stvari odjednom. Očito je sastavljena od nekoliko AI-generiranih fragmenata, zalijepljenih jedan za drugi u različitim promptovima, bez ijednog komentara koji bi objasnio zašto je nešto napravljeno baš tako. Nitko u timu se ne sjeća da je ovu funkciju "napisao" — u smislu da je netko sjeo i smislio njezinu logiku. Netko ju je, u nekoliko navrata, zatražio od modela. A sad je netko drugi mora razumjeti u petnaest minuta prije nego što izađe hitna zakrpa.

Ovo nije rijedak scenarij iz noćne more. Prema recentnim analizama industrije, vibe coding — isporučivanje AI-generiranog koda na temelju intuicije umjesto pomnog pregleda — postao je zadani način rada za 85 posto developera. A ono što je krenulo kao obećanje nevjerojatne brzine razvija se u ono što inženjerski lideri sve češće zovu njegovim imenom naličja: vibe debugging. I pokazuje se da je teže popraviti kod koji nitko nije razumio dok je nastajao, nego napisati ga ispočetka.

Zašto je debugiranje AI koda drugačija vrsta problema

Kad ljudski programer napiše lošu funkciju, gotovo uvijek postoji trag razmišljanja koji se može rekonstruirati — možda pogrešna pretpostavka, možda prečac pod pritiskom roka, ali neka logika koja se, uz dovoljno vremena, može otkriti pitanjem "što je ova osoba pokušavala postići?". Kod AI-generiranog koda ta nit nestaje. Model ne slijedi namjeru u ljudskom smislu — on predviđa statistički najvjerojatniji sljedeći token na temelju obrasca u promptu i milijardama primjera koda koje je vidio tijekom treniranja. "Zašto" iza njegove odluke jednostavno ne postoji na način na koji postoji kod čovjeka, čak ni kad se model pita da objasni vlastiti kod — objašnjenje koje tada da samo je još jedna generacija teksta, ne stvarni uvid u proces koji je doveo do rješenja.

To čini debugiranje kvalitativno drugačijim zadatkom. Umjesto da tragate za pogreškom u nečijem (pa i vlastitom) rasuđivanju, tragate za pogreškom u statističkom obrascu koji nema unutarnju logiku koju biste mogli slijediti unatrag. Programer koji je navikao debugirati ljudski kod — postavljajući si pitanje "što je autor htio" — otkriva da to pitanje na AI kod jednostavno ne primjenjuje na isti način. Preostaje samo eksperimentiranje: mijenjanje, testiranje, nadanje.

Zašto se debugiranje AI koda razlikuje od debugiranja ljudskog koda Trag "zašto" — postoji li? LJUDSKI KOD "Što je autor htio?" — pitanje ima smisla Namjera se može rekonstruirati unatrag AI-GENERIRAN KOD "Što je model htio?" — pitanje bez smisla Samo statistički obrazac, nema namjere za otkriti

Rework rate: brojka koja tiho jede uštedu vremena

Vibe coding se prodaje kao ubrzanje — i kratkoročno, jest. Ali inženjerski lideri koji prate metrike duže od jednog kvartala primjećuju uzorak koji poništava taj dobitak: stopa "rework-a" — udio vremena developera potrošenog na popravljanje nedavno isporučenog koda — raste 30 do 60 posto unutar šest mjeseci od intenzivnog usvajanja AI alata. Drugim riječima, brzina kojom je kod napisan djelomično se, a ponekad i potpuno, pojede brzinom kojom se mora popravljati.

Ta brojka rijetko dospije u marketinške prezentacije alata za vibe coding, iz očitog razloga: teško ju je izmjeriti u prvih nekoliko tjedana korištenja, kad je dojam brzine najjači i najuvjerljiviji. Tek kad prođe kvartal ili dva, kad se nakupi dovoljno "brzo sklepanih" funkcija koje netko mora održavati, uprava i timovi počinju primjećivati da ukupna produktivnost ne raste onoliko koliko su brojke o "linijama koda po satu" obećavale. Analize ovog fenomena nazivaju ga "90-dnevnim obračunom" — trenutkom kad se tehnički dug nakupljen u prvom mjesecu vibe codinga konačno mora platiti.

Porast stope rework-a šest mjeseci nakon intenzivnog usvajanja AI alata Rework rate: prije i nakon 6 mjeseci vibe codinga bazna razina Prije usvajanja AI alata +30–60 % Nakon 6 mjeseci

Sigurnosne rupe koje niko nije tražio

Postoji i teži problem od produktivnosti, a to je sigurnost. Studije koje analiziraju AI-generirani kod dosljedno pronalaze da gotovo polovica cjelokupnog izlaza sadrži neku vrstu sigurnosne ranjivosti — od injection napada, preko propusta u autentifikaciji, do nenamjernog izlaganja osjetljivih podataka. Model koji generira kod ne "razmišlja" o sigurnosti na način na koji to radi iskusan programer koji je vidio desetke produkcijskih incidenata; on reproducira obrasce iz podataka na kojima je treniran, uključujući i obrasce koji su bili ranjivi u originalnim izvorima.

Problem se dodatno pogoršava jer se vibe-coded kod često isporučuje brže nego što sigurnosni pregled može pratiti. Kad je pisanje koda usko grlo, sigurnosna revizija ima vremena da bude temeljita. Kad AI napiše cijeli modul za nekoliko minuta, a tim je pod pritiskom da isporuči brzo jer je "brzina" bila cijela poanta korištenja alata, sigurnosni pregled postaje prva stavka koja se preskoči ili obavi površno. Rezultat je akumulacija ranjivosti koje čekaju da ih netko — u najboljem slučaju interni penetration test, u najgorem slučaju stvarni napadač — otkrije.

Rastući jaz: tko zapravo razumije što je isporučeno

Iz svega ovoga izranja podjela koja postaje sve oštrija unutar samih inženjerskih timova. Na jednoj strani su ljudi koji koriste AI alate za brzo generiranje koda, prihvaćaju rezultat na temelju osjećaja da "izgleda kako treba" i prelaze na sljedeći zadatak. Na drugoj strani su senior arhitekti sposobni pročitati, kritički procijeniti i po potrebi rastaviti AI-generirani kod komad po komad — sposobnost koja postaje sve rjeđa upravo zato što je sve manje ljudi koji su tu vještinu ikad morali razviti od nule.

Tvrtke počinju shvaćati da je osoba koja stvarno može čitati i razumjeti AI-generirani kod prestala biti "nice to have" i postala pitanje opstanka. Kad kritični sustav padne u tri ujutro, i kad je taj sustav sastavljen od desetak AI-generiranih fragmenata koje nitko u timu nikad nije pomno pregledao, jedina osoba koja može stvarno pomoći je ona koja zna zaroniti u kod bez oslanjanja na model da joj objasni vlastito djelo — jer, kao što smo vidjeli, model ni sam nema pristup pravom "zašto".

Kako izgleda razuman kompromis

Rješenje nije odbaciti vibe coding — brzina koju nudi je stvarna i vrijedna, pogotovo za prototipove, interne alate i projekte niskog rizika. Rješenje je razlikovati kontekste u kojima je "prihvati i idi dalje" prihvatljivo od onih u kojima nije. Kod koji dotiče plaćanja, osobne podatke, autentifikaciju ili bilo koji sustav gdje greška ima stvarnu cijenu, zaslužuje isti stupanj ljudskog pregleda kao i prije — bez obzira na to tko je (ili što je) napisao prvi nacrt.

Praktičan pristup koji sve više timova usvaja uključuje obveznu fazu "prijevoda": nakon što AI generira kod, netko u timu mora biti u stanju objasniti ga vlastitim riječima, kao da ga predstavlja kolegi. Ako to ne može — ako je kod crna kutija čak i za tim koji ga je "napisao" — to je signal da brzina isporuke nije bila vrijedna rizika koji nosi. Redovita revizija tehničkog duga, budžetirana unaprijed, a ne tek kad sustav počne pucati, druga je mjera koja razlikuje timove koji su vibe coding integrirali pametno od onih koji su njime jednostavno preplavljeni.

Vibe coding je promijenio brzinu kojom softver nastaje, i ta promjena je nepovratna. Ali brzina pisanja i brzina razumijevanja nisu ista stvar — a industrija tek uči, često na bolan način, da se druga ne može kupiti niti ubrzati na isti način kao prva. Za sad, najvrjednija vještina u sobi nije ona koja najbrže generira kod. Nego ona koja, kad kôd pukne u tri ujutro, zna zašto.

Izvori i dodatno čitanje