5 trików GitHub Copilot, które zmienią Twój workflow

Sam Copilot nie robi aż takiej różnicy, jak wiele osób zakłada.

Różnicę robi to, jak z nim pracujesz.

Widziałem już oba skrajne scenariusze. Ten pierwszy: model dostaje byle jaki prompt, generuje byle jaki kod, a potem człowiek ręcznie odkręca skutki. Ten drugi: ten sam model, ale dostaje dobry kontekst, jasne ograniczenia i prosty proces weryfikacji. Efekt jest nieporównywalny.

Poniżej pięć rzeczy, które dają mi największy zwrot z pracy z GitHub Copilot w VS Code.

1. Zamiast pytać „napisz to”, najpierw ustaw ograniczenia

Najczęstszy błąd jest prosty: ludzie opisują feature, ale nie opisują granic.

Model wtedy robi dokładnie to, do czego został zachęcony - zgaduje. Czasem zgadnie dobrze. Czasem dołoży over-engineering, niepotrzebne abstrakcje albo rozwiązanie niezgodne z frameworkiem.

Dlatego zamiast:

Dodaj endpoint do pobierania zamówień użytkownika.

wolę coś w tym stylu:

Dodaj endpoint do pobierania zamówień użytkownika.
Użyj istniejących wzorców z projektu.
Bez dodawania nowych warstw abstrakcji.
Zwróć tylko pola potrzebne do listy w UI.
Jeśli framework ma wbudowane rozwiązanie, preferuj je zamiast custom code.

To mała zmiana, ale mocno ogranicza pole do „twórczości”, która później kosztuje w review.

2. Każ większy plan sprawdzić jeszcze raz, zanim ruszysz z implementacją

Jedna z najlepszych rzeczy, jakie można zrobić z Copilotem, to kazać mu zakwestionować własny plan.

Jeśli zadanie ma więcej niż kilka kroków, proszę go najpierw o plan. A potem od razu o review tego planu pod kątem prostoty i zgodności z platformą.

Używam bardzo prostego promptu:

Review this plan for:
1. Over-engineering - can it be simpler?
2. Framework alignment - does it use built-in features?
3. Root cause - are we fixing the actual problem or symptoms?
4. Maintenance cost - will this be easy to maintain in 6 months?

To jest szczególnie przydatne tam, gdzie model ma tendencję do rozlewania zmian po całym repo. Jedno takie sprawdzenie potrafi zamienić 20 edycji plików w jedną zmianę konfiguracji.

3. Dawaj kontekst selektywnie, nie hurtowo

„Kontekst to klucz” jest prawdą, ale tylko do pewnego momentu.

Za mało kontekstu i model zgaduje. Za dużo kontekstu i zaczyna mulić, gubić priorytety albo przepalać uwagę na rzeczy, które w danym tasku nie mają znaczenia.

W praktyce najlepiej działa mi otwieranie tylko plików, które naprawdę biorą udział w zadaniu:

aktualna implementacja,
typy lub interfejsy,
testy,
jeden podobny przykład z repo.

Nie pięć podobnych przykładów. Nie pół projektu „na wszelki wypadek”.

Jeśli wątek jest długi, a Copilot ma za sobą dużo testów, logów i narzędziowych odpowiedzi, po prostu zaczynam nowy chat. Z praktyki to daje lepszy wynik niż próba ratowania kontekstu, który już jest zaśmiecony.

4. Używaj Copilota do pętli: plan -> implementacja -> self-review

Najgorsze użycie Copilota to jedno strzałowe „napisz kod”.

Lepszy workflow wygląda tak:

poproś o plan,
zawęź rozwiązanie,
każ wdrożyć zmianę,
każ zrobić self-review jak code reviewer,
dopiero wtedy oceniaj diff.

Przykład prostego self-review:

Review the proposed change like a senior code reviewer.
Focus on unnecessary complexity, framework misalignment,
security issues, and maintenance cost.
Point out anything that should be simplified before merge.

To nie zastępuje code review człowieka. Ale bardzo dobrze wycina oczywiste głupoty, zanim jeszcze pokażesz komuś diff.

5. Skonfiguruj instrukcje raz, zamiast powtarzać to samo w każdym czacie

Największy zysk z Copilota nie bierze się z pojedynczego promptu. Bierze się z tego, że model wreszcie przestaje za każdym razem zgadywać podstawowe zasady projektu.

Dlatego warto mieć porządne .github/copilot-instructions.md i jeśli projekt jest większy - także instrukcje zawężone do folderów albo typów plików.

To jest szczególnie ważne, gdy chcesz pilnować takich rzeczy jak:

brak niepotrzebnych abstrakcji,
preferowanie wbudowanych mechanizmów frameworka,
styl testów,
konwencje DTO i API,
zasady bezpieczeństwa,
sposób komentowania i dokumentowania kodu.

Jeśli tego nie zrobisz, będziesz w każdym tasku od nowa tłumaczył modelowi to samo. To jest strata czasu i jakości.

Wniosek

GitHub Copilot nie daje przewagi dlatego, że „pisze kod szybciej”. To potrafi dziś wiele narzędzi.

Przewaga pojawia się wtedy, gdy ograniczasz mu pole do zgadywania, pilnujesz kontekstu i każesz mu przejść przez prostą pętlę weryfikacji przed pokazaniem wyniku.

Model nadal bywa bardzo dobry w odpowiadaniu na pytanie „jak to napisać?”. Problem zaczyna się wtedy, gdy bez kontroli zaczyna odpowiadać też na pytanie „co w ogóle warto pisać?”.

I właśnie dlatego najlepsze „triki” do Copilota nie są magicznymi komendami. To po prostu dobra inżynieria pracy z narzędziem.