To je ogromna promena za industriju. Development može da bude brži, repetitivni poslovi mogu da se automatizuju, a developer može više vremena da posveti arhitekturi, logici proizvoda i problemima koji zahtevaju razmišljanje. Ali postoji jedna stvar koju je lako zaboraviti kada funkcionalnost koja je nekada zahtevala nekoliko sati odjednom nastane za nekoliko minuta: kod koji radi nije nužno i dobar kod.
AI može da napiše funkcionalnost, ali ne zna nužno ceo kontekst
Zamislite da AI dobije zadatak da napravi login, poveže novu payment metodu ili doda opciju za izvoz podataka. Može vrlo brzo da napravi rešenje koje na prvi pogled funkcioniše. Ono što ne mora da zna jeste zašto je sistem pre tri godine napravljen na određeni način, koje druge funkcionalnosti zavise od tog dela koda, kakva poslovna pravila postoje iza njega ili šta će se dogoditi kada sistem više ne koristi deset nego deset hiljada korisnika.
U ozbiljnom projektu kod nikada ne postoji izolovano. Jedna promena može da utiče na bazu podataka, performanse, bezbednost, integracije sa drugim sistemima ili funkcionalnost koja naizgled nema nikakve veze sa njom. Upravo je razumevanje tog šireg konteksta jedan od razloga zbog kojih development nije samo pisanje sintakse.
AI je veoma dobar u tome da odgovori na pitanje „kako ovo možemo da napravimo?“. Mnogo je važnije da neko i dalje postavi pitanje:
Da li ovo treba da napravimo baš ovako?
Najopasniji kod nije onaj koji ne radi
Kada kod ne radi, problem je uglavnom lako primetiti. Aplikacija prijavi grešku, test padne ili funkcionalnost jednostavno ne može da se koristi. Mnogo je problematičniji kod koji radi, ali je napravljen loše.
Može da postoji bezbednosni propust koji će biti primećen tek mnogo kasnije. Može da koristi biblioteku koju nije trebalo uvoditi. Može da napravi nepotreban broj upita prema bazi i da funkcioniše savršeno dok aplikacija nema veliki broj korisnika. Može da duplira logiku koja već postoji na drugom mestu ili da reši trenutni problem tako da svaka sledeća izmena postane komplikovanija.
AI modeli su posebno ubedljivi upravo zato što rezultat često izgleda potpuno ispravno. Kod je lepo strukturiran, nazivi funkcija deluju smisleno, postoji komentar koji objašnjava šta se događa i sve deluje kao da je neko veoma siguran u ono što je napisao. To, međutim, nije isto što i dokaz da je rešenje dobro.
Bezbednost postaje još važnija
Kako coding alati postaju sposobniji, više ne govorimo samo o AI-ju koji predlaže tekst unutar editora. Agent može da čita fajlove, izvršava komande, instalira dependency-je, pristupa internetu i koristi druge development alate.
Zbog toga je OWASP tokom 2026. objavio posebne smernice za bezbedan rad sa AI coding agentima. Među preporukama su izolovana razvojna okruženja, ograničavanje pristupa alatima i podacima, kontrola dependency-ja i obavezna ljudska provera promena koje mogu da utiču na CI/CD, infrastrukturu ili produkciona okruženja.
Drugim rečima, što agent može više da uradi, važnije postaje pitanje šta mu je dozvoljeno da uradi. Developeru verovatno ne biste dali administratorski pristup svakom sistemu kompanije samo zato što radi na jednoj funkcionalnosti. Isti princip treba da važi i za AI.
Code review nije postao manje važan. Postao je važniji.
Ako AI može da proizvede više koda za kraće vreme, tim može da završi više posla. Ali tada raste i količina koda koju neko mora da razume i proveri. Zato se uloga code review-a ne smanjuje. Menja se.
Više nije dovoljno pogledati da li funkcija vraća očekivani rezultat. Potrebno je proveriti kako se uklapa u postojeću arhitekturu, da li uvodi nove dependency-je, kako obrađuje greške, šta se dešava u edge case situacijama, da li poštuje postojeće standarde projekta i da li otvara novi sigurnosni rizik.
Zanimljivo je da se AI već koristi i sa druge strane tog procesa. GitHub, na primer, razvija AI podržan code review i security review koji mogu da pronađu određene kategorije ranjivosti pre nego što kod završi u glavnoj grani projekta. To pokazuje u kom pravcu ide development: AI piše deo koda, AI može pomoći i da se taj kod proveri, ali odgovornost za ono što završava u proizvodu i dalje mora da ima tim koji ga razvija.
A gde su testovi?
Ako postoji jedno mesto gde AI može značajno da pomogne development timu, to je upravo testiranje. Može veoma brzo da predloži unit testove, pronađe scenarije koje developer nije pokrio ili proveri veliki broj varijacija neke funkcionalnosti. Ali ni veliki broj testova automatski ne znači da je aplikacija dobro testirana.
AI može da napiše test koji samo potvrđuje istu pretpostavku koju je napravio dok je pisao kod. Ako je pretpostavka pogrešna, možemo dobiti vrlo lep rezultat: pogrešno implementiranu funkcionalnost koja prolazi sve testove. Zato se ne testira samo ono što je napisano, već i ono što je trebalo da bude napisano. Tu ponovo ulaze specifikacija, poslovna logika, iskustvo tima i razumevanje korisnika.
Da li AI onda zaista ubrzava development?
Da. I verovatno mnogo više nego što trenutno možemo da izmerimo. Kod određenih zadataka razlika je ogromna. Boilerplate kod, migracije, dokumentacija, testovi, refaktorisanje, istraživanje postojećeg codebase-a ili manje izolovane funkcionalnosti mogu da se urade značajno brže. Developer više ne mora svaki problem da rešava od praznog ekrana.
Ali brzina pisanja koda nikada nije bila jedina stvar koja određuje koliko brzo nastaje dobar proizvod. Pre nego što počne development, neko mora da razume šta pravimo. Potrebno je osmisliti arhitekturu, odabrati tehnologiju, razumeti poslovnu logiku i definisati kako će različiti sistemi međusobno komunicirati. Nakon što kod nastane, potrebno ga je testirati, proveriti, deployovati, pratiti i održavati.
AI može da ubrza gotovo svaki od tih koraka. Ne može da učini da oni prestanu da postoje.
Šta se onda menja u poslu developera?
Manje vremena moraće da odlazi na samo kucanje koda, a više na donošenje odluka. Developer sve češće postaje osoba koja agentu daje kontekst, deli problem na manje celine, procenjuje predloženo rešenje i prepoznaje kada nešto što izgleda ispravno zapravo nije dobro za sistem koji se gradi.
To znači da iskustvo neće postati manje važno zato što AI ume da programira. Moglo bi da postane još važnije. Junior developer uz AI može mnogo brže da napravi nešto što radi. Senior developer će mnogo lakše prepoznati zašto to rešenje možda ne treba da ode u produkciju. I upravo tu će se verovatno praviti najveća razlika.
AI-generated nije isto što i production-ready
Moguće je danas napraviti landing stranicu, prototip, malu aplikaciju ili čak prilično kompleksnu funkcionalnost za vreme koje je do skoro bilo nezamislivo. To je odlična stvar. Problem nastaje tek kada brzinu izrade počnemo da mešamo sa kvalitetom proizvoda.
Production-ready softver mora da bude pouzdan, bezbedan, održiv i napravljen tako da može da nastavi da se razvija. Mora da funkcioniše kada nešto pođe po zlu, kada broj korisnika poraste i kada developer koji ga je prvobitno napravio više nije osoba koja ga održava.
Zato pitanje više nije da li AI može da napiše kod; može. Mnogo zanimljivije pitanje za naredne godine biće: ko zna dovoljno da proceni da li je taj kod zaista dobar?
