Cursor koristimo već godinu dana i on je iz temelja promijenio način na koji gradimo softver. Ne zato što piše savršen kod, već zato što nam oslobađa vrijeme i pažnju za ono što je doista važno. Manje se bavimo pisanjem popratnog koda (boilerplatea) i mehaničkim poslovima, a više donošenjem ključnih odluka. Ovaj post detaljno opisuje našu svakodnevicu s Cursorom: od postavljanja projekata za rad s agentom do lekcija koje smo naučili na teži način.
Zašto Agent Mode mijenja pravila igre
Većina AI alata za pisanje koda funkcionira kao napredni autocomplete. Prate što tipkate i predlažu sljedeću liniju ili blok koda. To je korisno, ali granica produktivnosti se brzo dosegne jer i dalje morate donijeti svaku odluku, dok alat samo dovršava započeto.
Cursorov Agent Mode donosi kvalitativni pomak. Agent može pretraživati cijeli repozitorij (koristeći ključne riječi i semantičko pretraživanje), čitati i uređivati više datoteka istovremeno, pokretati naredbe u terminalu, provjeravati tipove, pokretati lintere i iterirati sve dok ne ispuni zadani uvjet. Fokus se pomiče s pisanja pojedinačnih linija koda na implementaciju cijelih funkcionalnosti (featurea).
Ta promjena izravno utječe na organizaciju rada, što je i glavna tema ovog teksta.
Korak 1: Specifikacija prije koda
Najvažnija promjena koju smo uveli nema veze s konfiguracijom samog Cursora. Ključ je u uvođenju faze planiranja i izradi specifikacije koja prethodi svakom pisanju koda.
Kada radimo na kompleksnijoj funkcionalnosti, krećemo s fokusiranim razgovorom s reasoning modelom kako bismo ideju razradili do detalja. Cilj nije kod, već jasna specifikacija koja odgovara na pitanja: što točno gradimo, koji su rubni slučajevi, kako se rješenje uklapa u postojeću arhitekturu i kako izgleda podatkovni model. Taj dokument pohranjujemo kao spec.md unutar repozitorija.
Nakon toga, specifikaciju prosljeđujemo na razradu plana, gdje se zadatak dijeli na male, sekvencijalne korake. Svaki korak mora biti izvediv u jednom fokusiranom razgovoru s agentom i nadovezivati se na prethodni. Rezultat u datoteci prompt_plan.md izgleda ovako:
## Korak 1
Kreiraj `CreateInvoiceForm` komponentu u `src/features/invoices/` prateći
obrazac iz `src/features/users/CreateUserForm.tsx`. Uključi polja za
klijenta, iznos, datum dospijeća i stavke. Bez validacije za sada.
## Korak 2
Dodaj validaciju koristeći `FormValidator` iz `src/utils/FormValidator.ts`.
Email polja koriste `isValidEmail`, obavezna polja `isNotEmpty`,
iznos `isWholeNumber`. Prati obrazac iz `src/features/auth/LoginForm.tsx`.
## Korak 3
Poveži formu s `InvoiceService.create()` iz `src/services/InvoiceService.ts`.
Obradi greške sa strane servera koristeći `methods.setError()` na relevantnim poljima.
Prikaži success toast po završetku.
Uz plan generiramo i todo.md listu zadataka u kojoj označavamo dovršene korake. Ako morate prekinuti rad i nastaviti sljedeći dan, lista vam odmah pokazuje gdje ste stali, pa se ne morate ponovno prisjećati konteksta. Cijeli proces planiranja traje petnaestak minuta i uvijek se isplati jer eliminira potrebu za kasnijim prepravljanjem koda.
Korak 2: Agent treba poznavati vaš projekt
Agent pruža znatno bolje rezultate kada od samog početka razumije konvencije vašeg projekta. U početku smo to podcjenjivali, što nas je stajalo vremena zbog niza nepotrebnih ispravaka.
U Cursoru se to rješava pomoću direktorija .cursor/rules/ koji sadrži Markdown datoteke koje agent učitava prije svake sesije. Te datoteke nisu klasična dokumentacija, već trajne upute za agenta: koje naredbe pokretati, koja pravila slijediti i gdje se u repozitoriju nalaze referentni primjeri.
Naša pravila obično pokrivaju tri stvari: naredbe za build, provjeru i testiranje projekta; pravila koda koja pratimo; te linkove na kanonske primjere u repozitoriju.
# Naredbe
- `yarn dev`: Pokretanje razvojnog servera
- `yarn build`: Build projekta
- `yarn lint`: Pokretanje ESLinta i Stylelinta s automatskim ispravljanjem
- `yarn lint:base`: Pokretanje Prettiera i ESLinta
- `yarn lint:styles`: Pokretanje Stylelinta na SCSS fileovima
# Konvencije koda
- TypeScript posvuda, bez `any` tipova
- Komponente idu u `src/components/`, svaka u svojoj mapi s index datotekom
- API pozivi idu kroz Axios instancu definiranu u `src/lib/api.ts`
- Named exporti za komponente, default exporti za stranice
- Pogledaj `src/components/Button/Button.tsx` kao referentni primjer strukture komponente
# Workflow
- Pokreni `yarn lint` nakon svake serije promjena
- Novi featurei idu u `src/features/` prateći postojeću strukturu
- API routevi idu u `app/api/` prateći postojeće obrasce
Te se datoteke pohranjuju u Git (commit), čime cijeli tim automatski koristi isti kontekst. Time nestaje potreba da agenta pri svakom upitu podsjećate na pravila, a on prestaje ponavljati iste strukturne pogreške.
Presudna je i sama organizacija direktorija. Agent koji se kreće kroz dobro strukturiranu bazu koda brzo pronalazi datoteke i smješta novi kod na predviđeno mjesto. Iako to nije nova zamisao, rad s agentom čini cijenu loše organizacije vidljivijom i neposrednijom.
Korak 3: Ključne navike pri izvođenju
Kada imate plan i konfiguriran projekt, izvođenje se svodi na nekoliko ključnih navika.
Kratki i fokusirani razgovori
Za svaki korak u planu otvorite novi razgovor. Dugi razgovori gube na kvaliteti jer agent pri svakom odgovoru mora procesirati sve veći kontekst. Nakon mnogo izmjena razgovor postaje preopterećen i agent počinje gubiti fokus, ponekad uređuje fileove koje ne bi trebao ili ponavlja pristupe koji nisu funkcionirali. Kad za svaki zadatak krenete iznova, kontekst ostaje čist i rezultat je pouzdan.
Pišite specifične promptove
Ovo je navika s najvišim učinkom. Neodređen prompt producira rezultat koji zahtijeva više krugova ispravaka. Specifičan prompt daje upotrebljiv rezultat već u prvom pokušaju. Razlika u praksi:
Loš prompt:
Dodaj date picker na formu za fakture.
Dobar prompt:
U `src/features/invoices/CreateInvoiceForm.tsx` dodaj polje za datum dospijeća koristeći
MUI-jev DatePicker. Poveži ga kroz `renderInput` prop od FormInputa prateći
obrazac iz `src/features/projects/CreateProjectForm.tsx`. Validiraj da datum
nije u prošlosti koristeći custom validator u `src/utils/FormValidator.ts`
pod nazivom `isFutureDate`.
Drugi prompt je duži za pisanje, ali ne zahtijeva dopunska pitanja. S vremenom razvijete osjećaj za pravu razinu detalja, što otprilike odgovara tome koliko biste trebali objasniti developeru koji poznaje repozitorij, ali nije vidio ovaj konkretni feature.
Selektivno označavanje datoteka
Agent može pronaći relevantne datoteke pretragom repozitorija i to radi prilično dobro. Ali kada već znate koje su datoteke uključene u zadatak, označite ih s @ kako biste uklonili dvosmislenost i ubrzali proces. Uključivanje nebitnih datoteka ima suprotan učinak, pa budite selektivni.
Commit nakon svakog koraka
Ovu je naviku lako zanemariti, no agenti u kratkom vremenu mogu promijeniti mnoštvo datoteka. Bez čestih commitova, povratak na zadnju stabilnu verziju postaje izuzetno težak, pa čak i nemoguć. Zato nakon svakog odrađenog koraka iz plana radimo commit s jasnim opisom promjena. Ako agenta zamolite da sastavi poruku na temelju diffa, on će to obično učiniti preciznije nego što bismo mi u žurbi.
Korak 4: Pregled koda bez prečaca
AI-generirani kod ima osobinu koja ga čini težim za pregled od koda kojeg pišu ljudi. Sintaktički je ispravan, dosljednog formatiranja i konzistentnog stila. Greške su logičke i semantičke, i teško ih je previdjeti na brzom pregledu.
U borbi protiv takvih pogrešaka, strogo konfiguriran TypeScript pokazao se kao naše najmoćnije oružje. Imamo pravilo u .cursor/rules/ koje nalaže agentu da pokrene yarn lint odmah nakon uvođenja promjena. Agent tako samostalno analizira izlaz lintera te ispravlja vlastite pogreške u tipovima i stilu prije nego što uopće prikaže konačan rezultat. U protivnom se ti sitni propusti neprimjetno nakupljaju, da bi na kraju isplivali na površinu u najgorem mogućem trenutku.
Osim što se oslanjamo na TypeScript, pažljivo nadziremo rad agenta na složenijim zadacima. Budući da Cursor prikazuje promjene u stvarnom vremenu (live diff), možemo reagirati istog trenutka. Ako primijetimo da agent kreće u pogrešnom smjeru, mnogo je brže odmah ga zaustaviti i preusmjeriti nego čekati da završi pa naknadno poništavati promjene. Jednom kada agent odradi svoje, koristimo ugrađenu opciju pregleda (review) za finalnu provjeru prije nego što prihvatimo kod.
Kod većih funkcionalnosti, od agenta tražimo i kratak sažetak – što je točno promijenio i s kojim razlogom. To nam služi kao polazište za opis Pull Requesta, a kolegama koji pregledavaju kod pomaže da odmah shvate namjeru promjena bez potrebe za iščitavanjem svake pojedine linije.
Automatizacija rutinskih Git zadataka
Cursor nam je omogućio značajnu uštedu vremena automatizacijom rutinskih dijelova Git procesa. Primjerice, koristimo naredbu /pr, definiranu unutar Markdown datoteke u direktoriju .cursor/commands/:
Kreiraj pull request za trenutne promjene.
1. Pokreni `git diff` za pregled staged i unstaged promjena
2. Napiši jasnu, specifičnu commit poruku na temelju toga što se promijenilo
3. Commitaj i pushaj na trenutni branch
4. Koristi `gh pr create` za otvaranje PR-a s opisnim naslovom i tijelom
5. Vrati PR URL
Agent analizira stvarni diff te sastavlja poruku i opis PR-a koji precizno odražavaju unesene promjene. Ove naredbe pohranjujemo u Git zajedno s projektom, čime postaju dostupne svim članovima tima. Na isti smo način postavili i naredbe poput /review, koja pokreće lintere i ukazuje na potencijalne probleme, te /fix-issue, koja automatski dohvaća GitHub issue prema broju i nudi prijedlog ispravka.
Takve se automatizacije isplati uvesti za svaki proces koji ponavljate više puta dnevno. Ulaganje truda je minimalno, dok je kumulativna ušteda vremena itekako značajna.
Preciznost pri rješavanju pogrešaka
Kada se pojavi kvar kojem nije odmah jasan uzrok, uspjeh rješavanja problema (debugganja) gotovo u potpunosti ovisi o tome koliko precizno možete opisati problem. Neodređen opis vodi do lutanja u istrazi. Ako navedete točne korake za reprodukciju, konkretne ulazne podatke te jasnu razliku između očekivanog i stvarnog ponašanja, agent može instrumentirati kod, prikupiti podatke u vremenu izvršavanja (runtime) i donositi zaključke na temelju dokaza umjesto nagađanja.
Za pogreške u korisničkom sučelju, snimka zaslona (screenshot) gotovo je uvijek učinkovitija od tekstualnog opisa. Zalijepite sliku izravno u chat i opišite željeno ponašanje. Agent izvrsno razumije vizualni kontekst i može uočiti probleme s rasporedom elemenata ili renderiranjem za čiji bi opis inače trebali deseci rečenica.
Kod ponavljajućih bugova najbolje je zaboraviti na brza rješenja i problemu pristupiti sustavno. Umjesto da samo pitate 'zašto ovo ne radi', opišite agentu točne korake kako doći do greške i zamolite ga da postavi dodatne logove. Tek kad mu pošaljete stvarni izlaz tih logova, dobit ćete pravu analizu uzroka umjesto nagađanja. Možda traje dulje, ali je jedini način da bug stvarno nestane.
Što se mijenja, a što ostaje isto?
Važno je precizno definirati što integracija Cursora zapravo mijenja u procesu razvoja, jer odgovor nije samo "sve je brže."
Ono što se mijenja je cijena jasno definiranog rada. Pisanje komponenti koje prate ustaljene obrasce, dodavanje validacija na forme, povezivanje novih endpointa na postojeće servise, generiranje testova ili postupno ažuriranje ovisnosti – sve se to drastično ubrzava.
S druge strane, cijena nejasnog razmišljanja ostaje ista. Ako ne možete dovoljno precizno opisati što želite izgraditi, agent vam u tome neće pomoći. Ako je arhitektura loše postavljena, agent će samo nastaviti raditi unutar tih okvira i ubrzati stvaranje koda koji ćete kasnije morati iz temelja prepravljati. Upravo zato postoji faza planiranja o kojoj smo ranije govorili: kritičko razmišljanje mora biti odrađeno prije nego što agent krene u izvođenje.
U našem timu najveću korist od Cursora imaju developeri koji fazi izvođenja pristupaju s jasnim planom i specifičnim upitima. Oni koji ga koriste kao prečac za izbjegavanje razmišljanja dobivaju najmanje, a na kraju redovito završe s kodom koji je neupotrebljiv.
Kako početi?
Ako ovu metodologiju uvodite u tim koji je dosad nije koristio, redoslijed koraka je presudan za uspjeh.
Prvo usvojite naviku planiranja. Prije nego što napišete ijednu liniju koda, odvojite vrijeme za izradu specifikacije i redoslijeda upita. To će podići kvalitetu rezultata bez obzira na to koji alat koristite, a svaki sljedeći korak učiniti predvidljivijim.
Zatim postavite pravila unutar .cursor/rules/. Tu uključite naredbe za pokretanje i provjeru projekta, osnovne konvencije pisanja koda i poveznice na nekoliko referentnih primjera u repozitoriju. Sve to odmah pohranite u Git. Nova pravila dodajte postupno. Tek kada primijetite da agent dvaput ponovi istu pogrešku, nikako unaprijed ili napamet.
Nakon toga izgradite disciplinu čestih commitova. Svaki dovršeni korak plana zaslužuje vlastiti commit s jasnom porukom. Iako zvuči zamorno, to je razlika između popravka lošeg rezultata u trideset sekundi i dvadeset minuta raspetljavanja promjena u desetak različitih datoteka.
Kada uspostavite ova tri temelja, sve ostalo – poput prilagođenih naredbi, paralelnih agenata i detaljnih pravila – postaje nadogradnja na stabilnoj bazi, a ne dodatni kaos na nesigurnim temeljima.
