Da li Code Review ima smisla ako AI piše kod, a drugi AI ga proverava?

Ključne teze (Key Takeaways) – šta je najbitnije u ovom tekstu

AI Code Review već nije futuristički koncept. GitHub Copilot danas može automatski da pregleda Pull Request, analizira promene i ostavi konkretne predloge, dok GitLab ima Agentic Code Review koji razmatra strukturu repozitorijuma, međuzavisnosti fajlova i projektne instrukcije. GitHub je otišao još korak dalje i testira mogućnost da Copilot-ovo odobrenje, kada administrator to dozvoli, zadovolji Repository Rule koji zahteva odobren Code Review.

Istovremeno, AI sve češće piše upravo onaj kod koji drugi AI pregleda. Tu nastaje paradoks: ako jedan probabilistički sistem generiše kod, a drugi probabilistički sistem kaže da je kod dobar, da li smo dobili dve nezavisne kontrole – ili dve verzije iste vrste greške?

Odgovor nije jednostavan. AI Code Review ima ogroman smisao za:

• rutinske provere,

• očigledne bugove,

• Security obrasce,

• nedoslednosti,

• test coverage,

• dokumentaciju,

• standardizaciju,

• pretraživanje velikog Diff-a.

Ali AI ne poseduje automatski ono što je decenijama bilo najvrednije u dobrom Code Review-u: duboko razumevanje zašto promena uopšte postoji, kako se uklapa u sistem, koji poslovni kompromis pravi i šta će se dogoditi šest meseci kasnije kada taj kod mora da održava neko ko nije učestvovao u njegovom nastanku.

Zato budućnost Code Review-a verovatno nije „čovek ili AI“, već model u kojem AI pregledava gotovo sve, dok čovek odlučuje šta zaista zahteva ljudsku pažnju. I upravo tu Code Review možda postaje važniji nego ikada.

Nekada smo proveravali kod koji je napisao čovek. Sada proveravamo kod koji možda niko nije zaista „napisao“

Klasičan Pull Request ima poznatu logiku: developer razume problem, piše kod, pokreće testove i otvara Pull Request. Kolega ga pregleda, postavlja pitanja, autor objašnjava odluke, menjaju implementaciju i kod se spaja u glavnu granu (merge).

U ovom procesu Code Review ima najmanje dve funkcije. Prva je očigledna: pronaći problem. Druga je mnogo važnija nego što izgleda: preneti razumevanje sistema sa jednog čoveka na drugog. Reviewer ne proverava samo da li postoji Null Pointer Exception. On pita: Zašto smo ovo rešili upravo ovako? Zašto nova apstrakcija postoji? Da li već imamo sličnu funkcionalnost? Da li promena krši arhitektonski princip? Šta će se dogoditi kada količina podataka poraste deset puta? Ko će ovo održavati? Da li menjamo nešto što drugi tim koristi? Drugim rečima, Code Review nikada nije bio samo statička analiza sa ljudskim licem – bio je mehanizam kolektivnog razmišljanja.

Sada zamislimo drugi scenario. Developer napiše: „Implementiraj podršku za novi način plaćanja.“ AI agent pregleda repozitorijum, pronađe relevantne servise, promeni devet fajlova, napiše testove, pokrene ih, ispravi dve greške i otvori Pull Request. Drugi AI agent radi Code Review i pronalazi tri problema. Prvi agent ih ispravlja. CI je zelen. AI reviewer kaže: „Looks good.“ Šta tačno čovek sada treba da radi? To je pitanje koje će promeniti Software Engineering.

AI Code Review više nije pomoćna funkcija

GitHub Copilot Code Review već može automatski da pregleda Pull Requestove, komentariše probleme i predloži izmene koje se zatim mogu primeniti direktno. Automatski review može se pokrenuti nakon svakog novog push-a, a GitHub uvodi i različite nivoe Review Effort-a kako bi se dublja analiza koristila za kompleksnu logiku, Security-sensitive kod i promene kroz više servisa.

Još zanimljivije je to što GitHub već ima Public Preview za Copilot Approvals. Kada organizacija to eksplicitno omogući, Copilot može ostaviti Approve Review koji se računa prema zahtevanom broju odobrenja za merge. Ta mogućnost je po default-u isključena, ali sama činjenica da postoji pokazuje koliko se granica između „AI daje savet“ i „AI učestvuje u procesu odobravanja“ brzo pomera.

GitLab ide sličnim putem. Njegov Code Review Flow više nije samo generički LLM komentar. Agentic sistem analizira promene, projektni kontekst, strukturu repozitorijuma i zavisnosti kroz više fajlova (cross-file dependencies), a tim može definisati i sopstvene review instrukcije. Dakle, pitanje više nije da li će AI jednog dana raditi Code Review. Radi ga sada. Pravo pitanje je: šta ostaje čoveku kada AI postane prvi reviewer gotovo svakog Pull Request-a?

Prvo moramo razdvojiti Code Review od pronalaženja grešaka

Ovo je ključna razlika. Ako Code Review definišemo kao pronalaženje očiglednog problema u Diff-u, AI je već veoma koristan. Može pronaći neobrađen Edge Case, moguću Null vrednost, duplirani kod, pogrešno ime promenljive, potencijalni Security propust, problem sa rukovanjem greškama (Error Handling), nedostatak testa ili neusklađenost sa standardima kodiranja (Coding Standard).

Čoveku je dosadno da dvesta puta proverava isto pravilo, dok računaru nije. Tu nema mnogo romantike: ako Style Guide kaže da određeni API ne sme biti korišćen, nema razloga da Senior Engineer troši pažnju na njegovo ručno pronalaženje. Mašina to treba da radi. Problem je što dobar Code Review nikada nije bio samo lista grešaka.

Najbolji komentar u Code Review-u često nije: „Ovde je bug“

Može biti: „Zašto ovo uopšte radimo u ovom servisu?“ To je mnogo opasnije pitanje. Kod može biti sintaksno ispravan, tipiziran, pokriven testovima, bez očigledne Security ranjivosti, brz, čitljiv – i potpuno pogrešan arhitektonski izbor.

AI reviewer može proceniti kod koji vidi, ali ono što je često presudno jeste ono što ne postoji u Diff-u:

• Šta Product tim pokušava da postigne?

• Koji kompromis je ranije dogovoren?

• Koja Legacy odluka ima istorijski razlog koji nije dokumentovan?

• Koji drugi servis planira migraciju sledećeg meseca?

• Zašto kompanija neće da podržava određenu vrstu transakcije?

• Koji regulatorni zahtev menja tehnički dizajn?

Upravo tu se nalazi granica između inspekcije koda (Code Inspection) i inženjerske procene (Engineering Judgment). AI može biti izvanredan u prvom, ali drugo je mnogo teže.

Imamo još jedan problem: ko proverava proveravača?

Pretpostavimo da AI piše kod, a AI reviewer kaže da je kod dobar. Zašto verujemo reviewer-u? Zato što je drugi model? Druga instanca? Druga kompanija? Veći model?

Ako oba sistema dele slične trening obrasce, iste popularne konvencije i slične slepe tačke, nezavisnost možda nije onoliko velika koliko pretpostavljamo. To je dobro poznat princip iz bezbednosnog inženjeringa (Safety Engineering): dve kontrole imaju veću vrednost kada su zaista nezavisne. Ako avion ima dva senzora koji oba zavise od istog pogrešno kalibrisanog izvora, nemamo pravu redundansu, već dve potvrde iste greške.

Sa AI sistemima ovaj problem može biti suptilniji. Generator napravi naizgled elegantnu implementaciju, a reviewer je vidi kao poznat i uobičajen Pattern i odobri je. Međutim, oba sistema mogu propustiti domenski problem koji nije dovoljno zastupljen u njihovom kontekstu. Sve izgleda profesionalno, testovi prolaze, a greška putuje u produkciju. To je možda znatno opasniji scenario od očigledno lošeg AI koda.

„Skoro tačno“ je opasnije od očigledno pogrešnog

Stack Overflow Developer Survey 2025 daje veoma zanimljiv signal: čak 66% developera kao najveću frustraciju sa AI alatima navodi rešenja koja su „skoro tačna, ali ne sasvim“, dok 45% kaže da debugging AI-generisanog koda može trajati duže. Istovremeno, 46% developera aktivno ne veruje tačnosti AI outputa, naspram 33% koji mu veruju.

To je centralni problem AI Code Review-a. Potpuno besmislen kod lako odbacujemo, dok kod koji izgleda gotovo savršeno može proći mnogo dublje: nazivi su dobri, struktura je uredna, testovi postoje, komentari izgledaju profesionalno, a pattern deluje poznato. Reviewer – čovek ili AI – mora da bude mnogo pažljiviji da bi pronašao problem koji se krije ispod kvalitetne prezentacije. AI zato može proizvesti novu vrstu tehničkog duga: kod koji izgleda bolje nego što je zaista dobar.

Što AI više piše, Review postaje veći Bottleneck

Ovo se prirodno nadovezuje na širu promenu koju smo na ITNetwork-u već analizirali kroz AI-Augmented Agile. AI povećava sposobnost generisanja rada mnogo brže nego sposobnost organizacije da ga proveri.

DORA 2025 AI opisuje kao pojačivač (Amplifier): AI pojačava i dobre i loše karakteristike razvojnog sistema. Organizacija sa dobrom automatizacijom, platformama, testiranjem i jasnim workflow-om može dobiti veliki efekat, dok slab sistem može samo brže proizvesti više problema. Na ITNetwork-u smo upravo zato u tekstu o AI-Augmented Agile-u ukazali na novi paradoks: količina programerske aktivnosti može snažno porasti, dok povećanje stvarnih release-ova ostaje mnogo manje.

To je veoma važno za Code Review. Ako AI developer može da generiše deset Pull Requestova dnevno, a Senior Engineer može kvalitetno da pregleda tri, nismo dobili deset puta brži tim – dobili smo sedam Pull Requestova u redu čekanja (Queue). Dodajmo AI reviewer: sada ih možda preliminarno pregledamo svih deset. Da li smo rešili problem? Samo ako AI pregled zaista smanjuje količinu pažnje koju čovek mora da uloži. Ako čovek mora detaljno da proveri i kod i AI review, dobili smo još jedan sloj sistema, a ne nužno uštedu.

Budućnost nije jedan Code Review. Budućnost je Review Pipeline

Ovo je verovatno najrealniji model. Umesto da svaki Pull Request prođe kroz jednog čoveka koji pokušava da primeti sve, provera će imati više slojeva:

• Prvi sloj: Compiler, Linter, Static Analysis, Unit Tests, Integration Tests, Security Scanner, Dependency Scanner. To već imamo.

• Drugi sloj: AI Code Review. On može da traži šire probleme: logičke Edge Case-ove, neusklađenosti između fajlova, sumnjive promene, nedostajuće testove, potencijalne Security implikacije i probleme sa održavanjem (Maintainability).

• Treći sloj: Klasifikacija rizika (Risk Classification). Da li ovaj PR menja dokumentaciju, boju korisničkog interfejsa, platnu logiku, autentifikaciju, enkripciju, šemu baze podataka ili produkcionu infrastrukturu?

• Četvrti sloj: Ljudski pregled (Human Review). Ali ne isti nivo ljudskog pregleda za sve. To je ključna promena.

Nije svaki Pull Request vredan jednog sata Senior Engineer-a

Ako AI promeni typo u dokumentaciji, zašto Senior treba detaljno da pregleda promenu? Ako Dependency Bot podigne Patch verziju biblioteke, svi testovi prođu, Security Scan je čist i AI reviewer ne vidi problem – možda je potreban minimalan ljudski review.

Ali ako AI menja Authorization Layer? To je druga priča. Ako menja obračun poreza? Druga priča. Ako menja mehanizam za enkripciju korisničkih podataka? Potpuno druga priča.

Zato će sve važniji biti Risk-Based Code Review. Što je promena rizičnija, potrebno je:

• više ljudske pažnje,

• više nezavisnih kontrola,

• viši nivo iskustva (Seniority) reviewer-a,

• stroži Approval Gate.

Manje rizične promene mogu postati gotovo potpuno automatizovane. To nije ukidanje Code Review-a – to je njegovo sazrevanje.

AI Code Review zapravo može popraviti ljudski Code Review

Postoji tendencija da ljudski review idealizujemo, iako je realnost mnogo manje romantična: PR ima 1.800 linija, petak je u 16:40, reviewer ima još tri sastanka, autor kaže: „Hitno je za Release“, pa reviewer pogleda nekoliko fajlova, napiše „LGTM“ i spoji kod.

Čovek u procesu ne znači automatski kvalitet. Ljudski Code Review pati od umora, nedostatka vremena, pristrasnosti potvrđivanja (Confirmation Bias), socijalnog pritiska, površnog pregleda, prevelikih diff-ova i nedovoljnog domenskog znanja.

AI nema problem da u tri ujutru po stoti put proveri isto pravilo. Neće reći: „Ma poznajem Marka, sigurno je dobro.“ Neće mu biti neprijatno da ostavi 17 komentara Senior Engineer-u. Zato AI reviewer može biti odličan prvi filter koji oslobađa čoveka trivijalnosti, ostavljajući mu više vremena za ono što je zaista teško.

Najgori scenario je da čovek postane ceremonial reviewer

Ovo je mnogo realniji rizik. AI napiše kod, AI ga proveri, testovi prođu, dashboard je zelen, a čovek vidi 2.300 promenjenih linija i poruku: „AI review: no critical issues.“ Zatim samo klikne Approve.

Formalno imamo Human-in-the-Loop, ali praktično nemamo. Čovek je postao samo ljudski pečat (Human Rubber Stamp) čije prisustvo služi da organizacija može da kaže kako je čovek odobrio. Ali ako čovek nije realno mogao da razume promenu, odgovornost je postala fikcija.

To je možda najveći budući problem Human-in-the-Loop modela. Ne pitamo više: „Da li postoji čovek u procesu?“, nego: „Da li čovek realno ima dovoljno vremena, znanja i informacija da promeni odluku sistema?“ Ako nema – to nije kontrola, već ceremonija.

Approval nije isto što i odgovornost

Ovo postaje posebno zanimljivo zato što GitHub sada testira Copilot Approvals koji, kada su administrativno dozvoljeni, mogu zadovoljiti pravilo obaveznog odobrenja (required approval rule). Tehnički, review postoji, approval postoji i pravilo je zadovoljeno.

Ali organizaciono pitanje ostaje: ko odgovara ako promena izazove Incident? Copilot? GitHub? Developer koji je otvorio Pull Request? Tech Lead? Kompanija?

Odgovor iz perspektive stvarnog upravljanja sistemom i dalje je prilično jasan: organizacija ne može delegirati odgovornost algoritmu samo zato što mu je delegirala pregled. AI može izvršiti proveru, ali odgovornost (Accountability) ostaje ljudska i organizaciona.

„Drugi AI ga je proverio“ nije dovoljan argument

Zamislite Security Incident i analizu uzroka (Root Cause Analysis). Na pitanje kako je ovo prošlo Code Review, odgovor glasi: „Claude je napisao kod, Copilot ga je pregledao.“ Da li će to zvučati kao ozbiljna inženjerska kontrola? Ne bez dodatnog konteksta.

Koja verzija modela? Koje instrukcije? Koji kontekst repozitorijuma? Koji alati? Da li je model imao pristup Security Policy-ju? Koliko je Review Effort bio dubok? Da li je određeni tip promene zahtevao Human Approval i da li postoje revizorski tragovi (Audit Logs)?

Dakle, uvodimo još jedan potpuno novi problem: AI review mora i sam biti podložan reviziji (auditable). Nije dovoljno znati da je AI nešto proverio; moramo znati šta je proverio, na osnovu čega, sa kojim ograničenjima i ko je prihvatio taj nivo rizika.

Kod koji je napisao AI traži više konteksta, ne manje

Postoji paradoks: što više implementacije delegiramo mašini, to preciznije moramo opisati:

• Architecture Principles,

• Security Rules,

• Coding Standards,

• Domain Constraints,

• Forbidden Dependencies,

• Data Handling Rules,

• Definition of Done.

Inače AI radi ono što statistički izgleda razumno, a „statistički razumno“ nije isto što i „ispravno za našu kompaniju“. AI reviewer ima isti problem: ako ne zna da kompanija eksplicitno zabranjuje određeni način čuvanja podataka, ne može ga pouzdano primeniti. Zato će Repository Instructions, Architecture Decision Records (ADR), testovi, pravila i mašinski čitljive politike postajati sve važniji. Dobra dokumentacija više nije samo pomoć čoveku – postaje Context Infrastructure za AI.

To može konačno rešiti sindrom: „To samo Petar zna“

Godinama softverske kompanije funkcionišu na implicitnom znanju. Zašto je ovaj servis ovakav? „Pitaj Petra.“ Zašto ne smemo da menjamo ovu tabelu? „Zna Jelena.“ Zašto određeni API izgleda potpuno nelogično? „Duga priča.“

AI agent taj model teško podnosi jer ne može pouzdano koristiti znanje koje postoji samo u nečijoj glavi. To može naterati organizacije da konačno formalizuju odluke, ograničenja, izuzetke, arhitektonska pravila i Security zahteve. Paradoksalno, AI može poboljšati ljudsku inženjersku kulturu upravo zato što zahteva bolji kontekst.

Ali onda dolazimo do Context Poisoning problema

Ako AI zavisi od konteksta, šta se događa kada je kontekst pogrešan? Zastarela dokumentacija, pogrešan Architecture Decision Record, zlonamerna instrukcija, Prompt Injection u fajlu ili neproveren tekst iz tiketa mogu učiniti da AI reviewer bude savršeno racionalan u odnosu na potpuno pogrešan kontekst.

To je jedna od ključnih razlika između klasičnog Static Analysis-a i LLM pregleda: Linter ima relativno determinističko pravilo, dok AI interpretira. To daje ogromnu fleksibilnost, ali i novu površinu napada. Zbog toga AI Code Review treba tretirati kao Security komponentu, a ne samo kao alat za produktivnost.

Da li AI reviewer može pronaći ranjivost koju je AI developer napravio?

Naravno da može, ali to nije garancija. Jedan AI može pronaći grešku drugog, a isti AI može pronaći sopstvenu grešku kada dobije drugačiju instrukciju ili kontekst – to već koristimo kroz Critic modele, Self-Reflection, debate više agenata i druge tehnike.

Ali treba izbeći pogrešan zaključak: „Ako imamo dva modela, greška je rešena.“ Nije. Modeli mogu deliti iste slepe tačke, pogrešno razumeti specifikaciju, halucinirati istu pretpostavku, propustiti domenski kontekst i previše verovati testovima koje je takođe napisao AI.

Zato je prava odbrana raznovrsnost kontrola: AI review, testovi, Static Analysis, Runtime Observability, Security alati i ljudska procena. Nijedan mehanizam sam za sebe nije dovoljan.

Test koji je napisao AI može potvrditi pogrešnu AI pretpostavku

Ovo je veoma važan problem: AI dobije zahtev, pogrešno ga protumači, napiše implementaciju i zatim napiše testove na osnovu svog iskrivljenog razumevanja. Kod prolazi testove, a AI reviewer vidi uredan kod, dobre testove i sve zeleno. Ali i kod i test proveravaju pogrešnu interpretaciju zahteva.

To je zatvorena epistemološka petlja gde sistem sam sebi daje zadatak, sam ga rešava, sam definiše šta znači „tačno“ i sam potvrđuje da je uspeo. Ako čovek proverava samo tehnički output, problem može ostati nevidljiv. Zato Acceptance Criteria i stvarni poslovni ishod postaju još važniji kada implementaciju automatizujemo.

AI može proveriti da li smo dobro napravili pogrešnu stvar

To je možda najbolji opis problema. Software Engineering ne postavlja samo pitanje: „Da li kod radi?“, nego pre svega: „Da li smo napravili ono što treba?“

Prvo pitanje može biti veoma automatizovano, ali drugo je čisto produktno pitanje. Zamislite savršeno implementiranu funkcionalnost koju korisnici ne žele: kod je odličan, testovi savršeni, AI reviewer oduševljen, a komercijalni rezultat je nula. Zato Code Review ne sme postati zamena za Product Discovery, Architecture Review, modelovanje pretnji (Security Threat Modeling) i istraživanje korisnika. AI može ubrzati implementacioni sloj, ali ne rešava automatski pitanje svrhe.

Senior Engineer će manje loviti zareze, a više proveravati odluke

Ovo je optimističniji scenario. Danas Senior developer tokom pregleda koda troši vreme na imenovanja, sitne greške, nedostajuće testove, standardizaciju, ponavljanje šablona i očigledne bezbednosne probleme. AI može preuzeti veliki deo tog rada.

Šta ostaje Senioru?

• Arhitektura,

• Kompromisi (Trade-offs),

• Domenska ispravnost,

• Skalabilnost,

• Operabilnost,

• Dugoročna održivost,

• Međusistemski efekti.

Dakle, Code Review ne nestaje, već se penje jedan nivo apstrakcije više. To je možda jedan od zdravijih efekata AI-ja: Senior Engineer konačno prestaje da bude vrlo skup Linter.

Ali šta se događa sa juniorima?

Tu priča postaje neprijatnija. Code Review je decenijama bio jedan od glavnih mehanizama učenja: junior napiše kod, senior ostavi komentare, junior pita zašto, a senior objašnjava arhitekturu, imenovanja, kompleksnost, testiranje i obrasce dizajna. Godinu dana kasnije junior već razmišlja drugačije.

Ako AI napiše juniorov kod, drugi AI pregleda taj kod i automatski ga popravi – šta junior uopšte uči? Može učiti brže, ali samo ako je aktivno uključen. Ako proces postane: Prompt -> Agent -> AI Review -> Merge, izbacili smo važan krug učenja (Learning Loop). To kratkoročno može doneti mnogo veću produktivnost, ali dugoročno stvara manje ljudi koji zaista razumeju sistem.

Ko će pregledati AI kada Seniori odu u penziju?

Ovo zvuči kao senzacionalizam, ali zapravo nije. Senior nije postao senior čitanjem naslova „Senior Software Engineer“, već kroz hiljade grešaka, Code Review sesija, produkcione incidente, loše arhitektonske odluke, debagovanje, mentorstvo i projekte koji nisu uspeli.

Ako rutinski rad masovno automatizujemo, moramo osmisliti novi lanac razvoja znanja (Skill Pipeline). U suprotnom ćemo dobiti organizacije pune ljudi koji odlično orkestriraju agente, ali nedovoljno dobro razumeju ono što agenti proizvode. To je ozbiljan tehnološki rizik.

Možda čovek ponekad mora da pregleda kod čak i kada AI to radi bolje

Zvuči neefikasno, ali organizacije ne smeju da optimizuju samo današnji protok (Throughput). One moraju čuvati sposobnost sutrašnjeg razumevanja sistema. Pilot i kopilot mogu koristiti modernu automatiku, ali i dalje moraju znati da lete.

Slično tome, developer možda treba povremeno dubinski da pregleda i napiše kod ne zato što je u tom trenutku najbrži izvršilac, već zato što organizacija mora da održava ljudsku stručnost. Potpuno delegiranje može stvoriti atrofiju veština (Skill Atrophy) – a to je cena koju dashboard produktivnosti neće odmah pokazati.

Human-in-the-Loop zato nije dovoljno precizan koncept

Treba nam znatno preciznija podela uloga:

• Human-on-the-Loop: AI radi samostalno, dok čovek nadzire proces i interveniše po potrebi.

• Human-in-the-Loop: čovek aktivno i obavezno odobrava definisane kritične korake.

• Human-over-the-Loop: ljudi definišu pravila, upravljanje (Governance) i odgovornost na nivou čitavog sistema.

Nije svaka promena ista i ne treba isti čovek da pregleda ispravku u dokumentaciji, CSS margine, SQL migraciju, OAuth autentifikaciju i algoritam za odobravanje kredita. Zato će nivo ljudske kontrole morati da bude dinamičan.

AI-generated code treba da dobije Risk Score

Zamislimo svaki Pull Request sa automatskom procenom rizika:

• Nizak rizik (Low Risk): dokumentacija, testovi, formatiranje, manje izmene korisničkog interfejsa.

• Srednji rizik (Medium Risk): poslovna logika, API izmene, upiti ka bazi, promene zavisnosti (dependencies).

• Visok rizik (High Risk): autentifikacija, autorizacija, plaćanja, rukovanje osetljivim ličnim podacima (PII), enkripcija, konfiguracija infrastrukture, migracije kritičnih podataka.

Na osnovu toga sistem odlučuje: koliko AI reviewer-a se aktivira, koji modeli se pozivaju, koji automatski testovi se pokreću, koji inženjer preuzima pregled i koliko je odobrenja potrebno. To je mnogo racionalnije od današnjeg modela u kojem svaka promena formalno prolazi kroz isto pravilo.

Code Review će sve više postajati pitanje ekonomije pažnje

Ovo je verovatno najvažnija promena. AI proizvodi kod veoma brzo, dok ljudska pažnja ostaje strogo ograničena. Zato će buduća inženjerska organizacija morati pažljivo da bira: gde ljudska pažnja daje najveću vrednost?

Na slovnu grešku? Ne. Na potpuno standardni CRUD endpoint? Možda ne. Na promenu bezbednosnog modela? Apsolutno. Na novi šablon distribuirane transakcije? Verovatno. Na odluku koja može izazvati finansijski gubitak? Bez ikakve dileme.

Dakle, najveća vrednost AI Code Review-a nije da izbaci čoveka, već da spreči da čovek troši ograničenu pažnju na probleme koje mašina može pouzdano da filtrira.

I tu dolazimo do veoma nepopularne istine: većina današnjih Code Review-a verovatno je preskupa

Ne zato što Code Review nema smisla, nego zato što skup ljudski mozak često koristimo za banalne provere. Ako Senior Engineer sa deset godina iskustva proverava formatiranje, konvencije imenovanja, očigledan propust u null proveri ili nedostajući jedinični test – onda ne koristimo njegovu stručnost optimalno. To treba automatizovati.

Ali druga krajnost je podjednako loša: ako kažemo „AI je odobrio, spajaj kod“, onda smo automatizovali i ono što možda nikada nije trebalo potpuno automatizovati. Prava granica biće najvažniji inženjerski problem narednih godina.

DORA već upozorava: AI ne popravlja loš sistem

To je veoma relevantno i ovde. Izveštaj DORA State of AI-assisted Software Development 2025 zaključuje da AI primarno deluje kao pojačivač postojećih organizacionih karakteristika.

Ako kompanija već ima dobar CI/CD, jake testove, jasne arhitektonske principe, dobru dokumentaciju i kvalitetan proces pregleda, AI može dodatno ubrzati sistem. Ako kompanija ima slabe testove, ogromne Pull Requestove, loš ownership, slabu dokumentaciju i produkciju koju niko ne razume, AI će omogućiti da takva kompanija mnogo brže pravi još više promena. To nije transformacija – to je ubrzavanje haosa.

Zato AI Code Review nije dovoljan ako organizacija nema Definition of Good

AI može da proverava pravilo samo ako postoji neko definisano pravilo. Šta uopšte znači „dobar kod“? Čist kod (Clean Code)? Performanse? Čitljivost? Minimalan broj zavisnosti? Domain-Driven Design? Security-first pristup? Brzina razvoja?

Nekada su ti ciljevi u direktnom konfliktu. Savršen primer jeste duplikacija koda: AI može predložiti brzu apstrakciju, dok će senior možda reći: „Ne još.“ Zašto? Zato što dve stvari trenutno liče jedna na drugu, ali pripadaju različitim domenima i verovatno će se razvijati u potpuno različitim pravcima. To je iskustvena procena, a ne jednostavno pravilo, i tu inženjerska procena ostaje neprocenjiva.

Da li dva različita AI modela daju bolji Review?

Mogu dati. Jedan model generiše, drugi radi review, a možemo uključiti i treći model specijalizovan za bezbednost, što uvodi veću raznovrsnost. Ali to nije magično rešenje.

Multi-model review može smanjiti određene korelisane greške, ali značajno povećava trošak, kompleksnost, kašnjenje (Latency) i broj konflikata između preporuka. Šta ako jedan AI kaže „Approve“, a drugi „Critical Security Issue“? Ko odlučuje? Čovek. Vratili smo se na početak – i to uopšte nije loše. AI treba da smanji informacioni teret, a ne da ukloni ljudsku odgovornost.

Možda će AI reviewer postati advokat, a čovek sudija

Ovo je znatno korisnija mentalna slika:

• Jedan AI kaže: „Vidim sledećih sedam rizika.“

• Drugi AI navodi: „Tri nisu relevantna zbog ovog specifičnog konteksta.“

• Bezbednosni alat upozorava: „Ova promena povećava površinu napada (Attack Surface).“

• Sistem za testiranje javlja: „Sve funkcionalne provere prolaze.“

Čovek pred sobom dobija sažetu argumentaciju i presuđuje. Tada AI nije zamena za inženjersku procenu, već postaje sistem podrške pri odlučivanju (Decision Support System). To je mnogo zdravija uloga.

Agentic AI dodatno komplikuje priču

U prethodnim tekstovima na ITNetwork-u analizirali smo prelazak sa klasičnih chatbotova na Agentic AI – sisteme koji više ne čekaju samo prompt, već planiraju, koriste alate i samostalno izvršavaju zadatke.

Kada Coding Agent samostalno preuzme Issue, promeni kod, pokrene test, otvori Pull Request, pozove AI Code Review, primeni predlog reviewer-a i ponovo testira, dobijamo zatvorenu mašinsku petlju u kojoj čovek vidi samo finalni rezultat. To donosi brzinu, ali drastično smanjuje vidljivost procesa. Ako je bilo 14 iteracija pre finalne verzije, da li čovek zna šta se tačno dogodilo i da li treba da zna? Za trivijalan zadatak možda ne, ali za kritičan sistem verovatno da. Zato će opservabilnost (Observability) za AI agente postati važna disciplina, baš kao što je to danas praćenje mikroservisa.

Moramo moći da odgovorimo: šta je agent zapravo uradio?

Koji fajl je pročitao? Koju instrukciju je koristio? Koju komandu je pokrenuo? Koji test nije prošao? Zašto je promenio prvobitni pristup? Koje predloge reviewer-a je prihvatio, a koje je odbio?

Ako to ne možemo precizno da rekonstruišemo, imamo sistem koji može proizvoditi promene, ali nemamo sistem kojim možemo ozbiljno da upravljamo. To je posebno važno u finansijama, zdravstvu, kritičnoj infrastrukturi, državnim sistemima i bezbednosnim proizvodima. AI autonomija bez revizibilnosti (Auditability) je veoma opasan spoj.

„AI je napisao kod“ nije problem. „Niko ga ne razume“ jeste

Ovo je suštinska razlika. Nema posebne moralne vrednosti u tome da je čovek ručno otkucao svaku liniju u editoru. Kompajler takođe proizvodi mašinski kod koji čovek ne piše ručno, radni okvir generiše ogromnu količinu ponašanja, ORM piše SQL upite, a generatori koda prave klase. Automatizacija je oduvek bila normalan deo programiranja.

Problem nije poreklo koda. Problem je: da li organizacija razume ponašanje sistema dovoljno dobro da ga može održavati, menjati i popraviti kada stvari krenu loše? Ako je odgovor da – generisani kod nije inherentno loš. Ako je odgovor ne – nije mnogo bitno koliko je lepo Pull Request izgledao.

Šta bi ozbiljan AI Code Review proces trebalo da ima?

Pre svega, ozbiljan proces zahteva automatsku klasifikaciju rizika. Zatim:

• nezavisne testove (a ne samo one koje je generisao isti agent koji je pisao kod),

• rigorozno bezbednosno skeniranje,

• jasna arhitektonska pravila,

• instrukcije specifične za repozitorijum,

• detaljan revizorski trag (Audit Trail),

• obavezno ljudsko odobrenje za rizične promene,

• periodične dubinske provere (Deep Review) nasumično odabranih promena niskog rizika.

Zašto je ova poslednja stavka obavezna? Zato što svaki automatizovani sistem vremenom može razviti slepu tačku (Blind Spot). Ako nikada ne proveravamo ono što smo proglasili bezbednim, nećemo znati kada ta klasifikacija prestane da važi.

Najzdraviji model možda je „Trust, but continuously verify“

Stav da veštačkoj inteligenciji ne verujemo ništa uništava samu svrhu automatizacije. Ali stav da je model dovoljno dobar i da treba pustiti sve podjednako je opasan.

Rešenje je kontrolisana autonomija: što sistem duže pokazuje pouzdanost na konkretnoj klasi zadataka, to mu se poverava više autonomije. Međutim, kada se promeni model, repozitorijum, arhitektura, domen ili bezbednosni profil, autonomija se ponovo procenjuje. To je slično načinu na koji dobar tim gradi poverenje u novog kolegu: ne dajete mu prvog dana root pristup produkciji, ali mu ne proveravate zauvek svaku tačku i zarez.

Šta će se dogoditi sa pull requestom od 5.000 linija?

Nadajmo se da ćemo konačno priznati da je to kardinalna greška. To što AI može vrlo brzo da napravi ogromnu promenu ne znači da to i treba da radi. Mogućnost kvalitetnog pregleda (Reviewability) postaće još važnije inženjersko ograničenje pri dizajnu sistema.

Agentu treba zadati jasnu instrukciju: ne pravi najveću moguću promenu, već napravi najmanju proverljivu promenu koja ostvaruje definisani cilj. To je čist agilni princip: mali paketi rada (small batches), brza povratna sprega i ograničen opseg potencijalne greške (Blast Radius). Agentic AI ne čini te principe zastarelim – naprotiv, čini ih neophodnim.

Budućnost Code Review-a je verovatno manje komentara – ali težih pitanja

AI će bez muke uhvatiti detalje: nedostajući test, potencijalnu null referencu, nekorišćen uvoz ili funkciju koja duplira logiku. Čoveku preostaju ona suštinska i znatno teža pitanja:

• Da li ova apstrakcija pripada ovde?

• Šta će ovo uraditi našem operativnom modelu?

• Da li smo spremni da podržavamo ovu funkcionalnost narednih pet godina?

• Zašto uvodimo još jedan servis?

• Da li korisniku ovo zaista treba?

• Šta će se dogoditi kada padne zavisnost?

• Koji scenario otkaza (Failure Mode) nismo razmatrali?

To su bolja, dublja i neuporedivo skuplja pitanja.

Code Review možda konačno prestaje da bude linijski i postaje sistemski

Danas u pregledu gledamo linije koda (Diff). Sutra ćemo možda mnogo više posmatrati širu sliku: grafikon arhitekture, mapu zavisnosti, bezbednosni uticaj, telemetriju iz produkcije, istorijat incidenata, vlasništvo nad kodom, uticaj na testove i poslovnu kritičnost.

AI može povezati sve te podatke u sekundi. Tada Code Review više neće biti samo pitanje šta je promenjeno u ovih 300 linija, nego šta ova promena znači za sistem kao celinu. To je ogroman inženjerski napredak.

A gde je tu Agile?

Na ITNetwork-u smo pisali da agilnost osnažena veštačkom inteligencijom nije Scrum sa ChatGPT-om, već razvojni sistem u kojem AI ulazi u zatvorene petlje povratnih informacija kroz gotovo čitav životni ciklus softvera (SDLC). Code Review je savršena ilustracija tog toka: AI napiše kod, AI ga proveri, CI ga testira, telemetrija meri rezultate, sistem za incidente šalje povratnu informaciju, agent predlaže popravku, a čovek donosi stratešku odluku.

Ako je taj krug brz i pouzdan, organizacija može zaista postati agilnija. Ako samo generišemo više Pull Requestova, nismo postali agilniji – samo smo postali bolji u proizvodnji rada. A to nikada nije bila ista stvar.

I upravo zato Code Review neće nestati

On će se promeniti. Rutinski deo posla postaće gotovo potpuno automatizovan: AI će gledati svaki commit, svaki Pull Request i verovatno analizirati kod pre nego što developer uopšte zatraži review (GitHub već omogućava automatski pregled novih push-eva i draft verzija).

Ali što se više tehničkog izvršenja automatizuje, ljudska kontrola mora da se pomeri prema oblastima gde automatizacija nema potpunu sliku:

• Arhitektura,

• Domen,

• Bezbednost,

• Sam proizvod,

• Etika,

• Procena rizika,

• Dugoročne posledice.

Tada Code Review možda više neće značiti: „Čitao sam svaku liniju koda.“ Značiće: „Razumem šta ova promena radi, zašto postoji i koliki rizik nosi.“ To je viši, a ne niži standard.

Najopasnija budućnost nije ona u kojoj AI piše sav kod

Mnogo opasnija je ona u kojoj AI piše kod, drugi AI ga proverava, treći piše testove, četvrti odobrava spajanje, a ljudi prestanu da razumeju sistem. A onda sistem jednog dana prestane da radi. Tada inženjeri prvi put otvaraju haubu i shvate da godinama unazad niko nije stvarno gledao unutra.

Zato pitanje iz naslova ima prilično jasan odgovor: da, Code Review i dalje ima smisla kada AI piše kod, a drugi AI ga proverava. Ali nema više smisla raditi ga na isti, stari način.

Ne treba čovek da glumi Linter, ne treba da proverava svaku banalnost koju mašina pouzdano može da pronađe, niti sme da klikne Approve samo zato što AI kaže da je sve u redu. Njegova uloga postaje znatno teža: mora da proceni nešto što je mnogo teže automatizovati – da li promena ima suštinskog smisla.

AI može da proverava kod. Čovek mora da proverava sistem

Tu je možda najvažnija granica. AI Code Review može postati bolji od prosečnog čoveka u hiljadama lokalnih tehničkih provera. To nije pretnja pregledu koda, već oslobađanje Code Review-a od njegovog najdosadnijeg dela.

Ali to važi samo pod uslovom da organizacije ne naprave pogrešan zaključak da im čovek više nije potreban. Potreban je, samo ne tamo gde je bio:

• Manje: „Ovde nedostaje test.“ -> Više: „Zašto ova funkcionalnost uopšte postoji?“

• Manje: „Promenljiva ima loše ime.“ -> Više: „Da li smo upravo napravili arhitektonsku zavisnost zbog koje ćemo žaliti narednih pet godina?“

• Manje: „Linter je našao problem.“ -> Više: „Ako ovaj model pogreši, šta je najgore što može da se dogodi?“

To je budućnost review-a: AI proverava linije, a ljudi proveravaju odluke. Organizacije koje pomešaju te dve stvari možda će imati najbrže Pull Requestove u industriji – sve dok prvi ozbiljan incident ne pokaže punu cenu te brzine.

FAQ – AI Code Review i AI-generisani kod

Šta je AI Code Review?

AI Code Review je korišćenje AI modela za automatsku analizu promena u izvornom kodu. Sistem može tražiti bugove, Security probleme, nedostajuće testove, Style probleme i druge potencijalne nedostatke.

Može li GitHub Copilot da radi Code Review?

Da. GitHub Copilot može biti dodat kao reviewer Pull Request-a i automatski ostavljati komentare i predloge promena. Moguće je podesiti i automatski review novih Pull Requestova i Push-eva.

Može li AI već da odobri Pull Request?

GitHub ima Public Preview funkcionalnost u kojoj Copilot Approval, kada ga administrator eksplicitno omogući, može zadovoljiti određena Repository Approval pravila. Funkcionalnost je po default-u isključena.

Da li GitLab koristi AI za Code Review?

Da. GitLab Duo Agent Platform ima Code Review Flow koji agentno analizira promene, Repository Context i međuzavisnosti između fajlova.

Da li AI Code Review može potpuno da zameni čoveka?

Za određene Low-risk i rutinske promene nivo automatizacije može postati veoma visok. Za kompleksne, poslovno kritične, arhitektonske ili bezbednosno osetljive promene ljudska procena i odgovornost ostaju veoma važne.

Zašto AI koji proverava drugi AI može biti problem?

Oba sistema mogu imati slične slepe tačke, pogrešne pretpostavke ili nedostatak poslovnog konteksta. Dve AI provere zato ne treba automatski tretirati kao dve potpuno nezavisne garancije kvaliteta.

Da li developeri veruju AI-generisanom kodu?

Stack Overflow Developer Survey 2025 pokazao je da 46% ispitanika ne veruje tačnosti AI outputa, dok mu 33% veruje. Samo mali procenat prijavljuje veoma visok nivo poverenja.

Koji problem developeri najčešće imaju sa AI kodom?

U istom istraživanju 66% je navelo problem sa AI rešenjima koja su „skoro tačna“, ali ipak pogrešna, dok je 45% navelo da debugging AI-generisanog koda može oduzimati više vremena.

Šta je Human-in-the-Loop?

To je pristup u kojem čovek ostaje aktivan deo AI procesa i donosi ili odobrava određene kritične odluke.

Da li je dovoljno da čovek samo klikne Approve?

Ne, ako čovek nije realno razumeo promenu i nije imao mogućnost da ospori odluku. Formalno ljudsko odobrenje bez stvarne procene daje samo privid kontrole.

Šta je Risk-Based Code Review?

To je pristup u kojem dubina i vrsta review-a zavise od rizika promene. Dokumentaciona izmena ne zahteva isti nivo kontrole kao promena Authentication, Payment ili Encryption sistema.

Hoće li Senior developeri i dalje raditi Code Review?

Verovatno da, ali će se fokus sve više pomerati sa trivijalnih problema prema arhitekturi, domenskim pravilima, bezbednosti, kompromisima i dugoročnim posledicama.

Kako AI Code Review utiče na Junior developere?

Može ubrzati povratne informacije i učenje, ali postoji i rizik da junior izgubi važan Learning Loop ako AI automatski piše, pregleda i popravlja njegov kod bez aktivnog ljudskog mentorstva.

Da li testovi garantuju da je AI-generisani kod dobar?

Ne. Testovi mogu biti nepotpuni, a AI može napisati i implementaciju i testove na osnovu iste pogrešne interpretacije zahteva.

Da li AI Review treba koristiti zajedno sa Static Analysis alatima?

Da. AI Review nije zamena za Compiler, Static Analysis, Security Scanners, Unit Tests i Integration Tests. Najpouzdaniji model koristi više različitih i delimično nezavisnih kontrola.

Šta je najveća prednost AI Code Review-a?

Automatsko pregledanje velikog broja promena i uklanjanje rutinskog posla može omogućiti ljudskim reviewer-ima da više vremena posvete kompleksnim problemima koje je teže formalizovati.

Šta je najveći rizik?

Najveći rizik nije samo da AI propusti bug. Ozbiljniji dugoročni rizik je stvaranje sistema u kojem AI piše, proverava i menja većinu koda, dok ljudi postepeno gube dubinsko razumevanje softvera za koji su odgovorni.

Da li će Code Review nestati zbog AI-ja?

Verovatnije je da će se transformisati. Rutinski Code Review će postati mnogo automatizovaniji, dok će ljudski review biti koncentrisan na rizične promene, arhitekturu, poslovni kontekst i Engineering Judgment.

Kako će izgledati idealan Code Review u AI eri?

Najverovatnije kao višeslojni Review Pipeline: automatski testovi i Static Analysis, AI Code Review, procena rizika, dodatne Security provere i ciljani Human Review tamo gde ljudska procena donosi najveću vrednost.

Da li Code Review ima smisla ako AI piše kod, a drugi AI ga proverava?

Da – ali njegova svrha se menja. AI može preuzeti veliki deo tehničke inspekcije, dok ljudi treba sve više da proveravaju kontekst, arhitekturu, rizik, poslovni smisao i posledice promene.