Vibe Coding i Agile: nova paradigma razvoja ili novi izvor tehničkog duga?

Ključne teze (Key Takeaways)

• Brzina izrade prototipa naspram produkcione spremnosti: Vibe Coding dramatično ubrzava validaciju hipoteza i jednokratni softver (disposable software). Ipak, činjenica da aplikacija lokalno „radi“ ne znači da zadovoljava produkcione standarde skalabilnosti, bezbednosti i pouzdanosti.

• Output ne znači nužno Outcome: Ako veštačka inteligencija samo uveća količinu generisanog koda i broj zatvorenih tiketa, tim dobija veći obim aktivnosti (activity), ali ne nužno i bolji poslovni ishod (outcome). Agile počiva na brzom učenju, a ne na gomilanju neproverenih linija koda.

• Pojava „duga razumevanja“ (Comprehension Debt): Najveći rizik nije loše formatiran kod, već postojanje funkcionalnog sistema čiju logiku, implicitne zavisnosti i domenske kompromise niko u inženjerskom timu više suštinski ne razume.

• Razvoj vođen specifikacijama (Spec-driven Development): Kako implementacija postaje jeftinija i brža, precizna specifikacija postaje najvredniji inženjerski artefakt. Budućnost pripada sinergiji jasne namere, autonomnih agenata i automatizovane verifikacije.

• Vibe Coding vs. Vibe Shipping: Slobodno eksperimentisanje u fazi prototipa je izuzetno korisno, ali puštanje neproverenog, generisanog koda u produkciju bez rigoroznih testova, revizije i opservabilnosti predstavlja direktan operativni rizik.

Sve počinje opasno prijatnom rečenicom: „Radi!“

Ako ste tokom poslednjih godinu dana intenzivnije koristili AI alate za razvoj, dobro vam je poznat ovaj scenario:

Zadate prompt:

„Napravi login sa Google nalogom, dodaj korisnički profil, dark mode i dashboard sa analitikom prodaje.“

AI model nekoliko trenutaka analizira zahtev, generiše fajlove, dodaje dependency biblioteke, postavlja backend rute, sklapa frontend komponente i pokreće testove. Pokrenete aplikaciju u browseru – i sve funkcioniše besprekorno.

Prototip za koji su ranije bili potrebni dani rada sada je pred vama za dvadesetak minuta. Teško je ne biti impresioniran.

Ipak, tu leži najveća zamka. Najrizičniji trenutak u primeni AI alata nije kada model ponudi očigledno neispravan kod – takav predlog se odmah odbacuje. Najopasniji trenutak nastupa kada rešenje radi dovoljno dobro da inženjeri prestanu da postavljaju ključna pitanja:

• Zašto je model odabrao baš ovu arhitekturu i biblioteku?

• Da li u sistemu već postoji modularna funkcija koja radi istu stvar?

• Šta se dešava kada eksterni servis ili baza nisu dostupni?

• Kako su konfigurisana prava pristupa i autentifikacioni tokeni?

• Da li predloženi test proverava stvarne granične slučajeve ili samo scenario koji je model sam sebi zadao?

Ukoliko tim ne zna odgovore, nije stvoren samo novi kod. Stvorena je obaveza koju će neko morati da razume i otplaćuje u budućnosti – a to je suštinska definicija tehničkog duga.

Šta je zapravo Vibe Coding?

Termin Vibe Coding popularizovao je Andrej Karpathy početkom 2025. godine. Koncept podrazumeva radikalnu promenu dinamike rada: umesto preciznog upravljanja implementacijom, inženjer prirodnim jezikom artikuliše nameru, prepušta LLM-u generisanje koda, pokreće rezultat i na osnovu novog feedback-a nastavlja iteraciju.

Martin Fowler s pravom povlači jasnu granicu između različitih pristupa korišćenju veštačke inteligencije:

Ako senior inženjer iskoristi AI da dobije nacrt funkcije, a zatim taj kod detaljno pregleda, refaktoriše, testira i uskladi sa postojećom bazom koda pre otvaranja Pull Request-a – to nije Vibe Coding. To je zreo AI-assisted inženjering.

Vibe Coding nastaje onog trenutka kada inženjerski stav postane:

„Napisao sam prompt, aplikacija vizuelno radi, idemo dalje.“

Idealno rešenje za prototipe, rizično za produkciju

Vibe Coding donosi izuzetnu vrednost u specifičnim fazama razvoja softvera. Za istraživanje i brzu proveru ideja, ovo je jedna od najproduktivnijih promena u novijoj istoriji programiranja:

• Interni alati i automatizacija: Izrada admin panela ili jednokratnih skripti za obradu podataka za sat vremena.

• Validacija korisničkog iskustva (UX): Kreiranje tri različite varijante interfejsa kako bi Product tim video funkcionalan koncept pre konačne odluke.

• Startup MVP: Preduzetnici mogu samostalno da testiraju tržišnu tražnju bez potrebe da troše mesece na tehničku realizaciju.

U ovoj fazi Vibe Coding i Agile funkcionišu u potpunoj sinergiji. Agile nalaže: napravi malu verziju -> testiraj sa korisnikom -> uči -> prilagodi se. Vibe Coding omogućava da se taj ciklus završi za jedno popodne.

Međutim, problem nastaje kada organizacija ne primeti trenutak u kojem prototip postaje proizvod.

Privremeni interni alat ubrzo počne da koristi ceo sektor. Nekoliko meseci kasnije povezuje se na produkcionu bazu. Godinu dana kasnije niko ne sme da ga restartuje niti promeni, jer je postao kritičan za poslovanje – a njegov temelj je za vikend generisao neko ko nije otvorio više od polovine kreiranih fajlova.

Output naspram Outcome-a: Agile nije puko kucanje koda

Agile metodologija nikada nije kreirana kako bi inženjeri proizveli maksimalan broj Story Point-a ili imali rekordan broj commit-a u jednom sprintu. Agile je empirijski odgovor na neizvesnost – njegova svrha je skraćivanje vremena između postavljanja poslovne hipoteze i validacije te hipoteze na tržištu.

Ako tim koristi AI samo da bi utrostručio količinu generisanog koda, napravljena je zamena teza: pomešani su obim aktivnosti (activity) i stvarni inženjerski napredak (progress).

Softverski repozitorijum nije protočni kanal kroz koji treba progurati što više linija koda. Ako promene ne donose stabilnu vrednost korisniku i ako tim ne može pouzdano da ih održava, brzina generisanja koda samo ubrzava gomilanje problema.

Comprehension Debt: Kada niko u timu ne razume sistem

Klasičan tehnički dug (Technical Debt) često je svesna inženjerska odluka: tim svesno pravi kompromis radi brzine isporuke, uz plan da se rešenje kasnije refaktoriše.

Kod Vibe Coding-a nastaje drugačiji, opasniji problem: Comprehension Debt (dug razumevanja).

Aplikacija radi, automatizovani testovi prolaze, Pull Request deluje uredno, ali u timu više ne postoji mentalni model o tome kako sistem zapravo funkcioniše ispod haube.

Tradicionalni tehnički dug:
„Znamo da ovo rešenje nije idealno, ali svesno pravimo kompromis radi roka.“

Comprehension Debt (Dug razumevanja):
„Sistem radi, ali niko u firmi tačno ne zna zašto radi niti šta će pući ako promenimo parametar.“

Kada nakon nekoliko meseci stigne novi zahtev, developer otvara fajlove koje niko u timu nije napisao, sa prekomernim apstrakcijama i zavisnostima koje niko nije planski uveo. Ako se taj problem ponovo rešava generisanjem novih slojeva AI koda preko onih nerazumevenih, baza koda gubi svaku koherentnost. To više nije samo inženjerski problem, već direktan gubitak intelektualnog kapitala organizacije.

Zašto AI ne rešava problem izgubljene namere (Intent)

Čest kontraargument glasi: „Zašto bi inženjer morao da pamti detalje implementacije ako napredni agent može za dva minuta da pročita ceo repozitorijum i objasni ga?“

AI sistemi mogu precizno da objasne šta određeni kod radi, ali retko mogu da rekonstruišu zašto je određena poslovna odluka doneta na specifičan način:

• Zašto korisnik sa određenim nivoom pretplate sme da pristupi samo specifičnom skupu podataka?

• Zbog kojih regulatornih zahteva refundacija zahteva tačno definisan redosled transakcija?

• Zašto je određena greška namerno tretirana kao tiho upozorenje, a ne fatalni prekid?

Kod beleži tehničku mehaniku, ali ne beleži prećutni poslovni kontekst. Kada se izgubi jasna namera (intent), tim ostaje sa savršeno sintaksno objašnjenim sistemom koji dugoročno rešava pogrešan problem.

Spec-driven Development: Odgovor na haotičan kod

Što je implementacija koda jeftinija i brža, specifikacija postaje skuplja i važnija.

Kada developeru treba dve nedelje da ručno napiše funkcionalnost, nejasnoće u zahtevima isplivaju tokom samog procesa kucanja. Kada AI isti zadatak generiše za petnaest minuta, pogrešna pretpostavka se materijalizuje u softver pre nego što je iko stigao da je dovede u pitanje.

Rešenje nije povratak u rigidni Waterfall model sa glomaznim specifikacijama od stotinu stranica. Rešenje je Intent Package – sažet, mašinski čitljiv skup parametara koji sadrži:

• jasan poslovni ishod i problem koji se rešava,

• precizne kriterijume prihvatljivosti (Acceptance Criteria),

• tehnička i bezbednosna ograničenja,

• eksplicitnu listu delova koda i konfiguracija koje agent ne sme da dira,

• način i automatizovane testove kojima će se rezultat verifikovati.

Pull Request od 3.000 linija nije produktivnost

AI modeli imaju izraženu sklonost ka hiperprodukciji koda. Agent bez problema može da izmeni 30 fajlova u roku od pet minuta, ali pregled takve promene od strane inženjera može trajati satima.

Ako tim pomoću AI-ja proizvede petnaest masivnih Pull Request-ova dnevno, a senior inženjeri mogu kvalitetno da analiziraju samo četiri, sistem nije ubrzan. Usko grlo je samo pomereno u fazu revizije (Review Queue).

Zato Code Review u eri veštačke inteligencije ne gubi svrhu, već menja fokus. Čovek više ne treba da gubi vreme na formatiranje, konvencije imenovanja ili sitne sintaksne greške – to rade linteri i AI modeli.

Ljudski Code Review mora da se fokusira na strateška pitanja:

• Da li predloženo rešenje nepotrebno komplikuje arhitekturu?

• Da li uvodimo novu biblioteku koju ćemo morati da održavamo godinama?

• Kako izgleda failure mode u vanrednim okolnostima?

• Da li ova promena donosi dugoročne performantne rizike?

Bezbednost i autonomija zasnovana na riziku (Blast Radius)

U vizuelnom delu aplikacije greška donosi loš prikaz na ekranu. U modulu za obradu plaćanja greška donosi finansijski gubitak. U autentifikaciji donosi kompromitovane podatke.

AI-generisan kod gotovo uvek izgleda izuzetno uverljivo: ima urednu strukturu, smislene nazive varijabli i prateće komentare. Ipak, bezbednost nije pitanje vizuelnog utiska.

Timovi ne treba da uspostavljaju jedinstvenu, krutu politiku za sav AI razvoj, već model autonomije zasnovane na riziku (Risk-Based Autonomy):

[NIZAK RIZIK / Visoka autonomija agenata]
- Jednokratne skripte, migracije šablona, interni prototipovi, UI varijacije.
- Verifikacija: Automatizovani testovi + brzi sanity check.

[SREDNJI RIZIK / Hibridni rad]
- Nove standardne CRUD funkcionalnosti, refaktoring izolovanih modula.
- Verifikacija: TDD pristup + obavezan standardni Code Review.

[VISOK RIZIK / Stroga kontrola i niska autonomija]
- Autentifikacija, platni promet, bezbednosne polise, izmene u arhitekturi baze.
- Verifikacija: Arhitektonsko odobrenje pre početka + rigorozan ljudski pregled.

Praktičan okvir: Kontrolisana evolucija od namere do produkcije

Kako spojiti brzinu Vibe Coding-a sa inženjerskom pouzdanošću? Rešenje leži u disciplinovanom toku u devet koraka:

1. Intent (Namera): Inženjer jasno definiše problem i željeni poslovni ishod.

2. Spec (Specifikacija): Definisanje proverljivih Acceptance Criteria i tehničkih ograničenja.

3. Small Batch (Mala promena): Agentu se zadaje najmanja smislena celina, bez zahvatanja celog repozitorijuma odjednom.

4. Automated Verification: Pokretanje testova, lintera, statičke analize i provere bezbednosti.

5. AI Review: Specijalizovani AI model vrši prvu trijažu koda i ukazuje na potencijalne propuste.

6. Human Risk Review: Inženjer vrši strateški pregled arhitekture, domenskih pravila i bezbednosti.

7. Controlled Deployment: Isporuka kroz CI/CD pipeline, uz primenu Feature Flags i Canary pristupa.

8. Observability: Praćenje realnog ponašanja, logova i telemetrije na produkciji.

9. Feedback: Povratne informacije iz produkcije vraćaju se kao osnova za sledeću iteraciju.

Zrele metrike umesto praćenja aktivnosti

Uvođenjem AI agenata Story Points, broj napisanih linija koda i broj zatvorenih taskova potpuno gube vrednost kao merila produktivnosti.

Timovi koji primenjuju AI moraju da se fokusiraju na DORA i sistemske metrike toka:

• Lead Time for Changes: Vreme od definisanja ideje do bezbednog puštanja u rad.

• Deployment Frequency: Učestalost kontrolisanih isporuka male vrednosti.

• Change Failure Rate: Procenat promena koje izazivaju probleme na produkciji.

• Deployment Rework Rate: Učestalost situacija gde se tek pušten kod mora odmah prepravljati.

• Review Latency: Vreme koje promena provede čekajući na verifikaciju pre spajanja na glavnu granu.

Kod je jeftiniji, loš softver podjednako skup

Vibe Coding jeste nova, moćna paradigma, ali istovremeno predstavlja i izuzetno efikasan akcelerator tehničkog duga. Obe tvrdnje su tačne.

Najveća korist veštačke inteligencije nastaje kada ona skrati put od ideje do učenja i povratne informacije od korisnika. Najveći rizik nastaje kada skrati put od nepromišljene ideje direktno do produkcije.

Zato pravo pitanje više nije da li treba koristiti AI za generisanje koda – odgovor je potvrdan svuda gde donosi uštedu vremena. Suštinsko inženjersko pitanje glasi:

Na kom mestu u procesu prestajemo da verujemo impresiji da aplikacija radi i počinjemo da zahtevamo proverljiv inženjerski dokaz?

AI nije učinio Agile principe zastarelim. Učinio ih je važnijim nego ikad. Kada kod nastaje brže nego što inženjeri mogu da ga pročitaju, najveća prednost tima više nije brzina generisanja koda, već disciplina da prepozna koja rešenja ne sme da pusti u sistem.

Često postavljana pitanja (FAQ)

Šta je Vibe Coding?

Vibe Coding je pristup razvoju softvera u kome programer prirodnim jezikom opisuje šta želi da postigne, dok AI model preuzima većinski deo implementacije. U užem smislu, inženjer proverava samo krajnje ponašanje aplikacije, bez obaveznog čitanja i detaljnog razumevanja svake linije koda.

Koja je razlika između Vibe Coding-a i AI-assisted razvoja?

Kod AI-assisted pristupa programer zadržava punu kontrolu, čita svaki diff, refaktoriše predloge i piše testove. Kod Vibe Coding-a fokus je na brzom rezultatu i poverenju u model, često uz preskakanje dubinske analize implementacije.

Da li je Vibe Coding primenjiv na produkcione sisteme?

U svom čistom obliku – nije preporučljiv. Odličan je za prototipe, testiranje ideja i jednokratne skripte. Za dugovečne produkcione sisteme neophodna je primena inženjerske discipline: specifikacija, automatizovano testiranje, Code Review i sigurnosna verifikacija.

Šta je Comprehension Debt (dug razumevanja)?

To je stanje u kome baza koda i njena kompleksnost rastu brže od sposobnosti inženjera da održe mentalni model o funkcionisanju sistema. Aplikacija prividno radi, ali niko u timu ne razume suštinski zašto radi, što svaku narednu promenu čini visoko rizičnom.

Kako Test-Driven Development (TDD) pomaže u radu sa AI-jem?

TDD postavlja jasne granice: inženjer prvo definiše očekivano ponašanje kroz testove, a zatim agent generiše implementaciju koja te zahteve mora da ispuni. Time se smanjuje verovatnoća da model unese nepredviđene i netestirane dizajnerske odluke.

Može li AI pomoći u smanjivanju postojećeg tehničkog duga?

Da. AI agenti su izuzetno efikasni u rešavanju rutinskih inženjerskih zadataka: ažuriranju zastarelih API poziva, migracijama biblioteka, pisanju testova za postojeće module i standardizaciji dokumentacije.