Da li Code Review koji radi AI ima smisla ako je i kod napisao AI?

AI napiše kod. Drugi AI pronađe problem. Treći AI ga popravi. Testovi prođu. Čovek pogleda zeleni ekran i klikne Approve.

U kom trenutku smo prestali da radimo Code Review, a počeli samo da formalno potpisujemo odluke sistema koji više ne razumemo dovoljno dobro?

Key Takeaways – šta je najbitnije u ovom tekstu

AI Code Review više nije eksperimentalna funkcija na marginama Software Development-a. Tokom 2026. godine postao je sastavni deo ozbiljnih razvojnih workflow-a. GitHub Copilot Code Review danas koristi agentsku arhitekturu (agentic architecture), može da prikuplja širi kontekst repozitorijuma, koristi više nezavisnih review agenata i modele različitih provajdera, automatski proverava nove commit-e, zatvara sopstvene komentare kada su problemi rešeni, a administrator čak može da mu omogući da formalno odobri Pull Request.
Autonomna petlja je već stvarnost. GitHub Copilot coding agent već može da napiše promenu, zatim pokrene Copilot Code Review nad sopstvenim radom, prihvati povratne informacije, popravi patch i tek onda pozove čoveka na pregled. Scenario iz naslova više nije hipotetički: AI piše -> AI pregleda -> AI popravlja -> čovek odobrava.
Višeslojna automatizacija stvara privid apsolutne sigurnosti. Vrlo lako možemo dodati još slojeva: AI generiše testove, AI pokrene Static Analysis, AI Security agent proverava ranjivosti, AI reviewer pročita diff, AI popravi nalaze, a drugi AI ponovo radi review. Na kraju developer dobije Pull Request na kojem sve svetli zeleno. Upravo tada nastaje najvažnije pitanje: da li čovek još uvek stvarno preuzima odgovornost za kod ili je njegov Approve postao samo proceduralni ritual?
Najnoviji benchmark podaci otkrivaju i snagu i granice ovih sistema. Microsoft Research je u oktobru 2026. objavio benchmark sa 1.000 review zadataka iz 98 open-source repozitorijuma i još 800 zadataka iz industrijskih repozitorijuma. Najbolji review agent uhvatio je 71,9% ljudski potvrđenih bugova među svojih pet najvažnijih komentara, dok je samo pet meseci ranije prethodna generacija modela bila na 47,7%.
Napredak je ogroman, ali 71,9% nije 100%. Najbolji sistem i dalje nije pronašao svaki bug, a posebno je slabiji kod kompleksnih promena, non-local reasoning-a, problema koji zahtevaju širi projektni kontekst i proprietary codebase-a u kojima istorija i poslovne odluke nisu eksplicitno zapisane.
Prava uloga AI pregleda nije dokazivanje ispravnosti, već filtriranje. AI Code Review definitivno ima smisla čak i kada je kod napisao AI, ali iz potpuno drugog razloga nego što se često pretpostavlja. Njegov cilj nije da dokaže da je AI-generated code ispravan, već da bude još jedan nezavisan filter u sistemu kontrole. Problem nastaje kada počnemo da taj filter tretiramo kao zamenu za Engineering Judgment – tu AI-native razvoj ulazi na mnogo klizaviji teren.

Prvo važno pitanje: da li dva AI-ja znače dve nezavisne provere?

Na prvi pogled deluje da je odgovor potvrdan. Agent A napiše kod, a Agent B ga proverava. To zvuči gotovo identično klasičnoj situaciji u kojoj developer A napiše kod, a developer B ga pregleda. Ipak, te dve situacije nisu nužno iste.

Dva ljudska developera imaju različito iskustvo, različita mentalna objašnjenja sistema, različite pretpostavke, različita znanja o kompaniji i različitu istoriju sa projektom. Naravno, i dva AI modela mogu imati različite slepe tačke (blind spots). GitHub je upravo zbog toga uveo Max Code Review, gde više nezavisnih review agenata koristi modele različitih provajdera, polazeći od ideje da kombinovanje različitih modela može da uhvati probleme koje jedan model propušta.

To je zdrava logika, ali nije savršena nezavisnost. Različiti LLM-ovi često dele slične trening korpuse (training corpora), slične programske obrasce (programming patterns), slične javne izvore i sličnu statističku predstavu „dobrog koda“. Zbog toga mogu napraviti različite greške, ali mogu i kolektivno prevideti isti problem. To je ono što u bezbednosti i sistemskom dizajnu nazivamo correlated failure (korelisani kvar). Ako tri sistema razmišljaju na sličan način, tri potvrde nisu nužno tri potpuno nezavisna dokaza.

AI može da potvrdi sopstvenu zabludu

Zamislimo jedan jednostavan, svakodnevni scenario. AI coding agent dobije zahtev: „Dodaj automatski refund ako payment provider vrati određeni status.“

Agent pogrešno protumači poslovno pravilo i napiše:

Python

if status == FAILED:
    refund()

Ovakav kod je čitljiv, dobro strukturisan, testiran, idiomatski i bez očiglednog bezbednosnog problema. Zatim drugi AI reviewer pregleda diff. Šta on vidi? Tehnički potpuno korektan kod, pa bez zadrške može da zaključi: „Looks good.“ Treći agent proveri testove i svi prolaze bez greške.

U čemu je onda problem? Stvarno poslovno pravilo je glasilo: refund se pokreće samo ako je transakcija naplaćena, ali fulfilment nije izvršen. Ceo automatizovani sistem je savršeno implementirao pogrešnu početnu pretpostavku.

To je ključna razlika koju moramo razumeti. AI Code Review vrlo dobro može da proveri pitanje: „Da li kod radi ono što izgleda da treba da radi?“ Mnogo teže proverava suštinsko pitanje: „Da li uopšte radimo pravu stvar?“

Code Review nikada nije bio samo pronalaženje bugova

Ovu činjenicu u praksi često zaboravljamo. Ako Code Review svedemo isključivo na mehaničke provere – pronađi null pointer, pronađi race condition, pronađi SQL injection, pronađi nedostatak testa ili dupliran kod – AI već postaje veoma moćan reviewer. GitHubova dokumentacija i razvoj Copilot Code Review-a upravo su fokusirani na correctness, security, maintainability i architectural integrity.

Međutim, najbolji ljudski Code Review često počinje sasvim drugačijim pitanjima:

„Zašto je ova promena uopšte napravljena ovako?“
„Zašto ovo pripada ovom servisu?“
„Zašto pravimo novi dependency i zašto menjamo public contract?“
„Šta se događa sa starim klijentima?“
„Da li je Product tim zaista želeo ovakvo ponašanje?“
„Šta se dešava ako regulator promeni uslov?“
„Zašto uopšte rešavamo problem kodom umesto promenom poslovnog procesa?“

Ovo nisu pitanja sintakse. To je Engineering Judgment (inženjerska procena).

Najbolji reviewer često pronalazi problem koji nije u diff-u

Ovo je verovatno najvažnija suštinska razlika između mašine i iskusnog inženjera. AI reviewer uglavnom kreće od samog diff-a, repozitorijuma, instrukcija, testova i eventualno povezanih sistema. GitHub sada dozvoljava review agentu da preko MCP servera čita issue trackere, dokumentaciju, service catalogs i druge izvore, čime se taj kontekst značajno širi.

Iako je to veliki tehnički napredak, ni tada nije garantovano da sistem zna šta je CTO rekao na sastanku prošle nedelje, koju migraciju drugi tim planira sledećeg meseca ili koji klijent ima nestandardni ugovor. Takođe, sistem ne može da zna koja legacy odluka postoji zato što je pre pet godina došlo do velikog produkcionog incidenta, niti koji je performance trade-off namerno prihvaćen.

Dobar senior reviewer poseduje ogromnu količinu prećutnog znanja (tacit knowledge) koje često nikada nije formalno zapisano. AI može imati pristup ogromnoj količini teksta, ali ne može da zna ono što organizacija nikada nije zabeležila.

To je argument za bolju dokumentaciju, ne protiv AI-ja

Ovde dolazimo do zanimljivog obrta. Možda problem zapravo ne glasi: „AI ne zna kontekst.“ Možda pravi problem glasi: „Kompanija nikada nije sistematski zapisivala kontekst.“

Ako ključna arhitektonska odluka postoji samo u glavi jednog seniora, organizacija već ima ozbiljan strukturni problem – sa AI-jem ga samo jasnije vidimo. Zato će AI-native razvoj neminovno povećati značaj eksplicitnih artefakata kao što su:

Architecture Decision Records (ADR)
Machine-readable coding standards
Service catalogs i API contracts
Structured requirements i testable policies

Što više procesa delegiramo AI agentima, to više znanja organizacije mora postati eksplicitno. Na portalu ITNetwork to smo već povezali sa konceptom Agile Architecture i idejom da arhitektura treba da bude proverljiva kroz jasna pravila (rules), fitness funkcije i dokumentovane odluke. AI jednostavno ne može pouzdano da poštuje pravilo za koje organizacija nikada nije jasno zapisala da postoji.

„AI je napisao kod“ nije najveći problem

Mnogo veći problem glasi: niko ga nije stvarno pročitao. To su dve potpuno različite stvari.

Softverska industrija odavno prihvata automatski generisan kod. Compiler generiše mašinski kod, ORM generiše SQL upite, framework generiše scaffolding, a OpenAPI generator pravi client biblioteke. Nema nikakve posebne moralne vrednosti u tome da je čovek ručno otkucao svaki karakter.

Dakle, pravo pitanje nije: „Da li je kod napravila mašina?“ Pravo pitanje glasi: „Da li organizacija dovoljno razume ponašanje sistema da može da preuzme odgovornost za njega?“ Ako je odgovor potvrdan, poreklo koda je sekundarno. Ako je odgovor negativan, imamo ozbiljan problem čak i kada svi testovi prolaze.

AI-generated kod ima drugačiji profil grešaka

Velika analiza iz 2025. godine obuhvatila je više od 500.000 Python i Java uzoraka i upoređivala kod koji su pisali ljudi sa kodom koji je generisao AI. Rezultati nisu pokazali pojednostavljen zaključak da je AI kod lošiji, već da ima potpuno drugačiji profil problema.

AI kod je u proseku bio jednostavniji i repetitivniji, češće je sadržao neiskorišćene konstrukte i hardcoded debugging elemente, dok je ljudski kod imao više strukturalne kompleksnosti i maintainability problema. Posebno važan nalaz bio je znatno veći broj visoko rizičnih bezbednosnih ranjivosti (high-risk security vulnerabilities) u uzorcima koje je generisao AI.

To znači da AI Code Review ne treba dizajnirati kao puku kopiju tradicionalnog pregleda koda. Treba ga ciljano usmeriti upravo na one tipove grešaka koje AI generacija statistički češće pravi.

AI Review možda najbolje radi ono što ljudi najmanje vole da rade

Ponavljajuće provere, usklađenost sa coding standardima, nedostajući error handling, očigledni security smells, izostavljeni testovi, pogrešna upotreba API-ja i problemi sa zavisnostima (dependencies) – sve su to zadaci izuzetno pogodni za automatizaciju.

Čovek ne mora po dvesta puta da piše isti komentar: „Ovaj input nije validiran.“ Ako mašina može pouzdano da pronađe takav propust, neka ga pronađe. Nema razloga da romantizujemo rutinski deo ljudskog Code Review-a. GitHub čak preporučuje workflow u kojem Copilot pregleda Draft PR u ranoj fazi, uklanja jednostavnije correctness i maintainability probleme, pa se Pull Request tek onda šalje ljudskom reviewer-u. To ima mnogo smisla: AI postaje prvi filter, a čovek dobija znatno čistiji diff.

Problem nastaje kada prvi filter postane jedini filter

Zamislimo situaciju u kojoj menadžment vidi sledeću statistiku: AI reviewer hvata veliki broj bugova, dok Human Review vidno usporava isporuku (delivery). Tada se postavlja naizgled logično pitanje: „Zašto nam uopšte treba obavezni čovek?“

Put ka potpunoj automatizaciji obično ide postepeno:

Prvo uvodimo human review samo za high-risk PR.
Zatim ga sužavamo samo na security-sensitive promene.
Nakon toga čovek ulazi u igru samo kada AI prijavi problem.
Na kraju, Copilot approval postaje dovoljan za merge.

Tehnički gledano, GitHub danas već dozvoljava da administratorski uključeno Copilot odobrenje zadovolji repository required-approval pravilo. Infrastruktura za praktično „lights-off“ development (razvoj bez upaljenog svetla, odnosno bez ljudskog prisustva) već nastaje. Ključno pitanje glasi: da li je organizaciona odgovornost spremna za to?

Microsoft je upravo testirao ideju „lights-off“ software factory

Naziv Microsoftovog istraživanja gotovo je savršen za ovu raspravu: „When Should a Software Factory Be Lights-Off?“ Ideja iza studije je jednostavna – coding agent generiše kod, review agent ga proverava, pa se postavlja pitanje zašto bi čovek morao da bude deo svakog koraka.

Rezultati su impresivni, ali veoma korisno prizemljuju tržišni hype. Najbolji review sistem pronašao je 71,9% bugova u top-5 komentara. To je ozbiljan rezultat, ali 71,9% i dalje nije 100%. Još važnije, performanse osetno opadaju kada bug zahteva širi kontekst, kompleksno rezonovanje ili razumevanje specifičnih proprietary sistema.

Drugim rečima: što je promena lokalnija i formalnija, AI reviewer je jači; što je problem sistemskiji i kontekstualniji, ljudska procena postaje vrednija. To je izuzetno korisna granica za svakodnevnu praksu.

Dakle, ne treba svaki PR isti nivo Human Review-a

Ovo je možda najpraktičniji zaključak celog procesa. Zašto bi senior inženjer trošio 20 minuta svog vremena da detaljno pregleda preimenovanje promenljive, ažuriranje zavisnosti, generisani DTO ili jednostavan unit test? Verovatno ne mora.

Sa druge strane, izmena authentication flow-a, logike plaćanja, sistema dozvola (permissions), deljenih biblioteka (shared libraries), migracije podataka ili javnog API-ja nosi potpuno drugačiji nivo rizika. GitHub je upravo iz tog razloga uveo različite nivoe napora pri pregledu (review effort levels), uključujući Max režim za promene sa većim rizikom, poput autentifikacione logike ili deljenih biblioteka.

Budućnost razvoja softvera nije binarni izbor između Human Review-a i AI Review-a. Budućnost je Risk-Based Review (pregled zasnovan na proceni rizika).

PR treba prvo klasifikovati po riziku

Možemo vrlo lako zamisliti jasan sistem klasifikacije promena u četiri nivoa:

Low Risk (nizak rizik): Dokumentacija, automatski generisan kod, formatiranje i trivijalni refactoring. Ovde su AI review i automatizovani testovi sasvim dovoljni.
Medium Risk (srednji rizik): Standardne izmene poslovne logike. Potreban je AI review u kombinaciji sa ciljanim ljudskim pregledom.
High Risk (visok rizik): Autentifikacija, plaćanja, lični podaci, infrastruktura, upravljanje dozvolama i deljena arhitektura. Ljudski reviewer je obavezan.
Critical Risk (kritičan rizik): Zdravstvo, finansije, safety-critical sistemi i strogo regulisana okruženja. Neophodna su višestruka ljudska odobrenja, automatizovani security alati, AI provere i potpuna sledljivost (auditability).

Ovakav pristup je daleko racionalniji od rigidnog pravila da svaki Pull Request moraju da pregledaju dva developera, ali i daleko bezbedniji od slepog stava da je merge opravdan čim AI kaže da je sve u redu.

Najveći rizik nije bug – najveći rizik je Automation Bias

Automation Bias označava psihološku sklonost ljudi da previše veruju automatizovanom sistemu kada on deluje kompetentno i autoritativno.

Zamislimo sledeći Pull Request:

Copilot: Code review passed.
Static Analysis: Passed.
Tests: 487 passed.
Security scan: No issues.
AI Review Agent: Approved.

Developer otvara diff od 2.400 linija koda. Koliko je psihološki verovatno da će ga zaista detaljno pročitati od početka do kraja? Vrlo malo. Sistem mu je već pet puta zaredom rekao da je sve u najboljem redu, pa klik na dugme Approve postaje linija manjeg otpora. Upravo tu human-in-the-loop može postati najopasnija vrsta kontrole: čovek formalno postoji u procesu, ali psihološki više ne vrši nezavisnu proveru.

„Human in the loop“ ne znači ništa ako čovek samo klikne

Ovu istinu moramo izgovoriti potpuno otvoreno. Kompanije veoma vole umirujuću formulaciju: „Kod nas je čovek uvek u petlji.“ To zvuči odlično na prezentacijama, ali ključno pitanje glasi: šta taj čovek zapravo radi? Da li zaista čita diff, razume suštinu promene, pokreće kritične scenarije i proverava arhitektonski uticaj, ili samo dobije opcije Approve i Reject?

Ako odluka čoveka nema informisanu osnovu, human oversight se pretvara u human rubber stamping (ljudsko udaranje pečata). Tada dobijamo najgoru moguću kombinaciju u inženjerstvu: formalnu odgovornost bez stvarne kontrole.

Ko je odgovoran ako tri AI-ja kažu da je kod dobar?

Odgovor koji nijedna kompanija ne želi da čuje glasi: i dalje kompanija.

U trenutku incidenta nije naročito važno da li je bug napisao junior, senior, Copilot, Claude ili neki autonomni agent. Krajnji korisnik ne dobija refundaciju zato što je grešku napravio AI, niti će regulator reći: „U redu, model je pogrešio, nema kazne.“ Produkcioni incident i dalje pripada organizaciji koja je taj kod pustila u rad.

Zato se odgovornost (accountability) ne može delegirati samo zato što je izvršenje posla (execution) delegirano. To je verovatno najvažniji princip AI-native inženjerstva: možete delegirati rad, ali nikada ne možete delegirati konačnu odgovornost.

Ali kako odgovarati za kod koji više niko detaljno ne čita?

Upravo na ovom mestu rađa se nova inženjerska disciplina. Odgovornost više ne može počivati isključivo na tradicionalnoj ideji da je senior inženjer lično pročitao svaku pojedinačnu liniju koda. Takav model jednostavno prestaje da bude skalabilan u trenutku kada AI agenti generišu hiljade linija dnevno, jer ljudska pažnja postaje glavno usko grlo.

Zato moramo promeniti samu paradigmu kontrole: umesto principa „čitaj sve“, prelazimo na princip „proveravaj dokaze“.

Evidence-Based Code Review

Umesto da reviewer gleda isključivo sirovi diff, sistem treba da mu pruži jasan uvid u to:

zašto je promena uopšte napravljena i koji poslovni zahtev rešava;
koje je testove agent kreirao, koje je pokrenuo i kakvi su rezultati;
koji je Security Scan izvršen i koji je review agent korišćen;
koji su problemi pronađeni tokom AI pregleda i šta je tačno izmenjeno nakon njih;
koji deo sistema je pogođen i koliki je rizik procenjen.

Drugim rečima, Pull Request prestaje da bude samo skup izmenjenih fajlova i postaje kompletan evidence package (paket dokaza). Čovek više ne mora jednako duboko da čita svaku liniju, ali mora da ima dovoljno strukturisanih dokaza da donese informisanu i odbranjivu odluku. To je daleko realističniji model za AI-native razvoj.

Observability više nije samo za produkciju

Kada AI agent radi na kodu, inženjerski tim mora imati jasan uvid u to koje je fajlove agent pročitao, koje je promenio, koju je komandu pokrenuo, koji je test pao i šta je pokušao nakon toga. Takođe, moramo znati koji je review komentar prihvatio, koji je odbacio i koju je tačno verziju modela koristio.

Na ITNetwork-u smo o ovome već detaljno pisali kroz temu „Da li znate šta su vaši AI agenti radili juče?“. Isti princip važi i ovde: AI coding workflow mora imati ugrađen Agent Observability (opservabilnost agenata). Ako ne možemo da rekonstruišemo kako je neka promena nastala, teško možemo ozbiljno govoriti o reviziji i sledljivosti.

AI reviewer ne sme da bude zamena za deterministic tools

Ovo je jedno od najvažnijih tehničkih pravila. Ne treba pitati veliki jezički model da li se kod kompajlira – pokrenite compiler. Ne treba pitati model da li testovi prolaze – pokrenite testove. Ne treba LLM da nagađa da li neka biblioteka ima poznatu CVE ranjivost – pokrenite dependency scanner.

GitHub i sam preporučuje da pregled AI-generated koda počne upravo determinističkim proverama (automated tests, static analysis, compiler checks) pre nego što se uopšte oslonimo na AI-assisted review. To je klasičan inženjerski princip: deterministički problem zahteva deterministički alat. AI treba koristiti isključivo tamo gde rigidni alati nisu dovoljni.

Najbolji Review Pipeline je heterogen

Dobar kontrolni sistem ne oslanja se na pet različitih AI agenata koji rade istu stvar, već na različite vrste kontrole složene u slojeve:

Compiler / Type Checker: Garantuje determinističku sintaksnu i tipsku ispravnost.
Unit Tests: Proveravaju očekivano ponašanje izolovanih celina.
Integration Tests: Potvrđuju ispravno međusistemsko ponašanje.
Static Analysis: Otkriva poznate code smells i strukturne anomalije.
Security Scanning: Detektuje poznate ranjivosti i slučajno izložene tajne ključeve (secrets).
AI Code Review: Analizira semantičke, logičke i kontekstualne probleme.
Human Review: Donosi konačni Engineering Judgment.

Ovo je klasičan princip odbrane u dubinu (defense in depth). Što su mehanizmi kontrole međusobno različitiji, to je manja verovatnoća da će svi imati istu slepu tačku.

AI-generated test koji potvrđuje AI-generated kod može biti kružni dokaz

Ovde leži posebna metodološka zamka. Agent napiše funkciju, a zatim napiše test koji potvrđuje da ta funkcija radi. Na papiru sve izgleda sjajno, ali ako je agent u startu pogrešno razumeo poslovni zahtev, i funkcija i test će kodirati istu pogrešnu pretpostavku.

Zamislite zahtev koji glasi: „Premium korisnik može povući do 1.000 € dnevno.“ Agent taj zahtev protumači kao „1.000 € po transakciji“. Napiše funkciju, a zatim i testove: transakcija od 999 € prolazi, transakcija od 1.001 € biva odbijena. Sve svetli zeleno, ali je poslovno pravilo suštinski pogrešno implementirano.

Upravo zato testovi koje generiše isti sistem nisu potpuno nezavisan izvor istine (oracle). Za ključne funkcionalnosti neophodno je imati test slučajeve koji nastaju iz nezavisnih specifikacija, ranijih produkcionih incidenata, realnih korisničkih scenarija i nezavisnih QA procesa.

Isto važi za AI reviewer-a koji koristi iste instrukcije kao coding agent

Ako i coding agent i review agent dobiju istu pogrešnu specifikaciju kao ulazni parametar, reviewer gotovo sigurno neće reći: „Ova specifikacija nema smisla.“ Umesto toga, on će revnosno proveravati da li je kod usklađen sa tim pogrešnim uputstvom.

Zbog toga AI-to-AI review može biti izuzetno efikasan za proveru ispravnosti same implementacije (implementation correctness), ali ostaje znatno slabiji u proveri ispravnosti samog zahteva (requirement correctness). To su dve potpuno različite dimenzije kvaliteta softvera.

Što je AI bolji, ovaj problem postaje opasniji

Loš AI kod je u praksi relativno bezbedan. On očigledno izgleda loše: compiler pada, nazivi promenljivih su čudni, logika je besmislena i čovek odmah postaje sumnjičav.

Najopasniji AI kod je onaj koji je 95% dobar. On je čitljiv, elegantno strukturisan, lepo komentarisan i pokriven testovima, ali u sebi krije jednu duboku, tihu pogrešnu pretpostavku. Na ITNetwork-u smo to već definisali kroz tezu da je „skoro tačno“ najopasnija kategorija koda. To je centralni izazov savremenog AI review-a: dobar stil koda psihološki povećava naše poverenje, ali dobar stil nikada nije dokaz suštinske ispravnosti.

AI Code Review ima još jedan problem: review fatigue u novom obliku

Tradicionalni ljudski reviewer obično ostavi desetak ili dvadeset komentara na jedan Pull Request. AI bez ikakvog napora može da ostavi stotinu. Ako je većina tih primedbi sitničava ili nevažna, developer vrlo brzo počinje da ih ignoriše.

To je klasičan problem odnosa signala i šuma (signal-to-noise). GitHub zato poslednjih meseci intenzivno optimizuje svoj review sistem ka manjem broju relevantnijih nalaza, uvodeći jasne nivoe ozbiljnosti (severity levels), procenu potrebnog truda (review effort) i automatsko zatvaranje rešenih komentara. Pregled koji prijavljuje svaku sitnicu često je u praksi lošiji od pregleda koji precizno izdvoji pet zaista kritičnih stvari, jer je ljudska pažnja strogo ograničen resurs.

AI reviewer će verovatno postati „linting nove generacije“

Nekada davno, provera stila pisanja koda i razmaka bila je ručni posao. Danas niko ozbiljan ne očekuje da senior inženjer troši vreme na proveru uvlačenja redova, formatiranja ili osnovnih stilskih pravila – to odavno rešavaju linteri.

AI review će na veoma sličan način apsorbovati veliki deo rutinskih provera: osnovne maintainability propuste, lokalne logičke greške, nedostajuće edge case-ove, jednostavna bezbednosna upozorenja i rupe u pokrivenosti testovima. Za samo nekoliko godina verovatno će delovati potpuno neprofesionalno poslati Pull Request kolegi pre nego što ga je prošao AI pre-review. I to je sasvim zdrav pravac evolucije.

Human Review tada mora postati skuplji i ređi – ali kvalitetniji

Kada AI preuzme uklanjanje rutinskih grešaka, senior reviewer više ne treba da gubi vreme na pitanje da li je neka promenljiva dobro imenovana. Njegov fokus mora da se pomeri na strateška pitanja:

„Da li je ovo granica domena koju zaista želimo da uspostavimo?“
„Da li ova izmena povećava spregnutost (coupling) u sistemu?“
„Da li ovim uvodimo novu operativnu obavezu za tim?“
„Šta će se dogoditi ako budemo morali hitno da uradimo rollback i da li nam ovo povećava blast radius?“
„Da li naš proizvod uopšte treba da se ponaša na ovaj način?“

Drugim rečima, ljudski pregled se pomera od puke inspekcije koda (Code Inspection) ka pregledu dizajna i arhitekture (Design Review). To je neuporedivo vrednija upotreba vremena iskusnih inženjera.

AI-native Software Development menja pojam autorstva

Na ITNetwork-u smo u tekstu „AI-native Software Development: kako izgleda Agile kada je AI ugrađen u ceo razvojni ciklus“ već opisali promenu u kojoj AI prestaje da bude samo pomoćni alat developeru i postaje aktivna komponenta celokupnog životnog ciklusa razvoja softvera (SDLC).

U takvom okruženju pitanje „Ko je napisao ovaj kod?“ postaje pomalo besmisleno. Da li je to developer, coding agent, review agent, model koji je generisao testove ili agent koji je primenio popravku? Mnogo važnije pitanje postaje: „Ko je odgovoran za ovu promenu?“ Autorstvo (authorship) i odgovornost (accountability) više nisu ista stvar.

Git blame postaje mnogo manje zanimljiv

Tradicionalno, komanda git blame jasno pokazuje ko je poslednji izmenio određenu liniju koda. U AI-native timu na tom mestu će sve češće pisati ime bota, agenta ili automatizovanog naloga.

Međutim, osoba koja je definisala poslovni cilj i zadala okvir često je mnogo važnija od sistema koji je generisao konkretnu sintaksu. Zato će praćenje porekla softvera (software provenance) morati da postane znatno šire. Više neće biti dovoljno znati samo koji je commit u pitanju, već koji je task, koja specifikacija, koji agent, koji model, koje instrukcije, koji reviewer i ko je dao konačno odobrenje.

„Čovek je kliknuo Approve“ nije dovoljan audit trail

Zamislite situaciju u kojoj interni revizor ili regulator postavi jednostavno pitanje: „Na osnovu čega je developer odobrio ovu kritičnu promenu?“ Odgovor „Copilot je rekao da je sve u redu“ ne zvuči nimalo ubedljivo.

Zbog toga će ozbiljne organizacije morati precizno da definišu šta formalno odobrenje zapravo znači u njihovom procesu. Na primer, ljudski reviewer potvrđuje da je razumeo poslovni uticaj i arhitektonsku kompatibilnost, automatizovani testovi potvrđuju pokrivenost, security pipeline potvrđuje bezbednosne kontrole, a AI reviewer potvrđuje provere na nivou koda. Svaki sloj potvrđuje svoj domen, što je neuporedivo snažniji model od jednog generičkog zelenog znaka potvrde.

Možda ćemo morati da uvedemo „Accountability Gates“

Savremeni CI/CD cevovodi već imaju svoje kontrolne tačke (gates): testovi moraju da prođu, security scan mora biti čist, pokrivenost koda mora preći zadati prag. Za AI-native workflow verovatno nam je potreban novi mehanizam: Accountability Gate.

Za svaku promenu visokog rizika mora postojati imenovana osoba koja eksplicitno potvrđuje četiri stvari: da je razumela promenu, da razume njene potencijalne posledice, da je pregledala relevantne dokaze i da svesno prihvata preostali rizik. To više nije mehanički klik – to je korporativno upravljanje (governance).

Ali ni to ne treba pretvoriti u novu birokratiju

Ovde se krije velika organizaciona zamka. Ako uvedemo sistem u kojem AI generiše izveštaj od 40 stranica, developer mora ručno da čekira 18 polja, a tri menadžera moraju da stave svoj potpis, u potpunosti smo ubili glavnu prednost automatizacije.

Zato intenzitet pregleda mora direktno pratiti nivo rizika. Trivijalan Pull Request treba da prođe gotovo potpuno automatizovano, dok kritičan Pull Request zahteva dokazivu i jasnu ljudsku odgovornost. To je jedini racionalan balans između brzine i sigurnosti.

AI Code Review će verovatno ubrzati još jedan trend: manji PR-ovi

AI sistemi znatno bolje i preciznije analiziraju promenu kada je ona ograničena, jasna i lokalizovana. Microsoftov benchmark takođe potvrđuje pad performansi modela sa rastom kompleksnosti i potrebom za povezivanjem udaljenih delova sistema (non-local reasoning).

To znači da dobar AI-native proces daje još snažniji podsticaj za primenu malih serija (small batches), malih Pull Request-ova i jasno definisanih granica modula. Ova praksa se savršeno uklapa sa temeljnim Agile i Continuous Delivery principima: ogroman Pull Request je podjednako težak i nepregledan i za čoveka i za AI.

„AI je pregledao“ možda postaje isto što i „tests passed“

Ovu mentalnu promenu moramo što pre usvojiti. Kada svi unit testovi prođu, nijedan iskusan inženjer ne tvrdi da je kod matematički savršen i bez greške. Kažemo samo da taj konkretan skup testova nije pronašao nijedan problem.

Na potpuno isti način treba interpretirati i AI review. Umesto zaključka „AI je rekao da nema problema“, ispravno tumačenje glasi: „Ovaj reviewer, sa ovim modelom, ovim dostupnim kontekstom i ovim setom pravila, nije pronašao problem.“ To stvara mnogo zdraviji i realniji nivo poverenja.

Confidence nije correctness

AI reviewer može zvučati izuzetno samouvereno, a da pritom bude potpuno u krivu. Zeleni status nije matematički dokaz, već statistička procena.

Zato je za praktičnu upotrebu izuzetno važno da review alati ne daju samo binarne ocene, već jasne metrike pouzdanosti (confidence), nivo ozbiljnosti (severity), konkretne dokaze (evidence) i tačne reference na linije koda. Umesto uopštene primedbe „Ovo je potencijalni problem“, korisniji je precizan nalaz: „Metoda X poziva servis Y bez validacije ulaza na linijama 42-48, što može dovesti do prekida rada.“ AI review mora biti proverljiv, a ne samo autoritativan.

Šta raditi kada se AI reviewer-i ne slažu?

Zamislimo sasvim realnu situaciju u kojoj tri različita agenta daju suprotna mišljenja: Reviewer A daje Approve, Reviewer B prijavljuje visoko rizičan bezbednosni propust, a Reviewer C ne vidi nikakav problem. Ovakve situacije će uskoro postati svakodnevica.

Jedan mogući pristup je glasanje većine (majority vote), ali u inženjerstvu to često nije dobra ideja. Ako jedan reviewer otkrije ozbiljnu bezbednosnu ranjivost, potpuno je nevažno što su ostala četiri agenta rekla da je sve u redu. Daleko bolji model je agregacija osetljiva na rizik (risk-sensitive aggregation), gde jedan visoko pouzdan kritičan nalaz automatski zaustavlja merge. Softverska bezbednost funkcioniše poput vazduhoplovstva, a ne poput parlamentarne demokratije.

AI reviewer treba da bude adversarial, ne ljubazan

Coding agent ima jasan konstruktivan cilj: da napravi rešenje koje prolazi zahteve. Review agent, međutim, mora imati potpuno suprotan cilj: da pokuša da to rešenje slomi.

Ako oba agenta rade pod istim mentalnim okvirom pomoći da se zahtev uspešno implementira, lako mogu zajedno da optimizuju pogrešno rešenje. Zato reviewer mora dobiti suprotstavljene (adversarial) instrukcije: da aktivno traži rubne slučajeve (edge cases), tačke otkaza, bezbednosne rupe, pogrešne poslovne pretpostavke, breaking changes i načine na koje testovi mogu da prođu iako je ponašanje sistema pogrešno. Tek tada dobijamo stvarnu funkcionalnu nezavisnost između agenata.

Red Teaming će ući u običan Code Review

Do sada smo koncept Red Teaming-a uglavnom vezivali za sajber bezbednost. U AI-native razvoju isti princip možemo primeniti na svaku važniju izmenu u kodu kroz specijalizovane uloge:

Coding agent: Predlaže konkretno rešenje.
Review agent: Pokušava da dokaže da rešenje ne radi u praksi.
Test agent: Generiše adversarial test slučajeve sa ciljem obaranja logike.
Security agent: Aktivno traži potencijalni exploit.
Architecture agent: Procenjuje dugoročne strukturne rizike.

Ovakva arhitektura je neuporedivo zanimljivija i otpornija od oslanjanja na jednog opšteg AI reviewer-a. Ipak, važno je ponoviti: ni pet specijalizovanih agenata ne uklanja konačnu odgovornost čoveka.

A šta čovek onda zapravo radi?

U ovakvom ekosistemu uloga programera se suštinski transformiše. On sve manje ručno proverava svaki if uslov, a sve više:

definiše pravila igre i granice autonomije sistema;
procenjuje nivo rizika i analizira prikupljene dokaze;
razume širu arhitekturu i donosi odluke o kompromisima (trade-offs);
preuzima krajnju odgovornost za ono što ide pred korisnike.

Programer tako prestaje da bude samo autor koda i postaje upravljač promenama (governor of change). To možda zvuči manje romantično od klasičnog kucanja koda kasno u noć, ali je mnogo bliže stvarnoj budućnosti senior inženjerstva.

Ovo menja i junior-senior odnos

Ova promena nosi i jedan skriveni kadrovski izazov. Junior developeri tradicionalno uče kroz pisanje koda, pravljenje grešaka i čitanje konstruktivnih komentara seniora tokom Code Review-a. Ako AI sam piše kod, sam ga popravlja, objašnjava i pregleda, junior će nesumnjivo proizvoditi više funkcionalnosti za kraće vreme, ali može izgubiti dragoceni proces kroz koji se gradi inženjerska intuicija.

Senior inženjer nije postao senior zato što je pročitao svu dokumentaciju, već zato što je godinama pravio greške i uživo posmatrao posledice svojih odluka u produkciji. Ako automatizacija ukloni ta mikro-iskustva, timovi će morati svesno da osmisle nove načine za razvoj stručnosti mladih inženjera.

Code Review je bio i obrazovni mehanizam

U žurbi za brzinom često zaboravljamo da je Code Review oduvek služio za prenos znanja. Kada junior napravi Pull Request, a senior mu napiše: „Zašto ovde izvršavaš upit ka bazi unutar petlje?“, junior usvaja važnu lekciju i sledeći put sam prepoznaje taj anti-obrazac.

Ako AI reviewer ostavi komentar, a coding agent ga automatski ispravi u pozadini pre nego što junior uopšte vidi problem, znanje nikada ne prelazi na čoveka. Produktivnost na papiru raste, ali stvarna sposobnost tima stagnira. Tako možemo doći u paradoksalnu situaciju gde softver postaje sve bolji, a ljudi u timu sve manje razumeju zašto on uopšte radi.

Možda će zato „learning mode“ biti važan i za Code Review

U radu sa mlađim kolegama, AI asistent ne bi smeo samo tiho da primeni ispravku i prijavi da je zadatak završen. Umesto toga, koristan pristup bio bi režim učenja: „Pronašao sam problem X. Pre nego što ga popravim, objasniću ti zašto on nastaje i kakav kompromis ovde postoji.“

Ovakav pristup jeste sporiji u kratkom roku, ali dugoročni razvoj ljudi ima nemerljivu vrednost. Svaka organizacija mora jasno da odluči da li joj je jedini cilj maksimalan trenutni protok zadataka (throughput) ili izgradnja budućih inženjerskih kapaciteta.

Najveći dug AI-native razvoja možda neće biti Technical Debt

Najveći rizik nove ere verovatno neće biti klasičan tehnički dug, već Comprehension Debt (dug razumevanja).

Kod nezaustavljivo raste, sistem brzo evoluira, agenti rade u pozadini i svi testovi prolaze, ali sve manji broj ljudi u kompaniji ume da objasni zašto sistem funkcioniše baš na taj način. Ovo je izuzetno opasan oblik duga jer ne pravi nikakve probleme dok sve radi glatko. Njegova prava cena dolazi na naplatu onog trenutka kada nešto veliko pođe po zlu u produkciji. Tada hitno tražimo nekoga ko dubinski razume sistem, samo da bismo otkrili da je većina arhitektonskih odluka u poslednjih godinu dana nastala kroz automatizovane petlje koje su radile odlično – sve do tog kritičnog trenutka.

„Mostly works“ nije dovoljan standard za kritične sisteme

Uspešnost AI review-a od 71,9% u detekciji bugova može biti fantastična za veliki broj standardnih razvojnih zadataka. Međutim, takav procenat nije ni blizu dovoljnog za softver u medicinskim uređajima, bankarskim transakcijama, industrijskim kontrolnim sistemima ili kritičnoj infrastrukturi identiteta.

Tolerancija na rizik nije univerzalna kategorija. Zato upravljanje AI alatima mora biti prilagođeno konkretnom domenu poslovanja (domain-specific). Startup koji razvija zabavnu aplikaciju može i treba da prihvati znatno viši nivo autonomije agenata nego finansijska institucija.

IT industrija mora prestati da traži jedno univerzalno pravilo

AI review nije ni apsolutno dobar ni apsolutno loš, baš kao što ni ljudski pregled nije ni uvek obavezan ni potpuno nepotreban. Sve zavisi od pet ključnih faktora: nivoa rizika, kompleksnosti izmene, mogućnosti brzog povratka na staro stanje (reverzibilnosti), kritičnosti sistema i šireg poslovnog konteksta.

Ako se neka promena lako može vratiti unazad (rollback) i njen potencijalni uticaj na sistem (blast radius) je mali, autonomija AI agenata može biti veoma visoka. Sa druge strane, ako greška može da izazove nepovratnu finansijsku, pravnu ili bezbednosnu štetu, ljudska kontrola mora biti čvrsta i beskompromisna. To je odlika zrelog inženjerskog razmišljanja.

Idealni Code Review pipeline 2027. možda izgleda ovako

Kada spojimo sve lekcije iz dosadašnje prakse, optimalan proces pregleda koda u bliskoj budućnosti mogao bi da izgleda ovako:

AI coding agent implementira zadatak prema specifikaciji.
Automated deterministic checks pokreću compiler, unit i integracione testove, statičku analizu, kao i skeniranje zavisnosti i bezbednosti.
AI self-review omogućava agentu da sam proveri sopstveni rad i ispravi očigledne propuste.
Independent AI review uključuje drugi model sa adversarial instrukcijama koji aktivno traži slabosti u rešenju.
Risk classifier automatski procenjuje nivo rizika promene (Low, Medium, High ili Critical).
Targeted human review angažuje iskusnog inženjera isključivo tamo gde ljudska procena i poznavanje konteksta donose najveću vrednost.
Post-deployment observability prati stvarno ponašanje koda u produkciji nakon isporuke.

Ovakav tok rada nije „AI umesto čoveka“, već pametna i održiva podela rada između mašine i inženjera.

Human Review će možda biti mnogo manje čest, ali mnogo važniji

Danas inženjeri pregledaju ogroman broj Pull Request-ova, ali to zbog preopterećenja često rade površno. U bliskoj budućnosti čovek će možda pregledati svega 20% svih promena, ali će tih 20% pregledati temeljno, detaljno i sa punim poslovnim kontekstom, jer je sistem procenio da nose visok rizik. To predstavlja ogroman kvalitativni skok: manje mehaničkog rituala, a mnogo više stvarne inženjerske procene.

Ali postoji jedna važna pretpostavka

U opisanom modelu krije se jedna suptilna tačka ranjivosti: sam klasifikator rizika (Risk classifier) takođe može biti zasnovan na AI modelu. Ako on napravi grešku u proceni i rizičnu izmenu označi kao Low risk, ta promena možda nikada neće stići do ljudskog oka.

Zato svaki novi sloj automatizacije, pored toga što rešava postojeće probleme, stvara i nove rizike. Zbog toga nivo upravljanja i kontrole (governance) mora da prati stvarnu zrelost AI alata u timu – nikada ne smemo povećavati nivo autonomije sistema samo zato što nam je ta opcija tehnički dostupna jednim klikom.

GitHubova odluka da AI approval bude konfigurabilan je vrlo važna

Činjenica da GitHub nije automatski uključio opciju da Copilot formalno odobrava Pull Request-ove za sve korisnike pokazuje zrelost u pristupu. Administrator repozitorijuma mora svesno i eksplicitno da dozvoli da AI odobrenje zadovolji pravila za merge.

To je ispravan pristup jer pitanje „Da li AI sme formalno da odobri kod?“ nije puka tehnička postavka, već ozbiljna organizaciona politika. Svaka kompanija mora jasno da definiše za koje repozitorijume, za koje putanje u kodu, za koji nivo rizika i uz koje dodatne kontrole ovakva automatizacija ima smisla.

Veoma lako možemo završiti sa „Approval Theatre“

Zamislite proces u kojem imamo AI review, zatim AI approval, a na kraju i obavezno ljudsko odobrenje. Spoljni revizor na papiru vidi dve nezavisne kontrole. Međutim, ako čovek u praksi samo mehanički klikne dugme zato što je AI već dao zeleno svetlo, mi realno imamo samo jednu kontrolu.

Ova pojava se naziva Approval Theatre (pozorište odobravanja). Proces spolja deluje bezbedno i usklađeno sa procedurama, ali stvarna nezavisnost provere ne postoji. To je možda najopasnija faza automatizacije: ne trenutak kada potpuno uklonimo čoveka iz procesa, već trenutak kada ga ostavimo u njemu samo kao dekoraciju.

Kada ljudska odgovornost postaje formalnost?

Odgovor na ovo pitanje je potpuno jasan. Ljudska odgovornost postaje puka formalnost onog trenutka kada inženjer više nema dovoljno informacija, vremena ili stručnosti da smisleno odbije odluku AI sistema.

Ako developer ne razume suštinu promene, nije pročitao kritične delove, ne sagledava šire rizike i nema razloga da posumnja u besprekorno formatiran izveštaj agenta, njegov klik na Approve nije kontrola kvaliteta. To je samo blanko potpis.

Da li je onda poštenije potpuno ukloniti čoveka?

Ovo je provokativno pitanje, ali u određenim situacijama odgovor može biti potvrdan. Ako je neki proces zaista niskog rizika, potpuno automatizovan, pokriven pouzdanim testovima i lako reverzibilan, mnogo je poštenije otvoreno ga nazvati autonomnim merge cevovodom nego tvrditi da postoji ljudski nadzor dok developer samo mehanički pritiska dugme. Formalni ljudski nadzor bez stvarne provere samo stvara opasan i lažan osećaj sigurnosti.

Ali kritične odluke moraju imati stvarnog vlasnika

Za svaku promenu visokog rizika u sistemu mora postojati konkretna osoba koja može da stane iza nje i kaže: „Razumem ovu promenu i preuzimam odgovornost.“

To nije zato što su ljudi nepogrešivi – naprotiv, ljudi redovno greše. Razlog je u tome što organizacije moraju imati jasnu liniju odgovornosti. AI model nema profesionalnu licencu, nema ugovor o radu, nema pravnu niti disciplinsku odgovornost pred zakonom ili klijentima. Kompanija i ljudi u njoj tu odgovornost imaju, i to se neće promeniti bez obzira na to koliko AI agenti postanu dobri u pregledu koda.

Šta bih preporučio timovima danas?

Nemojte zabranjivati AI Code Review. Koristite ga intenzivno, ali ga postavite kao pametan kontrolni sloj, a ne kao nepogrešivi izvor istine. Započnite sa jasnom strukturom:

uvedite automatski AI pre-review za svaki Pull Request;
zadržite stroge determinističke quality gates (testove, lintere, security skenere);
uvedite klasifikaciju promena prema nivou rizika i obavezan Human Review za rizične izmene;
čuvajte detaljne logove agenata i obezbedite jasan trag porekla svake izmene (provenance).

Nakon toga redovno merite rezultate u sopstvenom okruženju. Pratite koliko je AI nalaza zaista korisno, koliko bugova sistem propušta, koliko stvara lažnih uzbuna (false positives) i koje tipove promena najslabije razume. Microsoftov benchmark pokazuje da se kvalitet modela menja iz meseca u mesec, ali svaka organizacija mora da meri sopstvenu realnost, a ne samo laboratorijske rezultate.

Nemojte zaboraviti da AI review takođe treba testirati

Evaluacija samih alata za pregled koda postaje nova obavezna praksa. Ako uvodite AI reviewer u tim, kako znate da on zaista radi dobar posao?

Uzmite skup istorijskih Pull Request-ova iz sopstvenog repozitorijuma za koje pouzdano znate da su sadržali bugove koji su kasnije otkriveni u produkciji. Pustite AI reviewer da ih analizira i proverite koliko tih stvarnih grešaka uspeva da pronađe, koliko lažnih uzbuna generiše i kako se snalazi sa bezbednosnim i arhitektonskim propustima. GitHub je upravo sa tim ciljem objavio ReviewBench – specijalizovani benchmark sa reprezentativnim zahtevima i metrikama fokusiranim na produkciju. AI reviewer nije magija, već još jedan softverski sistem čiji kvalitet moramo kontinuirano da testiramo.

Budućnost će možda imati „reviewer routing“

Različiti modeli pokazuju različite prednosti: jedan je bolji za sajber bezbednost, drugi za sistemsku arhitekturu, treći za Python, a četvrti za optimizaciju performansi.

Umesto oslanjanja na jedan univerzalni AI reviewer, napredni sistemi će uskoro analizirati prirodu svakog Pull Request-a i automatski usmeravati zadatak (reviewer routing). Ako je u pitanju migracija baze podataka, šalje ga specijalizovanom modelu; ako se menja autentifikacija, aktivira maksimalan napor i bezbednosnog agenta; ako se menja samo dokumentacija, sprovodi brzu i laganu proveru. Upravo ovakvo dinamičko skaliranje napora prema kompleksnosti promene preporučuje i Microsoftovo istraživanje kao najefikasniji model za budućnost.

Review postaje orchestration problem

Nekada se ceo proces svodio na jednostavnu relaciju između autora koda i kolege koji ga pregleda. Danas taj lanac izgleda znatno složenije: coding agent predaje posao test agentu, zatim nastupaju bezbednosni alati, pa review agent, fix agent, klasifikator rizika i na kraju čovek.

Neko u organizaciji mora svesno da dizajnira, povezuje i održava tu arhitekturu kontrole – zadatak koji će sve češće pripadati Platform Engineering, AI Engineering i DevEx timovima. Code Review tako prestaje da bude samo interpersonalni dogovor unutar tima i postaje ozbiljan inženjerski problem orkestracije.

Joombooz paralela: automatizacija ne uklanja potrebu za odgovornošću

Potpuno istu logiku vidimo i van sveta čistog programiranja. Kroz rad na platformi Joombooz, gde se bavimo primenom generativne veštačke inteligencije i automatizacijom poslovnih procesa, stalno se ponavlja isti obrazac: AI može da napiše tekst, analizira podatke, generiše predlog i proveri usklađenost, ali organizacija i dalje mora da definiše šta u njenom poslovanju znači „dovoljno dobro“.

AI ne stvara poslovne standarde – ljudi ih definišu. Potpuno je isto i sa pregledom koda: model može efikasno da proverava poštovanje pravila, ali ljudi moraju da odluče koja pravila uopšte treba da postoje.

Najvažnija veština seniora možda više neće biti pronalaženje bugova

Ovaj zaključak na prvi pogled može delovati neobično. Međutim, ako AI uskoro postane brži i precizniji od prosečnog čoveka u pronalaženju velikog broja lokalnih grešaka u kodu, fokus senior inženjera mora da se podigne na viši nivo apstrakcije: na sistemsko razmišljanje, arhitekturu, poslovni uticaj, upravljanje rizicima, kompromise i dugoročne operativne posledice.

To u praksi znači manje komentara tipa „Na liniji 178 nedostaje provera za null vrednost“, a mnogo više strateških pitanja poput „Zašto uopšte uvodimo ovu spoljnu zavisnost u samu srž našeg domena?“. To je izuzetno pozitivna promena za celu profesiju, pod uslovom da je sprovedemo promišljeno.

AI Code Review možda će konačno naterati Code Review da bude ono što je trebalo da bude

Godinama smo u isti proces trpali potpuno različite aktivnosti: proveru stila pisanja, lov na sitne bugove, mentorstvo mlađih kolega i ozbiljne arhitektonske diskusije.

Ako AI preuzme najveći deo rutinskog lova na greške i stilskih provera, ljudski Code Review konačno može da se vrati svojoj pravoj suštini – kvalitetnom razgovoru o dizajnu sistema, deljenju domenskog znanja, analizi kompromisa i usklađivanju sa poslovnom logikom. AI neće ubiti Code Review; on ima potencijal da ga konačno očisti od zamorne rutine.

Ali samo ako ljudi ne prestanu da razmišljaju

Ovo je centralni i nezaobilazni uslov celokupne transformacije. Najgori mogući razvojni proces nije onaj u kojem AI radi potpuno bez čoveka. Najgori proces je onaj u kojem imamo AI i čoveka koji slepo veruje da je samo njegovo formalno prisustvo dovoljno da sistem bude bezbedan. Jer tada odgovornost postoji samo na papiru, dok u stvarnosti niko ne drži volan.

Zaključak: nije problem što AI proverava AI – problem je ako niko više ne proverava smisao

Da li Code Review koji radi AI ima smisla ako je i kod napisao AI? Da, apsolutno – i imaće ga sve više. Što AI sistemi budu generisali veće količine koda, to će biti manje realno očekivati da čovek ručno čita svaku liniju istim intenzitetom. Automatizovani pregled postaje neophodan sloj zaštite, a najnovija istraživanja pokazuju da review agenti već sada hvataju preko 70% realnih grešaka, uz izuzetno brz napredak iz meseca u mesec.

Ipak, bio bi pogrešan zaključak reći da čovek više nije potreban. Tačnije je reći da čovek više nije potreban za isti onaj rutinski deo posla kao ranije. Mašina će sve bolje proveravati sintaksu, lokalnu ispravnost, poznate obrasce, bezbednosne propuste i pokrivenost testovima. Čovek, sa druge strane, mora sve više da proverava smisao, širi kontekst, arhitekturu, rizik, poslovnu nameru i krajnju odgovornost.

To je daleko ozbiljnija uloga, ali ona zahteva da inženjer zaista bude intelektualno uključen, a ne da samo mehanički klikće. Ako jedan AI napiše kod, drugi ga pregleda, treći ga popravi, četvrti ga odobri, a developer na kraju otvori Pull Request, vidi zeleni ekran i pritisne dugme, onda human-in-the-loop više nije kontrolni mehanizam – postao je običan element korisničkog interfejsa.

Tu dolazimo do najneprijatnijeg pitanja za savremene razvojne timove: ako čovek ne razume dovoljno promenu da bi mogao razumno i argumentovano da kaže „ne“ – zašto ga uopšte pitamo da kaže „da“?

Budućnost će od nas zahtevati mnogo više profesionalnog poštenja. Za softver niskog rizika treba da dopustimo veću autonomiju mašina, dok za sisteme visokog rizika moramo zahtevati stvarno ljudsko razumevanje – ne ritual, ne puko štikliranje polja i ne Approve nakon 14 sekundi površnog gledanja, već istinsku odgovornost.

Softver ne postaje manje naš samo zato što ga više ne kucamo ručno slovo po slovo. Naprotiv, što više izvršenja prepustimo agentima, to postaje važnije da u svakom trenutku jasno znamo ko je vlasnik odluke. Zato najvažnija metrika AI-native Code Review-a neće biti koliko je Pull Request-ova AI pregledao niti koliko je bugova pronašao, već jedno mnogo dublje pitanje: za koliko promena možemo jasno da objasnimo zašto verujemo da su dovoljno bezbedne za produkciju? Ako na to pitanje imamo čvrst odgovor, AI Code Review donosi ogromnu vrednost. Ako nemamo, onda su svi zeleni znaci potvrde samo veoma lepo automatizovana iluzija kontrole.

Često postavljana pitanja (FAQ)

Da li AI Code Review ima smisla ako je kod generisao AI?

Da. AI reviewer može predstavljati dodatni nezavisni sloj kontrole i pronaći greške koje coding agent nije primetio. Međutim, takva provera nije dokaz potpune ispravnosti sistema.

Koliko su AI Code Review agenti dobri u 2026. godini?

Microsoft Research benchmark iz oktobra 2026. pokazao je da je najbolji testirani review agent pronašao 71,9% ljudski verifikovanih bugova među pet najvažnijih komentara, ali sa osetno slabijim rezultatima kod kompleksnih i kontekstualno zahtevnih promena.

Može li GitHub Copilot da odobri Pull Request?

Da. GitHub je 2026. godine omogućio da administrator repozitorijuma dozvoli Copilot-u da podnese formalni approval koji može da zadovolji repository approval pravilo. Ova funkcija nije uključena automatski i zahteva svesnu odluku organizacije.

Može li AI coding agent sam da pregleda sopstveni kod?

Da. GitHub Copilot coding agent već može da pokrene Copilot Code Review nad sopstvenim promenama, zatim da obradi dobijene povratne informacije i popravi patch pre nego što uopšte zatraži ljudski review.

Da li su dva AI modela nezavisna kao dva ljudska reviewer-a?

Ne nužno. Različiti modeli mogu imati različite slepe tačke, ali često dele slične trening izvore, programske obrasce i statističke pretpostavke, zbog čega postoji realan rizik od korelisanih grešaka (correlated failure).

Da li AI Review može zameniti Static Analysis?

Ne. Compiler, type checker, Static Analysis, security scanner i automatizovani testovi uvek treba da se koriste za determinističke probleme. AI review treba posmatrati isključivo kao dodatni semantički sloj kontrole.

Šta je Automation Bias?

Automation Bias je psihološka sklonost čoveka da nekritički prihvati odluku automatizovanog sistema zato što sistem deluje kompetentno ili zato što je više prethodnih provera dalo pozitivan rezultat.

Šta znači Human Rubber Stamping?

To je situacija u kojoj čovek formalno odobrava odluku sistema klikom na dugme, ali zapravo nema dovoljno vremena, informacija ili konteksta da sprovede stvarno nezavisnu proveru.

Kada Human Review ima najveću vrednost?

Ljudski pregled je najvredniji kod promena sa visokim rizikom, složenim poslovnim pravilima, dugoročnim arhitektonskim posledicama, bezbednosnim implikacijama ili kada odluka zavisi od informacija koje nisu eksplicitno zapisane i dostupne AI sistemu.

Da li svaki Pull Request treba da ima Human Review?

Ne nužno. Najracionalniji pristup je Risk-Based Review, gde promene niskog rizika mogu biti gotovo potpuno automatizovane, dok visoko rizične promene zahtevaju detaljnu ljudsku procenu.

Šta je Evidence-Based Code Review?

To je pristup u kojem reviewer ne dobija samo sirovi diff, već kompletan paket dokaza: poslovni zahtev, kreirane testove, rezultate analiza, logove agenata, bezbednosne nalaze, procenu rizika i podatke o tome kako je promena nastala.

Šta je Comprehension Debt?

Comprehension Debt (dug razumevanja) predstavlja situaciju u kojoj softverski sistem evoluira brže nego što ljudski tim uspeva da održi razumevanje njegove arhitekture, ponašanja i razloga za prethodne odluke.

Zašto AI-generated testovi nisu dovoljni?

Ako isti AI sistem pogrešno protumači poslovni zahtev, on može generisati i kod i testove koji potvrđuju istu pogrešnu pretpostavku. Zato kritične testove uvek treba vezivati za nezavisne specifikacije i realne korisničke scenarije.

Šta znači adversarial AI reviewer?

To je review agent kojem cilj nije da potvrdi da je implementacija dobra, već aktivno pokušava da pronađe način na koji kod može da pogreši, bude zloupotrebljen ili proizvede neočekivane posledice.

Da li će Human Code Review nestati?

Verovatnije je da će postati ređi, ali znatno fokusiraniji i kvalitetniji. Rutinsku inspekciju će sve više preuzimati AI, dok će ljudi pregledati rizične promene, arhitekturu, poslovni uticaj i ključne kompromise.

Kako bi idealan AI-native Code Review pipeline mogao da izgleda?

Optimalan tok izgleda ovako: coding agent -> determinističke provere (compiler, testovi, static analysis, security) -> AI self-review -> nezavisni adversarial AI review -> klasifikacija rizika -> ciljano Human Review -> praćenje ponašanja u produkciji (observability).

Da li AI approval znači da je kod bezbedan?

Ne. Odobrenje koje daje AI predstavlja samo statističku procenu određenog modela u okviru dostupnog konteksta i pravila, a ne matematički dokaz ispravnosti ili bezbednosti.

Ko je odgovoran kada AI-generated kod izazove incident?

Odgovorna je isključivo organizacija koja je taj kod pustila u produkciju. Automatizacija izvršenja posla nikada ne uklanja poslovnu, profesionalnu niti zakonsku odgovornost.

Koja je najveća opasnost potpuno automatizovanog Code Review-a?

Najveća opasnost nije samo jedan propušten bug, već postepeni gubitak ljudskog razumevanja sopstvenog sistema uz opasan privid da ljudska kontrola i dalje postoji.