Vaš tim verovatno pogrešno koristi GitHub Copilot. Evo šta zaista daje rezultate.

Većina kompanija koje kupe GitHub Copilot na kraju ga ne iskoristi ni približno koliko bi mogla.

Copilot je trenutno verovatno najrasprostranjenija AI coding pretplata u enterprise okruženjima, što znači da dosta timova već ima pristup. Problem je u tome što skoro niko ne prođe obuku kako da ga koristi kako treba.

Ljudi otvore Copilot chat panel u VS Code-u, ukucaju neodređene instrukcije, dobiju osrednji rezultat i ponavljaju isti ciklus kroz svaki modul i svaki fajl. Bez strukture, bez konzistentnosti, bez ikakvog efekta koji se vremenom akumulira.

To je bacanje para na moćnu pretplatu.

Jedna napomena pre saveta za timove: za lične projekte ne bih koristio GitHub Copilot. Po mom mišljenju, za taj slučaj se ne isplati, pogotovo posle GitHub-ovih izmena individualnih Copilot planova iz aprila 2026.

Problem nije u modelu

Kada tim kaže da je Copilot razočarao, razlog je skoro uvek isti: svi ga koriste kao izolovanog asistenta umesto kao deo zajedničkog inženjerskog workflow-a.

Svaki developer piše svoje ad-hoc promptove. Svako objašnjava codebase na svoj način. Svako iznova otkriva isti kontekst koji bi već trebalo da bude negde dokumentovan. Rezultat je tačno ono što biste i očekivali: nekonzistentan output, iste greške koje se ponavljaju i gomila vremena potrošenog na objašnjavanje istih stvari ispočetka.

Ako želite bolje rezultate, prestanite da tretirate Copilot kao magični chat box i počnite da ga tretirate kao sistem kome treba struktura.

Promptovi i skillovi treba da žive u repou

Ono što je meni zaista upalilo bilo je centralizovanje AI instrukcija unutar samog codebase-a. Definisao sam dve stvari: promptove i skillove.

Promptovi su “šta”. Govore Copilotu koji zadatak da odradi.

Skillovi su “kako”. Opisuju korake, šablone, ograničenja i konvencije kojih Copilot treba da se drži dok radi taj zadatak.

Zajedno, te dve stvari daju modelu dovoljno konteksta da proizvede koristan output umesto generičkog nagađanja.

Napisati ih jednom bilo je samo pola posla. Ono što je zaista napravilo razliku jeste to što su čuvani u repozitorijumu kao zajednički izvor istine. Ceo tim je koristio iste instrukcije. To je odmah eliminisalo dosta uzaludnog truda i nekonzistentnosti.

Umesto da svaki developer kreće od praznog chat box-a, kretali su od dokumentovanog workflow-a.

Konkretan primer: migracija sa Angular 8 na 16

Ovaj pristup sam koristio tokom migracije sa Angulara 8 na Angular 16. To nije bio neki uski refactor. Migracija je zahvatala TypeScript, template-e, CSS, konfiguracione fajlove, dependency-je i Angular Material od verzije 8 do 16.

Upravo na takvim poslovima se nestrukturirano korišćenje AI-ja raspada. Ako svaki inženjer traži izmene na malo drugačiji način, dobijate malo drugačiji output na svakom mestu. Na migraciji se te sitne nekonzistentnosti brzo nagomilaju.

Zato sam formalizovao workflow.

Napisao sam promptove za svaku fazu migracije. Napisao sam skillove koji su objašnjavali kako treba odraditi svaki tip izmene. Onda sam napravio poseban review prompt čiji je jedini zadatak bio da pregleda izmene koje je AI generisao i proveri da li su zaista ispravne.

Taj poslednji deo je bitan. Kod koji je generisao AI ne sme da ide pravo u branch bez druge provere. Review prompt mi je dao konzistentan način da proverim output, umesto da se oslanjam na to šta će ko slučajno primetiti.

Ovo je samo jedan primer. Workflow vašeg tima može izgledati potpuno drugačije. Možda modernizujete legacy frontend, pišete testove oko starog servisnog sloja ili generišete repetitivni interni CRUD. Detalji nisu toliko bitni koliko sama vežba.

Sedite kao tim i postavite jednostavno pitanje: za šta je ovom timu AI zapravo potreban?

Kad odgovorite na to, korisni promptovi se pišu mnogo lakše.

Šta konkretno treba da uradite

Ako vaš tim već plaća Copilot, ovo je praktična polazna tačka:

1. Prvo definišite workflow. Krenite od problema, ne od alata. Shvatite gde se AI uklapa u vaš postojeći inženjerski proces pre nego što napišete ijedan prompt.
2. Napišite promptove i skillove i čuvajte ih u repou. Držite jedan zajednički izvor istine. Ako AI pravi izmene u codebase-u, instrukcije iza tih izmena takođe treba da budu verzionisane.
3. Iskoristite /init na samom početku. /init daje Copilotu početni set projektnih instrukcija na osnovu vašeg repozitorijuma, što je mnogo bolje od počinjanja svakog chata od nule. Zvanični VS Code vodič za Copilot best practices ga preporučuje, a meni je bio veliki dobitak jer mi je dao nešto konkretno za doterivanje umesto da gradim kontekst ispočetka u svakom razgovoru.
4. Iterirajte po projektu. Workflow koji radi za migraciju neće biti isti onaj koji radi za razvoj novih feature-a. Tretirajte promptove i skillove kao projektne resurse, a ne kao univerzalne šablone.

Suština

Timovi koji izvuku pravu vrednost iz Copilota obično imaju jednu zajedničku stvar: uložili su rad unapred da definišu strukturirane instrukcije koje se mogu ponovo koristiti. Nivo pretplate sa tim nema skoro nikakve veze.

Ako vaš tim već ima Copilot, nemojte potrošiti sledeći mesec raspravljajući da li je alat dobar. Potrošite jedno popodne na definisanje workflow-a, pisanje promptova i dokumentovanje skillova u repou.

To će vam reći više o stvarnoj vrednosti Copilota nego još sto neodređenih chat poruka.