Autor: Ivan Čorković, Aircash, Backend Development Team Lead | Software Engineering

Ni revolucija, ni varanje — samo alat koji treba znati koristiti.

Razgovor o AI alatima u developmentu 2025. godine teži k polarizaciji. Jedni misle da su LLM-ovi varanje — doping za programere koji ne žele razmišljati. Drugi tvrde da je to kraj tradicionalnog razvoja softvera i da će “prompt engineers” zamijeniti programere. Istina je dosadnija od oboje: to je alat koji radi neke stvari dobro i neke loše, kao svaki alat koji je ikad ušao u razvoj softvera.

Htjeli smo to zapisati na način koji ne glorificira ni ne odbacuje — nego pokušava biti precizan.

Predrasude s obje strane — i zašto su pogrešne

Koristiš li AI za kod ili ne, imaš predrasudu. Oni koji ne koriste misle da je to varanje. Oni koji koriste misle da je to revolucija. Predrasude su uglavnom pogrešne, ali iz krivih razloga.

“Ne učiš ako koristiš AI” — učiš, samo drugačije. Manje pamtiš API signature koji se mijenja svakih šest mjeseci, više razmišljaš o dizajnu rješenja. Razlika između juniora koji koristi AI i seniora koji koristi AI nije alat — nego kapacitet da prepoznaju kada je odgovor koji dobiju netočan ili opasan.

S druge strane, “AI piše kod brže od tebe” može biti istina za izoliranu funkciju, ali ne za sustav. Model ne zna zašto ste izabrali taj framework, ne zna što ste prošli tjedan odlučili odbaciti i zašto. Svaki razgovor počinje od nule — i kad pogađa, pogađa uvjerljivo, što je opasnije od očitog neznanja.

Gdje AI stvarno pomaže

Delegiranje dosadnog posla je legitimna i korisna primjena. Konkretno:

• Boilerplate— standardni CRUD endpointi, DTO klase, Swagger anotacije. Posao koji oduzima vrijeme ali ne zahtijeva kreativno razmišljanje. AI ga radi brzo i dovoljno točno.
• Unit testovi za trivijalne funkcije— pisanje testova za funkcije koje konvertiraju, parsiraju ili formatiraju podatke. Model to radi solidno.
• Dokumentacija— ono što ionako nitko ne napiše pravovremeno. Generiranje JSDoc komentara, README-a za module, OpenAPI specifikacija iz postojećeg koda.
• Onboarding u tuđi kod— “Objasni mi što radi ovaj handler” ili “Koji su entry pointi ove aplikacije” može uštedjeti sate čitanja nepoznatog koda.
• Regex i formatni problemi— umjesto pet minuta guglanja Stack Overflowa, pitanje od jedne rečenice.

Zajednički nazivnik svih ovih slučajeva: zadatak je dobro definiran, provjera outputa je brza, i greška ima nizak trošak. Što više ovih uvjeta pada, to manje ima smisla slijepо se oslanjati na model.

Gdje AI zakaže

Sve za što trebaš kontekst koji model nema:

• Arhitekturalne odluke— model ne zna ograničenja vaše infrastrukture, ne zna koja je odluka već bila diskutirana i odbijena, ne razumije organizacijske faktore koji utječu na tehnički odabir.
• Debugging koji zahtijeva razumijevanje cijelog sustava— “Zašto ova funkcija vraća null u produkciji ali ne u testu” nije pitanje za model koji vidi samo isječak koda. Race conditionsi, state management problemi, timing issues — sve to zahtijeva holistično razumijevanje.
• Procjena tradeoffova— “Je li bolje koristiti Redis ili in-memory cache” ovisi o vašem load patternu, budžetu i SLA-ovima. Model može nabrojati prednosti i mane, ali preporuku ne može dati bez konteksta koji vi imate a model nema.
• Sigurnost i compliance— model može generirati kod koji izgleda siguran ali ima suptilne ranjivosti. Sigurnost zahtijeva razumijevanje deployment konteksta, regulatornih zahtjeva i threat modela specifičnog za vaš sustav.

Netočan odgovor koji zvuči sigurno je gori od pogreške koja je očigledna.

Cijena nije samo novčana

Tokeni se troše. Na jednostavnim zadacima zanemarivo, na kompleksnim brzo postaje skupo. Ali monetarni trošak je samo jedan aspekt.

Drugi trošak je kognitivni: svaki razgovor počinje od nule. Model nema memoriju projekta. Svaki novi kontekst koji mu moraš objasniti je trošak — tvog vremena i tokena. Timovi koji dobro koriste AI uče biti precizni: jasni promptovi, relevantan kontekst, konkretni primjeri. Ista disciplina koja čini dobar kod čini dobar prompt.

Treći trošak je povjerenje: ako model griješi i ti to ne primjećuješ, greška ulazi u produkciju pod tvojim imenom. Code review ostaje obvezan, ne opcija. Senior koji koristi AI bez reviewiranja outputa nije brži — samo je brže pogrešan.

Kako to izgleda u praksi — iz Aircasha

U Aircashu koristimo AI alate kao dio standardnog development workflowa. Konkretno, to znači da model nosi teret pisanja inicijalne verzije koda za dobro definirane zadatke — boilerplate, testove, dokumentaciju. Developer nosi razumijevanje i review.

Naučili smo nekoliko stvari kroz korištenje:

• Specifikacija mora postojati prije prompta. Ako ne možeš jasno opisati što funkcija treba raditi, model neće pogoditi — i uglavnom to neće ni pokušati reći, nego će generirati nešto što izgleda ispravno ali nije.
• Output se uvijek reviewira kao da je napisao junior developer kojeg tek upoznaješ. Jer u biti jest — model nema kontekst tvog projekta.
• Postoje domene gdje AI jednostavno ne koristimo za generiranje koda: sigurnosno-kritični dijelovi, kompleksna business logika, integracije s reguliranim sustavima. Ne jer je zabranjen — nego jer trošak reviewiranja i mogući trošak pogreške premašuju benefit brzine.

Ovo nije ideološka pozicija. To je cost-benefit analiza koja se mijenja ovisno o kontekstu — i za svaki novi alat koji uđe u stack, morate je napraviti iznova.

Zaključak: disciplina ostaje tvoja

Model nosi brzinu, ti nosiš razumijevanje. Ovo nije figura govora — to je podjela rada koja zahtijeva da znaš koji je čiji posao u svakom trenutku. Ako zaboraviš koji je čiji posao, dobit ćeš brz i samopouzdan krivi odgovor.

AI u developmentu nije ni varanje ni revolucija. To je alat koji pojačava onoga koji ga koristi — u dobrom i lošem smjeru. Ako razumiješ što radiš, bit ćeš brži. Ako ne razumiješ, bit ćeš brže pogrešan.

Hype prođe. Razumijevanje ostaje.