Šef: "Kako koristiš AI, zaista možeš da ne pišeš kod ručno? Zašto mi se Codex u rukama čini kao glup." Ja: "E ovako, a onda ovako.." Šef je pao na kolena.

Isti alat u rukama različitih ljudi daje potpuno različite rezultate. Na primer, marketing kanali kažu da je Codex bog, ali prema mom ličnom iskustvu — nije baš do te mere.

Ali je zaista postao najjači Agent alat — svakodnevno kodiranje, generisanje slika, sve se može obaviti uz njega.

Jedna stvar se mora naglasiti: čovek, odnosno ti, i dalje moraš biti u glavnoj ulozi.

Juče sam pomoću Codex-a integrisao Alibaba Cloud OCR u projekat Pai Pametan, a za jedan dan mi je naplatio preko 700 juana.

Još gore je to što se Alibaba Cloud OCR, jednom aktiviran, ne može isključiti, osim ako se programski ne ograniči. Srećom, ranije sam u .env dodao globalno ograničenje ALIYUN_OCR_ENABLED=false/true, inače bi problem bio ozbiljan.

Drugi rečima, tokom korišćenja AI programiranja, obavezno moramo formirati sporazum sa AI-jem, inače posledice mogu biti ozbiljne.

U nastavku ću podeliti svoje iskustvo korišćenja Codex-a. Vežite sigurnosne pojaseve, krećemo.

01. Nemojte odmah tražiti od AI-a da piše kod

Uđite u fasciklu projekta, pokrenite Claude Code / Codex, prvo /init. Zatim počnite da menjate CLAUDE.md / AGENTS.md.

AGENTS.md (za Codex) i CLAUDE.md (za Claude Code) su suštinski "uputstvo za projekat" koje govori AI-ju gde su granice ovog projekta.

Dobar AGENTS.md treba da sadrži barem sledeće:

• Najvažnija ograničenja najvišeg prioriteta (na primer, nemoj svaki put da izgrađuješ kod kad ga izmeniš, posebno ako je front-end već projekat sa vrućim razvojem)
• Tehnički stek i struktura direktorijuma projekta
• Konvencije kodiranja (imenovanje, obrada grešaka, zahtevi za testiranje)
• Tok razvoja (na primer, prvo testovi pa onda implementacija)

Upišite arhitektonska ograničenja i ključna pravila u AGENTS.md, u svakom razgovoru ih nosite sa sobom, i problem AI-jevog zaboravljanja je uglavnom rešen.

Zašto?

Zato što AI nema dugoročno pamćenje.

Pri svakoj novoj sesiji on je u "amnezijskom" stanju, a AGENTS.md je "memorijski čip" koji se automatski učitava na početku svakog razgovora. Ako u njega napišete "nema prekomernog obavijanja", AI neće se svaki put petljati u izradu nekih scheduler-a. Ako u njega napišete "testovi prvo", AI će prvo pokrenuti testove pre nego što pošalje izmene.

AGENTS.md treba da bude koncizan, ali da jasno definise tok razvoja, na primer "prvo test dokumentacija, dokumentacija se nalazi u direktorijumu xxx".

Nemojte od njega praviti dugački spisak.

AGENTS.md sam po sebi zauzima kontekst — ako ga napišete predugo, postaje kontraproduktivan. Preporučujem da ga držite ispod 200 redova i upišete samo ključna ograničenja.

Da pitam još jedno — da li pišete pravila i Skills za svoj projekat? Kada otkrijete problem u kodu koji je napisao AI, da li tražite od AI-a da ispravi i da ažurira pravila i veštine?

Ovo je proces dinamičke optimizacije.

Prva verzija AGENTS.md ne može biti savršena, ali svaki put kada AI napravi grešku treba da dodate novo ograničenje. Jednom kada upadnete u zamku, sledeći put je više nećemo ponoviti.

1. Prvo izgradite bazu znanja projekta — koje su osnovne biblioteke, koji su osnovni interfejsi, koje su konvencije.
2. Izgradite razne Skills koje će prilagoditi razne tokove razvoja i procese projekta.
3. Unapred generišite dokumente sa zahtevima i korak po korak uskladite zahteve sa AI-jem.
4. Nakon generisanja koda, uradite pregled, a zatim neka AI korak po korak ispravlja.

02. Plan režim prvo

Prvo razjasnite zahteve — koristite plan režim u Codex-u. Plan retko greši, mada može biti potrebna optimizacija detalja.

Ovo je funkcija koju korisnici Codex-a najčešće zanemaruju.

Plan režim ne piše kod — samo daje plan izvršenja: koje datoteke menjati, koje rešenje koristiti, u koliko koraka završiti.

Naš zadatak je da prvo pregledamo taj plan i, ako nešto nije uredu, zatražimo prepravku. To je mnogo efikasnije nego sačekati da napiše gomilu koda, pa onda sve odbaciti i početi ispočetka.

U praksi, moj tok obično izgleda ovako:

1. Jasno opišite zahteve (pozadina + cilj + ograničenja)
2. Neka Codex uđe u plan režim i prvo iznese rešenje
3. Pregledajte rešenje, ukažite na problematične delove i tražite prilagođavanje
4. Nakon što potvrdite da je rešenje uredu, pustite ga da izvrši

Preporučujem da nakon /init ne dodajete nikakve skills — kada želite da razvijate ili popravite grešku, jednostavno recite na primer "dodaj polje u xxx listu, prvo pogledaj trenutno stanje, kako nameravaš da uradiš, ako imaš pitanja pitaj".

Tačnost je skoro 99%.

03. Velike zahteve podelite na male zadatke

Pokušajte da kompleksan zahtev podelite na više manjih kako bi AI radio u malim koracima. Nakon završetka jednog atomskog funkcionalnog zadatka, započnite novi razgovor za novi zadatak.

Šta je "atomska funkcija"?

To je najmanja funkcionalna jedinica koja se može nezavisno proveriti. Na primer, "dodaj pretragu na listu korisnika" se može podeliti na:

• Dodavanje UI komponente polja za pretragu
• Implementacija back-end API-ja za pretragu
• Povezivanje front-enda sa API-jem za pretragu
• Dodavanje rezervnog prikaza kada nema rezultata pretrage

Svaki korak je nezavisnan razgovor — kada završite i verifikujete jedan, otvorite novi razgovor za sledeći korak.

Iz dva razloga:

Prvo, prozor konteksta AI-ja je konačan. Ako ubacite previše stvari odjednom, pažnja AI-ja se razblažuje i ograničenja navedena ranije se zaboravljaju.

Drugo, "pamćenje" AI-ja se pogoršava što je razgovor duži. Što je razgovor duži, AI je skloniji kontradikcijama. Kratki razgovori koji završe jednu stvar i završe su najstabilniji način korišćenja.

04. Testiranje je najvažnija garancija kvaliteta

Najvažnije je testiranje.

Obično primenjujem ovakav pristup: kada Opus 4.8 napiše kod, neka GPT-5.5 verifikuje; kada GPT-5.5 napiše kod, neka Opus 4.8 verifikuje.

Tako dobijen kod je veoma visokog kvaliteta.

Ako niste sigurni u kvalitet koda koji je napisao AI, umesto da trošite vreme na pregled red po red, pustite drugog Agent-a da verifikuje.

Naročito za testove koji zahtevaju snimke ekrana, Codex je bolji od Claude Code-a, jer CC za otpremanje slika zahteva ctrl+v, a kada sam ranije testirao, postojala je i ograničenja dužine konteksta — ne mogu se otpremiti previše slika. Codex gotovo da nema takvih ograničenja.

Konkretno u praksi:

• U AGENTS.md napišite "pre implementacije bilo koje funkcije prvo napišite jedinični test"
• Neka AI prvo generiše test slučajeve, a nakon što pregledate testove, pustite ga da napiše implementaciju
• Nakon svake izmene koda automatski pokrenite kompletne testove

Kada sam pisao projekat PaiCLI, za svaku funkciju sam tražio od Codex-a da generiše test slučajeve.

Tokene od 200 dolara ne treba propustiti — sa test slučajevima, AI uglavnom neće grešiti, a i ako kompajliranje ne uspe, sam će popraviti.

05. Nemojte ručno menjati kod koji je napisao AI

Nemojte ručno menjati kod koji je napisao AI, jer ćete zapasti u beskonačnu petlju menjanja. Ako zaista morate da menjate, nakon izmene otvorite novi razgovor.

Zašto nastaje beskonačna petlja?

Zato što AI pri generisanju narednog koda uzima u obzir kod koji se već nalazi u kontekstu. Ako ručno promenite deo, AI ne zna šta ste promenili i zašto, pa može dogoditi da pri sledećoj izmeni pregazi vaše izmene.

Ispravan pristup je:

• Kada otkrijete problem, prirodnim jezikom recite AI-u gde je problem i kako treba da se ispravi
• Ako AI iznova i iznova ne uspe da ispravi, otvorite novi razgovor i ponovo opišite zahteve
• Ako zaista možete brže da promenite nešto nego AI, nakon što to uradite, obavezno otvorite novi razgovor i pustite AI da nastavi na osnovu izmenjenog koda

Nemojte biti previše perfekcionistički — tretirajte AI kao drugog saradnika na projektu sa više ljudi.

Ono što AI proizvede ne može 100% odgovarati vašem ukusu.

Ovaj stav je veoma važan.

AI programiranje ne teži "da svaki red bude savršen", već "da celina bude upotrebljiva i održiva".

06. Saradnja više modela

S vremena na vreme neka Codex dizajnira funkcije, zatim neka Claude Code pronalazi greške i radi pregled, a onda neka Codex oceni izmene — posle nekoliko krugova generišite sledeću listu zadataka i radite po njoj.

Suština ovog pristupa je iskorišćavanje razlika u sposobnostima različitih modela za ukrštenu proveru.

Pri razvoju PaiCLI-ja sam se strogo pridržavao ovog pravila — za svaku funkciju sam tražio od Claude Code-a i Codex-a da više puta provere, a konačno bi Claude Code radio raščlanjivanje zahteva i generisao standardni markdown plan razvoja, koji bi zatim prepušten Codex-u na izvršenje.

Visokokvalitetan vibe coding ima samo dva ključna principa.

1. Najmanje dve sesije — jedna sa ulogom pregledača, druga sa ulogom izvršioca.
2. Zauzeće konteksta ispod 30%.

Naravno, ne morate nužno koristiti dva različita modela.

Možete u istom Agentu otvoriti dve sesije — jedna za pisanje koda, druga za pregled koda. Sesija za pregled ne mora da zna detalje implementacije — samo gleda konačni diff koda i rezultate testova i procenjuje da li su razumni.

Zapamtite ovo.

Kada AI počne da popravlja greške na način "zakrpe", to znači da trenutna arhitektura više nije ispravna. Tada ga nemojte pustiti da nastavi sa zakrpama — odmah tražite od drugog modela da ponovo pregleda arhitekturu i da da plan za refaktorisanje.

07. Prompt mora biti precizan

U Promptu koristite stručne izraze — izbegavajte reči kao "malo", "nešto", "otprilike". U jednom razgovoru ne mešajte različite zahteve — otvarajte više novih razgovora.

Ne dajte AI-u previše dokumenata (svaki LLM ima ograničenje konteksta), ali mu ne dajte ni previše oskudne opise (nijedan LLM ne čita misli).

Sažeo sam osnovnu strukturu Prompta:

• Pozadina: trenutno stanje projekta, obuhvaćeni moduli
• Cilj: šta treba uraditi (opisano konkretnim tehničkim jezikom)
• Ograničenja: šta ne sme da se dira, sa čime mora biti kompatibilno, koji su zahtevi za performanse
• Kriterijumi prijema: u kom slučaju se smatra završenim

Ne opisujte zahteve samo prirodnim jezikom.

Ako menjate API, nalepite postojeću definiciju interfejsa; ako dodajete polje u bazu podataka, nalepite strukturu tabele. AI mnogo tačnije čita kod nego prirodni jezik.

Obično, kada razvijam novu funkciju, prvo tražim zvaničnu dokumentaciju, a zatim prosleđujem najnoviju zvaničnu dokumentaciju Codex-u, kako bi on prvo razumeo njen sadržaj.

Ponekad će model potajno da koristi stariju verziju.

Zato što podaci za obuku modela imaju vremensku oznaku i navikao je da rešava probleme na osnovu sopstvenog iskustva.

Čak i ako ste mu dali Skills i slično.

Kada je potrebno, moramo sami proslediti naša vlastita iskustva Codex-u.

08. Koristite zvanične modele, ne posrednike

Codex je već na vrhu — sada gotovo sav kod prepustam njemu.

Modeli zvaničnih proizvođača mogu iskusiti pad inteligencije u špicu opterećenja ili druge situacije, ali generalno su prilično stabilni i nivo inteligencije je visok.

Problem posrednika nije samo u tome što model možda bude potajno zamenjen, već iu brojnim drugim problemima: ograničenje broja zahteva, presek konteksta, kašnjenje odgovora. Ako vam se čini da Codex loše radi, prvi korak treba da bude potvrda da li koristite zvaničnu pretplatu.

Različiti modeli imaju različite performanse na različitim zadacima.

Za pisanje biznis koda, GPT 5.5 xhigh je već veoma jak; za zadatke arhitektonskog dizajna možete se prebaciti na Claude Opus.

Sposobnosti modela takođe brzo napreduju.

Ako ste pre mesec-dva mislili da nije dovoljno dobar, sada možete ponovo probati. GPT 5.5 i GPT 5 od pre pola godine nisu ni na istom nivou.

09. Arhitekturu određujete vi, implementaciju prepustite AI-u

Iako su sposobnosti AI-a već veoma jake, neke inženjerske i arhitektonske sposobnosti i dalje moramo da zadržimo.

Prilikom implementacije JLine interakcije u PaiCLI-ju naišao sam na ovaj problem — proveo sam skoro ceo dan, interakcija je uvek imala problem.

Na kraju nisam imao izbora — pročitao sam zvaničnu dokumentaciju, a zatim rekao Codex-u kako da dizajnira, i tako smo na kraju uspeli.

AI često zajedničke tačke između dva biznisa obuhvata u xxx scheduler, što je zapravo često prekomerno obavijanje — ako kasnije želite da prilagodite jedan od biznisa, a da ne obratite pažnju na izmenu schedulera, uticaćete na drugi biznis.

Ispravna podela rada je:

• Vi ste odgovorni za: strukturu direktorijuma, granice modula, tok podataka, dizajn interfejsa
• AI je odgovoran za: popunjavanje konkretne implementacije u okviru koji ste postavili

Neka prvo pročita kod, ponovi razumevanje, iznese plan, a zatim ga pratite i polako menjajte.

Codex ima funkciju vođenja — kada primetite da Codex tokom izvršavanja odstupa od vaših očekivanja, obavezno ga pravovremeno usmerite.

Pravovremeni prekid je takođe veoma neophodan.

U suprotnom, Codex bi mogao da skrene sa pravog puta. Prošle nedelje sam pri integraciji OCR-a naišao na to — zamalo uništio moj CPU.

Jedan Python proces je zauzeo 99% CPU-a i nije se zaustavljao — ventilator je zujao, mislio sam da računar ne može da prati.

AI još uvek ne može potpuno samostalno da radi — iako ga neki marketing kanali neumereno hvale, razvoj AI-ja je daleko od nivoa AGI-ja.

Moramo blagovremeno intervenisati.

ending

AI programiranje nije "prosledi zahteve i gotovo".

Oni koji ga dobro koriste bez izuzetka rade istu stvar — prenose svoje inženjersko iskustvo AI-ju.

[Tehnologija nikada nije zamišljena da zameni razmišljanje, već da ga pojača.]

Vi ste i dalje taj arhitekta, taj donosilac odluka, taj koji stoji iza svega.

Samo što je sada vaša brzina ruke postala brzina ruke AI-a.

Vaše usko grlo više nije "sporo pisanje koda", već "jasno razmišljanje, jasno viđenje".

Vi ste i dalje gospodar.