Jak pisać kod żeby sugestie były trafniejsze

Czego się nauczysz

• Jak wpływać na jakość inline suggestions bez zmiany modelu
• Dlaczego komentarze, nazwy i otwarte pliki realnie poprawiają trafność podpowiedzi
• Które ustawienia pomagają, a które tylko kosmetycznie zmieniają doświadczenie

Lepsze sugestie nie biorą się z przypadku

Kiedy Copilot daje słabą sugestię, bardzo łatwo powiedzieć: “model jest kiepski”.

Czasem to prawda. Ale bardzo często problem jest bliżej.

Inline suggestions są wyjątkowo czułe na lokalny kontekst. To oznacza, że jakość podpowiedzi zależy nie tylko od modelu, ale też od tego, jak wygląda Twój kod, jak komunikujesz intencję i jak pracujesz w edytorze.

Ta lekcja jest właśnie o tym: jak sprawić, żeby Copilot miał większą szansę trafić dobrze za pierwszym razem.

Nazwy są sygnałem, nie dekoracją

Pierwsza rzecz jest banalna, ale fundamentalna: dobre nazwy robią ogromną różnicę.

Jeśli zmienna nazywa się data, item, obj albo temp, to model widzi znacznie mniej niż wtedy, gdy nazwa opisuje rolę i intencję.

To ważne zwłaszcza w inline suggestions, bo tutaj Copilot często bazuje na bardzo lokalnym fragmencie kodu. Każdy sygnał semantyczny ma znaczenie.

Porównaj dwa przypadki:

• data, result, value
• invoiceItems, retryPolicy, customerSegment

W drugim przypadku model dostaje znacznie mocniejszy kontekst jeszcze zanim cokolwiek dopowiesz komentarzem.

Komentarz może być najtańszym promptem w całym workflow

Dokumentacja VS Code pokazuje to wprost: komentarze pomagają prowadzić sugestie inline.

I to naprawdę działa.

Zamiast zostawiać pusty szkielet funkcji, możesz opisać:

• jaki algorytm chcesz użyć
• jakie warunki brzegowe mają być obsłużone
• jakie pola ma mieć tworzony obiekt
• jaki styl implementacji preferujesz

To nie musi być długi prompt. Często wystarczy jedno krótkie zdanie, które ustawia kierunek.

Na przykład zamiast liczyć, że Copilot odgadnie wszystko sam, lepiej napisać komentarz typu:

• użyj walidacji wejścia przed przetwarzaniem
• zwróć tylko aktywnych użytkowników posortowanych po dacie
• użyj prostego BFS bez rekurencji

To jest bardzo tani sposób poprawy jakości suggestions.

Otwórz pliki, które naprawdę mają znaczenie

Dokumentacja przypomina, że inline suggestions biorą pod uwagę nie tylko bieżący plik, ale też inne otwarte pliki.

To jest jeden z prostszych i częściej niedocenianych trików.

Jeśli pracujesz nad kodem, który zależy od:

• typu z innego pliku
• kontraktu API
• helpera używanego w tym samym module
• istniejącego wzorca implementacji

to otwarcie powiązanego pliku często poprawia sugestie bardziej niż dalsze poprawianie promptu w głowie.

To szczególnie dobrze działa przy:

• komponentach i ich propsach
• DTO i mapperach
• serwisach korzystających z istniejących helperów
• testach dopisywanych do znanego wzorca

Spójny kod daje spójniejsze predictions

Copilot lepiej działa tam, gdzie kod ma powtarzalne wzorce.

Jeżeli w projekcie konsekwentnie:

• nazywasz rzeczy podobnie
• obsługujesz błędy podobnie
• budujesz funkcje w podobnym stylu
• testujesz według stałego schematu

to suggestions są bardziej trafne, bo model widzi powtarzalność i może ją kontynuować.

Jeśli w każdym pliku obowiązuje inna estetyka i inna struktura, suggestions częściej robią się losowe albo zbyt ogólne.

To oznacza ciekawą rzecz praktyczną: dobre standardy kodu poprawiają nie tylko czytelność repo, ale też skuteczność AI.

Nie wrzucaj kilku intencji naraz do jednego miejsca

Inline suggestions najlepiej działają wtedy, gdy lokalna intencja jest czytelna.

Jeżeli w jednym fragmencie jednocześnie:

• zmieniasz nazwę
• przebudowujesz logikę
• poprawiasz styl
• dopisujesz nową odpowiedzialność

to model dostaje mieszany sygnał i jakość sugestii spada.

Lepszy workflow zwykle wygląda tak:

1. doprecyzuj jedną intencję
2. pozwól suggestions ją pociągnąć
3. dopiero potem przejdź do następnej warstwy zmiany

To jest mniej efektowne, ale częściej daje lepszy wynik.

Ustawienia pomagają, ale nie zastąpią dobrego kontekstu

Z dokumentacji i settings reference wynikają dwie klasy ustawień:

• takie, które realnie wpływają na komfort pracy
• takie, które głównie zmieniają sposób prezentacji

Do pierwszej grupy zwykle należą:

• github.copilot.enable, jeśli chcesz sterować suggestions globalnie albo per język
• editor.inlineSuggest.minShowDelay, jeśli chcesz ograniczyć agresywność podpowiedzi
• ustawienia NES, gdy pracujesz dużo na edycji istniejącego kodu

Do drugiej grupy częściej należą rzeczy typu:

• font dla inline completions
• toolbar on hover
• część ustawień czysto wizualnych

To ważne, bo łatwo wpaść w tuning kosmetyczny zamiast poprawić prawdziwy problem, czyli słaby kontekst wejściowy.

Kiedy wyłączyć suggestions dla części pracy

Nie każdy fragment repo powinien być traktowany tak samo.

Dokumentacja pozwala sterować suggestions per język. To praktyczne, bo są miejsca, gdzie inline suggestions pomagają bardzo, i takie, gdzie ich wartość jest mniejsza.

Na przykład część zespołów ogranicza je w:

• markdownach
• plaintext
• polach inputowych do commita
• językach albo plikach, gdzie koszt błędnej sugestii jest większy niż zysk

To nie jest oznaka słabości workflow. To oznaka selektywności.

Najlepszy workflow: małe sterowanie, duży zysk

Jeśli chcesz poprawić jakość suggestions bez przekombinowania, skup się na czterech rzeczach:

• czytelne nazwy
• krótki komentarz z intencją tam, gdzie trzeba
• otwarte powiązane pliki
• spójny lokalny wzorzec kodu

To jest zestaw, który najczęściej daje największy zwrot przy najmniejszym koszcie.

Ćwiczenie praktyczne

Weź jedną prostą funkcję i zrób trzy warianty pracy:

1. Zostaw pusty szkielet i zobacz pierwszą sugestię.
2. Cofnij zmianę i dopisz krótki komentarz opisujący cel funkcji.
3. Otwórz dodatkowo powiązany plik z typem, helperem albo podobną implementacją.

Po każdej próbie oceń:

• czy sugestia była bardziej konkretna
• czy lepiej trafiła w styl projektu
• czy wymagała mniej ręcznych poprawek

Na końcu sprawdź jeszcze, czy dla tego typu pracy warto zmniejszyć lub zwiększyć agresywność suggestions przez ustawienia.

To ćwiczenie zwykle bardzo szybko pokazuje, że model nie działa w próżni. Dobre wejście daje lepsze wyjście.

Kluczowe wnioski

• Jakość inline suggestions zależy mocno od lokalnego kontekstu, nie tylko od modelu.
• Czytelne nazwy i komentarze znacząco zwiększają szansę trafnej podpowiedzi.
• Otwarte powiązane pliki pomagają Copilotowi zrozumieć szerszy obraz zadania.
• Spójne wzorce w repo poprawiają jakość kontynuacji kodu.
• Ustawienia pomagają, ale nie zastąpią dobrze zakomunikowanej intencji.

Co dalej

Moduł inline masz już domknięty, więc kolejnym naturalnym krokiem jest wejście w chat i zobaczenie, kiedy warto wyjść z rytmu edytora do rozmowy, a kiedy lepiej zostać przy pracy bezpośrednio w kodzie.