Prompt engineering za developere: Kako napisati upite koji daju precizan kôd, a ne nagađanja

Najbitnije u tekstu (Key Takeaways):

• Prompt engineering za developere nije veština pisanja ukrasnih teksta u chatu, već inženjerska disciplina oblikovanja ulaznog konteksta, pravila i sistemskih ograničenja kako bi veliki jezički modeli (LLM) generisali produkciono spreman, deterministički i bezbedan kôd.

• Većina grešaka i „halucinacija“ veštačke inteligencije pri generisanju koda nastaje usled nepreciznog definisanja sistemskih pravila (System Prompts), nedostatka konteksta o arhitekturi projekta i neodgovarajućeg izbora tehnika zadavanja upita (Few-Shot, Chain-of-Thought, System Instructions).

• Integracija alata poput Cursor-a, Claude Code-a, GitHub Copilot-a ili agenata zasnovanih na Model Context Protocol-u (MCP) zahteva prelazak sa jednostavnog generisanja pojedinačnih funkcija na upravljanje .cursorrules datotekama i arhitektonskim kontekstnim prozorima (Context Windows).

• Ovladavanje inženjeringom upita omogućava programerima da drastično skrate vreme refaktorišućeg rada, eliminišu sintaksne i logičke bagove i preusmere težište svog rada sa rutinskog tipkanja koda na projektovanje složenih sistemskih arhitektura.

Generativna veštačka inteligencija nepovratno je ušla u svakodnevni rad softverskih inženjera. Alati poput ChatGPT-ja, Claude-a, Cursor IDE-a, GitHub Copilot-a i novijih CLI agenata obećavaju desetostruki skok u produktivnosti, pisanju unit testova i brzini prototipovanja. Međutim, ako pitate iskusnog senior inženjera kako izgleda njegov rad sa AI asistencijom u produkciji, dobićete prilično iznijansiran odgovor: od oduševljenja do teške frustracije.

Najčešći problem na koji programeri nailaze nije u tome što veštačka inteligencija „ne zna“ programski jezik. Problem je u tome što AI model, ostavljen bez preciznih inženjerskih ograda, naginje ka izmišljanju nepostojećih biblioteka, korišćenju zastarelih metoda, ignorisanju unutrašnjih konvencija projekta i generisanju koda koji na površini deluje ispravno, ali krije suptilne logičke i bezbednosne bagove.

Razlika između inženjera koji troši sate na „pregovaranje sa AI-jem“ i ispravljanje pokvarenog koda i inženjera koji jednim upitom dobija besprekoran, optimizovan blok koda spremnog za produkciju leži u novoj primarnoj veštini: u pitanju je prompt engineering za developere.

Ovo nije nauka o tome „kako lepo zamoliti robota da napiše funkciju“. Ovo je striktna metodologija struktuiranja konteksta, ograničenja, primera i sistemskih uloga koja probabilistički LLM (Large Language Model) algoritam usmerava da deluje deterministički. U nastavku teksta pružićemo dubinski, tehnički i praktičan vodič kroz strukturu idealnog inženjerskog upita, napredne obrasce zadavanja zadataka i metode za potpunu kontrolu nad izlaznim kodom.

Zašto LLM halucinira kôd: Probabilistička priroda naspram determinističke sintakse

Da bismo razumeli kako napisati upit koji daje precizan kôd, moramo najpre sagledati kako veliki jezički modeli iznutra procesuiraju informacije.

Softverski inženjering je po svojoj prirodi deterministički. Kod ili radi ili ne radi; sintaksa je ili ispravna ili nije; alokacija memorije ili poštuje pravila ili uzrokuje curenje. Jezički modeli su, sa druge strane, probabilističke matrice. Oni ne „razmišljaju“ o logici programa na način na koji to čini čovek — oni na osnovu unutrašnjih težina i prethodnih tokena predviđaju koji je sledeći najverovatniji token u nizu.

Kada programer pošalje lenj, neprecizan ili previše uopšten upit poput:

„Napiši mi skriptu u Python-u za preuzimanje podataka sa API-ja i čuvanje u bazi.“

Model ulazi u takozvani prostor visoke entropije (pretpostavki). Budući da mu niste rekli:

• Koja verzija Python-a se koristi (3.10 ili 3.12+)?

• Da li se koristi asinhroni rad (asyncio / httpx) ili sinhroni (requests)?

• Koju biblioteku za rad sa bazom preferirate (SQLAlchemy, SQLModel, Tortoise-ORM ili čist psycopg3)?

• Kakva je struktura baze i kako se rukuje greškama (Error Handling)?

Model je primoran da nagađa. On poseže za „najprosečnijim“ rešenjem iz svog skupa podataka za trening, što često rezultira kodom koji koristi zastarele biblioteke, nema nikakvu validaciju ulaznih podataka i ne uklapa se u arhitekturu vašeg projekta. Ako se unutar tog predviđanja nađe rupa u podacima, model će proizvesti halucinaciju — izmisliće naziv metode ili uveze paket koji uopšte ne postoji na PyPI ili npm registrima.

Efikasan prompt engineering za developere ima samo jedan primarni zadatak: da dovede entropiju izlaznih opcija na minimum i zatvori sve puteve za nagađanje modela.

Ovu potrebu za jasnom definicijom uloga i odgovornosti analizirali smo u našoj studiji o senioritetu u doba AI alata i razlici između mlađeg developera i arhitekte, gde razumevanje šire slike i arhitektonskih kompromisa čini osnovu seniorskog rada.

Anatomija perfektnog inženjerskog upita: C-C-R-I-O okvir

U praksi se najbolje pokazao takozvani C-C-R-I-O okvir (Context, Constraint, Role, Instruction, Output format). Svaki produkciono spreman upit za generisanje koda mora u sebi sadržati sledećih pet elemenata:

[C-C-R-I-O OKVIR ZA GENERISANJE KODA]
├── 1. ROLE (Uloga)            ──> Ko je AI u ovom zadatku (npr. Senior Rust/Go Arch)
├── 2. CONTEXT (Kontekst)      ──> Okruženje, verzije, baze, postojeći kôd
├── 3. INSTRUCTION (Instrukcija)─> Šta tačno kôd mora da uradi (korak po korak)
├── 4. CONSTRAINT (Ograničenja)──> Šta NIPOŠTO ne sme da koristi ili uradi
└── 5. OUTPUT (Format izlaza)  ──> Kako kôd mora biti formatiran (čist kôd, bez priče)

Pogledajmo kako izgleda primena ovog okvira u praksi:

Loš primer (Površan upit):

„Napiši mi kôd za autentifikaciju korisnika u Go-u.“

Dobar primer (C-C-R-I-O inženjerski upit):

[ROLE]
Djeluješ kao Senior Go Backend Inženjer koji se pridržava idiomatnog Go koda i industrijskih bezbednosnih standarda.

[CONTEXT]
Razvijamo REST API mikroservis u Go 1.22 koji koristi `net/http` (sa nativnim ruterom), PostgreSQL bazu i `pgx/v5` drajver. Aplikacija trči unutar Docker kontejnera.

[INSTRUCTION]
Napiši funkciju `AuthenticateUser(ctx context.Context, email, password string) (*User, string, error)` koja:
1. Proverava da li korisnik postoji u bazi preko prosleđenog email-a.
2. Verifikuje heširanu lozinku koristeći `golang.org/x/crypto/bcrypt`.
3. Ako su podaci ispravni, generiše signed JWT token sa važenjem od 15 minuta (koristeći `golang.org/x/oauth2` ili `golang-jwt/jwt/v5`).
4. Vraća identifikator korisnika i generisani token.

[CONSTRAINTS]
- NIPOŠTO nemoj koristiti ORM biblioteke (GORM, Ent); piši čist SQL upit sa pripremljenim izjavama (prepared statements).
- NIPOŠTO nemoj ignorisati greške; svaka greška mora biti obmotana (wrapped) sa `fmt.Errorf("AuthenticateUser: %w", err)`.
- Nemoj izmišljati eksterne pakete van zvaničnog `golang-jwt/jwt/v5`.
- Zadrži logiku heširanja potpuno odvojenom od mrežnog sloja.

[OUTPUT FORMAT]
Vrati SAMO produkciono spreman Go kôd, kompletno komentarišan na srpskom jeziku u GoDoc formatu, sa uključenim import blokom. Bez uvodnog teksta, bez objašnjenja pre ili posle koda.

Kada AI dobije ovako definisan zadatak, prostor za nagađanje sveden je na nulu. Rezultat je čist, bezbedan i idiomatski Go kôd koji možete direktno kopirati u projekat.

O izboru pravog jezika za pisanje brze i bezbedne backend infrastrukture opširnije možete pročitati u našem uporednom vodiču kroz Rust vs Go za sistemsko programiranje.

Napredne tehnike: Few-Shot, Chain-of-Thought i System Instructions

Kada rešavate složenije inženjerske probleme (poput pisanja novih algoritama, refaktorišućeg koda ili integracije kompleksnih API-ja), jednostavan upit nije dovoljan. U tim situacijama primenjujemo napredne tehnike inženjeringa upita.

1. Few-Shot Prompting (Zadavanje učećih primera)

Veliki jezički modeli fantastično uče „u hodu“ ako im unutar samog upita pružite jedan ili dva primera kako vaši postojeći funkcije ili unit testovi izgledaju.

Umesto da objašnjavate stilska pravila i konvencije koda rečima, jednostavno mu dajte primer:

Prilagodi novi modul tako da prati IDENTIČAN stil pisanja unit testova kao u sledećem primeru:

### PRIMER KOJI SLEDIŠ (Few-Shot Example):
func TestCalculateTax(t *testing.T) {
    tests := []struct {
        name    string
        amount  float64
        want    float64
        wantErr bool
    }{
        {"valid amount", 100.0, 20.0, false},
        {"negative amount", -10.0, 0.0, true},
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := CalculateTax(tt.amount)
            if (err != nil) != tt.wantErr {
                t.Errorf("CalculateTax() error = %v, wantErr %v", err, tt.wantErr)
            }
            if got != tt.want {
                t.Errorf("CalculateTax() = %v, want %v", got, tt.want)
            }
        })
    }
}

### ZADATAK:
Napiši unit test za funkciju `ProcessPayment(amount float64, currency string) (string, error)` prateći gornji format sa tabelarno definisanim testnim slučajevima.

Pružanjem ovog jedinog primera, u potpunosti ste eliminisali rizik da AI napiše testove u nekom drugom, neželjenom stilu (npr. koristeći testify paket umesto nativnog Go testing paketa).

2. Chain-of-Thought (Lančano razmišljanje za složene algoritme)

Kada zamolite AI model da izmesta reši složen matematički ili arhitektonski problem u jednom prolazu, on često pravi greške jer pokušava da generiše kôd pre nego što je „razmislio“ o svim graničnim slučajevima (edge cases).

Tehnika Chain-of-Thought (CoT) primorava model da razbije problem na korake pre nego što napiše ijednu liniju koda:

Želim da razvijemo algoritam za detekciju prevara u platnim transakcijama u realnom vremenu.

Pre nego što napišeš kôd, prođi kroz sledeće korake:
KORAK 1: Navedi sve granične slučajeve (edge cases) i potencijalne rasne uslove (race conditions) pri concurrent obradi.
KORAK 2: Objasi predloženu strukturu podataka i vremensku složenost algoritma u Big-O notaciji.
KORAK 3: Napiši pseudokôd i objasni kako se rukuje otkazivanjem mrežne veze.
KORAK 4: Tek nakon što potvrdiš prethodne korake, napiši kompletnu implementaciju u Rust-u.

Eksperimenti pokazuju da prisustvo klauzule „razmišljaj korak po korak“ smanjuje stopu sintaksnih i logičkih grešaka u generisanom kodu za više od 40%.

3. System Instructions i .cursorrules (Trajno ukalupljivanje)

U modernim razvojnim okruženjima kao što je Cursor IDE ili prilikom upotrebe Custom GPT-jeva i Claude Project-a, nema potrebe da iznova kucate iste kontekste za svaki zadatak.

Upotrebom sistemskih fajlova poput .cursorrules ili .clauderules postavljenih u korenskom direktorijumu vašeg projekta, vi trajno definišete arhitektonska pravila.

Primer jedne .cursorrules datoteke za moderan TypeScript / Next.js projekat:

{
  "rules": [
    "Uvek koristi TypeScript u strict mode-u. Zabranjena je upotreba `any` tipa.",
    "Sve komponente moraju biti Functional Components napisane u Arrow syntax-i.",
    "Za upravljanje stanjem koristi Zustand; zabranjeno je korišćenje Redux-a.",
    "Prilikom pisanja stilova koristi isključivo Tailwind CSS klase u liniji.",
    "Svi pozivi ka API-ju moraju koristiti Zod biblioteku za validaciju ulaznih podataka.",
    "Svaki fajl mora sadržati odgovarajući unit test u istom direktorijumu sa ekstenzijom `.test.ts`."
  ]
}

Svaki put kada u Cursor-u pritisnete Cmd+K ili pokrenete chat, AI automataki učitava ova pravila i generiše kôd koji je u potpunosti usklađen sa standardima vašeg tima.

Povezanost sa AI agentima i novim mrežnim standardima

Prompt engineering se brzo menja. Više se ne radi samo o pisanju teksta unutar chata — danas upiti direktno pokreću autonomne AI agente koji komuniciraju sa operativnim sistemom, mrežom i bazama podataka.

Kada AI agentu date mogućnost da samostalno izvršava komande u terminalu, neprecizan ili zlonamerno izmanipulisan upit može dovesti do katastrofalnih posledica po infrastrukturu.

Ove opasnosti su posebno izražene kroz novonastale koncepte:

1. Model Context Protocol (MCP): Standard koji omogućava AI agentima da čitaju lokalne fajlove i baze podataka.

2. Indirektno ubacivanje komandi (Indirect Prompt Injection): Scenario u kom zlonamerni podatak sa interneta preuzima kontrolu nad agentom.

O tome šta se dešava kada komande izmaknu kontroli i kako postaviti neprobojna okruženja za rad AI agenata detaljno smo pisali u tekstu o bekstvu AI agenta iz sandbox-a i lekcijama iz stvarnih napada.

Takođe, ako vaši AI agenti generišu kôd koji napaja mikroservisne arhitekture, preporučujemo da pročitate naš vodič kroz primenu WebAssembly-ja izvan veba za kreiranje ultra-brzih mikroslužbi, kao i uporedni prikaz za izbor Kubernetes-a ili Serverless arhitekture.

Testiranje, refaktoring i bezbednosna provera generisanog koda

Zlatno pravilo inženjeringa upita glasi: Nikada nemojte verovati generisanom kodu bez rigorozne verifikacije.

AI ne snosi odgovornost ako vaš kôd padne na produkciji ili otvori ozbiljnu sigurnosnu ranjivost. Odgovornost uvek snosi čovek inženjer koji je prihvatio taj Pull Request.

Proces provere generisanog koda mora pratiti sledeće korake:

Korak 1: Prompt za reviziju bezbednosti (Security Audit Prompt)

Pre nego što prihvatite izgenerisanu funkciju, pošaljite je nazad modelom uz namensku sigurnosnu proveru:

Djeluješ kao Ekspert za Sajber Bezbednost (Application Security Specialist).
Pregledaj sledeći blok koda i identifikuj potencijalne ranjivosti po OWASP standardu (npr. SQL Injection, XSS, BOLA, nedozvoljeno curenje memorije ili trka za resursima).

[UBAČENI KÔD]

Za svaku uočenu ranjivost objasni scenarij napada i ponudi popravljenu verziju koda.

Ova praksa je izuzetno važna radi sprečavanja BOLA i BOPLA ranjivosti o kojima smo pisali u vodiču o anatomiji napada kroz loše podešene API-je.

Korak 2: Prompt za refaktoring i čitljivost koda

Generisani kôd često ume da bude preterano opširan ili da sadrži dupliranu logiku. Primena pravila Clean Code arhitekture izvodi se kroz upit:

Refaktoriši sledeći kôd tako da:
1. Smanjiš ciklomatsku kompleksnost (Cyclomatic Complexity) na vrednost ispod 5.
2. Podeliš veliku funkciju na manje, čiste, kompozitne funkcije koje prate Single Responsibility Principle (SRP).
3. Eliminišeš ugnježđene `if-else` blokove primenom obrazaca ranog izlaska (Guard Clauses / Early Returns).

Finansijski i poslovni uticaj: Kako ekonomičnost upita smanjuje oblačne račune

Nepažljivo pisanje upita ne samo da troši vreme, već direktno uvećava troškove kompanije pri upotrebi komercijalnih API-ja za LLM (poput OpenAI ili Anthropic API-ja).

Cena API poziva obračunava se po broju utrošenih ulaznih i izlaznih tokena (Input/Output Tokens).

Ako u kontekstni prozor (Context Window) bez potrebe ubacite stotine hiljada linija nebitnog koda ili celokupne baze podataka, vaš pojedinačni upit može koštati i po nekoliko dolara. Kada se to pomnoži sa desetinama inženjera u timu koji svakodnevno šalju stotine upita, mesečni računi za AI API-je mogu dostići desetine hiljada evra.

Saveti za optimizaciju troškova tokena (Prompt Cost Optimization):

• Smanjite šum u kontekstu (Context Pruning): Šaljite samo one fajlove, interfejse i deklaracije tipova koji su direktno povezani sa funkcijom koju pišete. Nemojte ubacivati cele module ako vam treba samo jedna struktura.

• Upotrebite RAG i vektorske baze za pretragu koda: Ugradite alate koji pretražuju vašu bazu koda i AI-ju šalju samo najrelevantnije odlomke.

• Koristite manje modele za jednostavne zadatke: Koristite brze i jeftinije modele (npr. Claude 3.5 Haiku, GPT-4o-mini) za pisanje unit testova ili dokumentacije, a teže i skuplje modele (Claude 3.5 Sonnet, OpenAI o1/o3) sačuvajte za složeno arhitektonsko projektovanje.

Upravljanje ovim troškovima uklapa se u širu FinOps disciplinu. Takođe, za razumevanje širih SEO i GEO trendova u eri veštačke inteligencije, pročitajte naše tekstove o SearchGPT vs Perplexity vs Google SGE modelima, kao i vodič kroz GEO optimizaciju i pozicioniranje brenda u AI pretraživačima i kako pravilno strukturirati podatke na sajtu pomoću Schema.org standarda.

Na kraju, dok provodite sate radeći sa AI alatima na pisanju i verifikaciji koda, ne zaboravite na lično zdravlje i ergonomiju.

A kako se menja potražnja za programerima koji vladaju inženjeringom upita na našim prostorima proverite u redovnom izveštaju o tržištu IT poslova u Srbiji i najtraženijim profilima, kao i u vodiču kroz pravni i poreski okvir za poslovanje.

Uporedni pregled obrazaca zadavanja upita

Da bismo na jednom mestu sistematizovali razlike u pristupima i pomogli vam da preusmerite svoje svakodnevne navike pisanja upita, pripremili smo komparativni pregled:

Zaključak: Od tipkača koda do arhitekte konteksta

Veštačka inteligencija nije zamenila softverske inženjere, ali inženjeri koji su ovladali naprednim tehnikama inženjeringa upita ubrzano zamenjuju one koji odbijaju da se prilagode.

Pisanje koda u modernoj eri prestaje da bude veština pamtljivog kucanja sintakse iz glave. Težište inženjerskog posla se pomera ka projektovanju konteksta, postavljanju sistemskih ograničenja, kritičkoj analizi generisanih rešenja i bezbednosnoj verifikaciji.

Savladavanjem prompt engineering-a za developere, usvajanjem C-C-R-I-O okvira, kreiranjem .cursorrules datoteka i primenom Few-Shot i Chain-of-Thought tehnika, vi preuzimate potpunu kontrolu nad veštačkom inteligencijom. AI prestaje da bude nepredvidivi sagovornik koji nagađa rešenja, i postaje vaš najbrži, najprecizniji i najefikasniji inženjerski saradnik u izgradnji softvera budućnosti.

Često postavljana pitanja (FAQ)

1. Šta je to „Prompt Engineering za developere“ i zašto je važan?

Prompt engineering za developere je inženjerska disciplina oblikovanja ulaznog konteksta, pravila, ograničenja i primera kako bi veliki jezički modeli (LLM) generisali precizan, bezbedan i produkciono spreman kôd. Važan je zato što eliminise AI halucinacije, smanjuje vreme potrebno za refaktoring i omogućava bržu izradu softvera bez sintaksnih i logičkih grešaka.

2. Šta je to C-C-R-I-O okvir za pisanje upita?

C-C-R-I-O je metodološki okvir za struktuiranje upita koji se sastoji od pet ključnih elemenata:

1. Role (Uloga): Definisanje uloge modela (npr. Senior Go Developer).

2. Context (Kontekst): Objašnjenje okruženja, verzija jezika i zavisnosti.

3. Instruction (Instrukcija): Precizan opis zadatka korak po korak.

4. Constraint (Ograničenja): Zabrana korišćenja nepoželjnih biblioteka ili loših praksi.

5. Output Format (Format izlaza): Definisanje načina na koji kôd mora biti vraćen (npr. čist kôd bez teksta).

3. Šta je to „Few-Shot Prompting“ u generisanju koda?

Few-Shot Prompting je tehnika u kojoj unutar samog upita pružate model jednim ili dva konkretna primera kako vaš postojeći kôd ili unit testovi izgledaju. Model analizira te primere i generiše novi kôd koji u potpunosti prati vaš identičan stil, konvencije i strukturu.

4. Kako .cursorrules fajl pomaže pri programiranju sa AI alatima?

Fajl .cursorrules (ili .clauderules) je konfiguraciona datoteka koja se postavlja u korenski direktorijum projekta. U njoj se definišu trajna pravila koda (npr. zabranjeni tipovi, obavezni okviri, stilovi komponenata). AI asistent u Cursor IDE-u ili Claude-u automatski učitava ova pravila pri svakom upitu, obezbeđujući da izgenerisani kôd uvek poštuje arhitekturu vašeg projekta.

5. Zašto AI modeli često izmišljaju nepostojeće biblioteke (halucinacije)?

AI modeli haluciniraju jer su probabilistički algoritmi koji predviđaju sledeći najverovatniji token na osnovu trening podataka. Ako u upitu ne navedete koje tačno biblioteke i verzije treba koristiti, ili ako tražite funkcionalnost koja ne postoji u standardnoj biblioteci, model će pokušati da „popuni prazninu“ i kreiraće naziv paketa koji zvuči logično, ali fizički ne postoji na registrima poput PyPI ili npm-a.