W poprzednim wpisie poznaliśmy trzy podstawowe cegiełki ekosystemu Copilot: Agents, Skills i Instructions. Ale żeby skutecznie z nich korzystać, trzeba najpierw zrozumieć jedną fundamentalną rzecz: jak Copilot w ogóle "widzi" Twój projekt.
To jest temat który sprawia, że doświadczeni developerzy dostają naprawdę różne wyniki z Copilota – mimo że obaj siedzą przy tym samym projekcie i zadają podobne pytania. Różnica prawie zawsze leży w kontekście. Kto go dostarcza świadomie, ten dostaje trafne odpowiedzi. Kto zakłada że Copilot "jakoś to wie" – dostaje generyczne sugestie.
Copilot (jak każdy model językowy) nie "pamięta" Twojego projektu między sesjami. Przy każdym zapytaniu model widzi dokładnie tyle, ile zmieści się w jego oknie kontekstu (context window) – czyli w jednym, konkretnym "kadrze" informacji który jest mu przekazany w momencie generowania odpowiedzi.
🔍 Okno kontekstu w prostych słowach
Wyobraź sobie że Copilot to bardzo zdolny developer, który właśnie dołączył do Twojego projektu – ale nie ma dostępu do GitHuba, nie czytał historii PR-ów, nie był na żadnym spotkaniu. Jedyne co widzi, to kartki na biurku które mu położyłeś przed chwilą. Te kartki to właśnie okno kontekstu.
Im lepiej dobierzesz co leży na tych kartkach – tym trafniejsze sugestie dostaniesz. Im bardziej ogólne kartki – tym bardziej ogólne odpowiedzi.
W praktyce okno kontekstu Copilota w VS Code wypełniają trzy rodzaje informacji, które omówię po kolei.
Trzy warstwy kontekstu
1IMPLICITKontekst automatyczny – dostajesz go za darmo
VS Code automatycznie dołącza do każdego zapytania pewien zestaw informacji bez żadnego działania z Twojej strony. Trafia tam:
aktywny plik w edytorze – plik który masz otwarty i w którym pracujesz
zaznaczony fragment kodu – jeśli coś zaznaczyłeś przed wysłaniem pytania
historia bieżącej rozmowy – poprzednie pytania i odpowiedzi w aktywnym wątku chatu
język programowania i typ projektu – wykrywane na podstawie rozszerzenia pliku i struktury katalogu
⚠️ Pułapka nr 1: "aktywny plik" to nie "otwarte zakładki"
Wielu developerów zakłada że Copilot widzi wszystko co mają otwarte w zakładkach VS Code. To nieprawda – automatycznie trafia tylko plik aktualnie aktywny (ten na którym jest kursor). Pozostałe otwarte pliki są poza zasięgiem, chyba że je jawnie dołączysz. To jeden z najczęstszych powodów dlaczego Copilot "nie rozumie" zależności między klasami.
2EXPLICITKontekst jawny – dostarczasz go sam
To kontekst który aktywnie wskazujesz w zapytaniu. Masz do dyspozycji kilka mechanizmów:
#file – konkretny plik
Wpisując #file:NazwaPliku.cs w chatcie dołączasz zawartość wskazanego pliku do kontekstu. Copilot może wtedy porównywać, odwoływać się i generować kod spójny z tym plikiem.
// Przykład użycia w chatcie:
Napisz testy jednostkowe dla tej klasy. #file:OrderService.cs #file:IOrderRepository.cs
#codebase – przeszukiwanie całego repozytorium
Dodanie #codebase do zapytania uruchamia semantyczne przeszukiwanie całego indeksu repozytorium. Copilot sam decyduje które pliki są ważne dla Twojego pytania i dołącza je do kontekstu.
// Przykład:
#codebase Gdzie w projekcie obsługujemy autentykację? Pokaż mi wszystkie miejsca.
🔍 @workspace vs #codebase – jaka różnica?
@workspace
#codebase
Tryb
Chat (pytania i odpowiedzi)
Agent mode (wykonywanie zadań)
Wynik
Odpowiedź tekstowa w chatcie
Może generować / edytować pliki
Kiedy używać?
Szerokie pytania o projekt, overview
Konkretne zadania wymagające zmian w kodzie
GitHub rekomenduje używanie #codebase w Agent mode, a @workspace w zwykłym chatcie.
#fetch – zawartość strony internetowej
Za pomocą #fetch https://adres.pl możesz dołączyć do kontekstu zawartość dowolnej strony – dokumentację biblioteki, specyfikację API, changelog. Copilot pobiera stronę i bierze jej treść pod uwagę przy odpowiedzi.
// Przykład:
Jak zaimplementować paginację? #fetch https://docs.nswag.org/api/pagination
3INSTRUCTIONSKontekst z instrukcji – trwałe tło
To warstwa którą omawialiśmy w poprzednim wpisie. Pliki *.instructions.md są automatycznie dołączane do kontekstu dla plików które pasują do skonfigurowanych globalnych wzorców. Nie musisz ich wpisywać ręcznie – działają w tle przez cały czas.
Copilot "czyta" te instrukcje zanim odpowie na Twoje pytanie. To dlatego właśnie Instructions są tak potężnym narzędziem – standardy kodowania, wzorce architektoniczne i zasady projektu obowiązują w każdej sesji bez żadnego wysiłku z Twojej strony.
Jak działa indeks repozytorium?
Żeby #codebase i @workspace działały szybko i trafnie, Copilot utrzymuje indeks repozytorium. Warto wiedzieć jak on działa, bo to bezpośrednio wpływa na jakość odpowiedzi.
🔍 Trzy rodzaje indeksu – który masz?
Typ indeksu
Kiedy działa?
Szybkość / dokładność
Remote index
Repo hostowane na GitHub lub Azure DevOps
✅ Najszybszy, semantyczny, skaluje się do dużych repozytoriów
Local index
Repo hostowane lokalnie lub poza GitHub/ADO
✅ Semantyczny, ale wolniejszy, przechowywany na maszynie
Basic index
Gdy local indexing niedostępny
⚠️ Prostsze algorytmy, mniej trafny dla złożonych zależności
⚠️ Pułapka nr 2: uncommitted changes nie trafiają do remote index
Remote index jest budowany ze scommitowanego stanu repozytorium. Jeśli masz lokalne zmiany których jeszcze nie scommitowałeś – agent ich nie widzi przez indeks. VS Code próbuje to obejść hybrydowym podejściem (śledzi zmodyfikowane pliki lokalnie), ale to nie jest to samo co pełny indeks. Dlatego gdy Copilot "nie widzi" Twoich ostatnich zmian – to często właśnie ten powód.
Jak kontekst działa w trybie agentycznym?
W zwykłym chatcie kontekst jest statyczny – Copilot dostaje to co mu dasz i na tym pracuje. W Agent mode jest inaczej: agent aktywnie i iteracyjnie zbiera kontekst którego potrzebuje do wykonania zadania.
Konkretnie: agent może wykonać wiele rund przeszukiwania kodu, zanim zacznie pisać jakikolwiek output. Szuka powiązanych plików, sprawdza zależności, weryfikuje istniejące wzorce – i robi to autonomicznie, bez pytania Cię o każdy krok.
🌟 Przykład: agent przy zadaniu "dodaj endpoint"
Piszesz: "Dodaj endpoint POST /orders/{id}/cancel który anuluje zamówienie."
Agent zanim napisze pierwszą linię kodu:
Przeszukuje codebase pod kątem istniejących kontrolerów – żeby dopasować styl i strukturę
Znajduje klasę Order i sprawdza jakie ma pola i metody
Weryfikuje jak wygląda obsługa błędów w innych endpointach
Sprawdza jak skonfigurowana jest autoryzacja
Dopiero po tym wszystkim generuje endpoint – który od razu pasuje do Twoich wzorców, używa Twoich konwencji nazewnictwa i obsługuje błędy tak jak reszta projektu. Bez jednego słowa z Twojej strony o architekturze.
To jest właśnie ta różnica o której mówiłem w pierwszym wpisie – agent nie czeka aż mu powiesz wszystko. Sam buduje obraz projektu z dostępnego kontekstu.
🔍 Co trafia do kontekstu, a co nie?
To jest sekcja którą chciałem dodać od siebie, bo widzę że brak tej wiedzy jest jednym z najczęstszych powodów frustracji seniorów z Copilotem. Człowiek pracuje przy projekcie od miesięcy, "wie" jak on wygląda – i zakłada że Copilot też to wie. A Copilot dostaje tylko to co faktycznie trafia do kontekstu.
Poniżej pełna mapa – co jest w zasięgu Copilota, a co nie:
✅ Trafia do kontekstu
Aktywny plik w edytorze
Zaznaczony fragment kodu
Historia bieżącego wątku chatu
Pliki jawnie wskazane przez #file
Wyniki wyszukiwania przez #codebase
Pliki *.instructions.md (pasujące scopem)
Zawartość strony przez #fetch
Output terminala (gdy go dołączysz)
Dane z MCP serverów (gdy skonfigurowane)
Scommitowany kod z indeksu repo
❌ NIE trafia do kontekstu
Otwarte zakładki których nie wskazałeś
Historia poprzednich wątków chatu
Lokalny uncommitted kod (częściowo)
Komentarze w PR-ach i issues na GitHubie*
Twoja wiedza dziedzinowa o projekcie
Decyzje architektoniczne nieudokumentowane w kodzie
Historia zmian (git log, git blame)
Dokumentacja zewnętrzna (Confluence, Notion)*
Zmienne środowiskowe i sekrety
Zawartość kontenerów Docker w czasie runtime
* Możliwe do dołączenia przez odpowiednie MCP servery (GitHub MCP, Confluence MCP, itp.)
⚠️ Najczęstsze błędy seniorów z kontekstem
"Copilot powinien wiedzieć jak mamy zrobioną architekturę" – nie wie, jeśli nie ma tego w instrukcjach ani w jawnie wskazanych plikach. Nieudokumentowana wiedza istnieje tylko w głowach.
Długa sesja = rozmazany kontekst – im dłuższy wątek chatu, tym starszy kontekst jest kompresowany lub wypychany. Gdy Copilot zaczyna się "gubić" po dłuższej rozmowie, najskuteczniejsze rozwiązanie to otwarcie nowego wątku z precyzyjnym kontekstem.
Pytanie bez zaznaczenia kodu – "popraw ten błąd" bez zaznaczenia fragmentu to jak wołanie do serwisu "mój samochód wydaje dziwny dźwięk". Im bardziej precyzyjnie wskażesz co Copilot ma widzieć, tym lepsze dostaniesz sugestie.
Ignorowanie context window indicator – VS Code pokazuje w chatcie ile kontekstu jest zajęte. Gdy pasek dochodzi do końca, VS Code automatycznie kompresuje historię. Warto to obserwować przy długich sesjach agentycznych i w razie potrzeby samemu zarządzać tym co zostaje w wątku.
Jak świadomie zarządzać kontekstem?
Skoro wiesz już co trafia do kontekstu – kilka praktycznych zasad które warto wdrożyć od zaraz:
1. Nowy wątek = nowy kontekst
Każde większe zadanie zaczynaj w nowym wątku chatu. Stary kontekst z poprzedniego zadania to szum który zaciemnia odpowiedzi. Otwórz nowy wątek, wskaż precyzyjnie pliki których potrzebujesz i zacznij od czystej kartki.
2. Zostań w wątku przez całe zadanie
Odwrotna zasada: jeśli pracujesz nad jednym user story – nie zmieniaj wątku. Historia rozmowy to wartościowy kontekst który pomaga Copilotowi rozumieć gdzie jesteś i co już zostało postanowione. Zmiana wątku w połowie zadania to utrata tej ciągłości.
3. Udokumentuj to co Copilot musi wiedzieć
Jeśli regularnie zaczynasz sesje od tłumaczenia tej samej architektury – to sygnał że powinieneś to zapisać w .instructions.md. Wiedza która żyje tylko w głowie seniora jest niewidoczna dla Copilota i dla każdego nowego developera w zespole.
4. Zaznaczaj kod zanim zapytasz
Zanim wyślesz pytanie do chatu – zaznacz fragment kodu którego ono dotyczy. To najprostszy sposób na zapewnienie że Copilot odpowiada na właściwy problem, a nie zgaduje na podstawie nazwy pliku.
🌟 Przykład: dobry vs zły prompt z perspektywy kontekstu
❌ Słaby prompt
✅ Dobry prompt
"Napisz testy dla serwisu zamówień"
Copilot nie wie: który serwis, jakie wzorce testów używamy, jak mockujemy zależności, co to znaczy "dobry test" w tym projekcie
"Napisz testy jednostkowe dla metody CancelOrder. #file:OrderService.cs #file:OrderServiceTests.cs (jako przykład wzorca)"
Copilot widzi: konkretną metodę, wzorzec testów z istniejącego pliku, może dopasować styl
"Napraw błąd w kontrolerze"
Który kontroler? Który błąd? Co powinno działać?
[zaznaczasz metodę] "Ta metoda rzuca NullReferenceException gdy order jest null. Popraw obsługę błędu zgodnie z wzorcem z #file:ProductController.cs"
💪 Zadanie dla Ciebie – audyt kontekstu w Twoim projekcie
Zanim przejdziesz do następnego wpisu, zrób ten szybki audyt:
Otwórz VS Code w swoim projekcie i sprawdź w Status Bar czy masz Remote index czy Local index – to mówi Ci jak dobra jest baza do przeszukiwania przez #codebase.
Sprawdź czy w projekcie istnieje plik .github/copilot-instructions.md – jeśli nie, to Copilot nie ma żadnego trwałego kontekstu o projekcie.
Pomyśl: jakie informacje wklejasz ręcznie na początku każdej sesji? Architektura? Stack technologiczny? Wzorce? To kandydaci na plik instrukcji.
Spróbuj raz zadać to samo pytanie dwa razy: raz bez żadnego kontekstu, raz z #file i precyzyjnie zaznaczonym fragmentem. Porównaj jakość odpowiedzi.
Podsumowanie
Copilot jest tak dobry jak kontekst który dostaje. To prosta zasada, ale w praktyce większość ludzi traktuje go jak wyroczni która "powinna wiedzieć" – i potem jest rozczarowanie.
✅ Trzy warstwy kontekstu: automatyczny (aktywny plik, historia), jawny (#file, #codebase, #fetch) i instrukcje (.instructions.md)
✅ Indeks repozytorium: remote (GitHub/ADO), local lub basic – im wyżej, tym trafniejsze wyszukiwanie
✅ Agent mode: zbiera kontekst iteracyjnie i autonomicznie zanim zacznie pisać kod
✅ Uncommitted changes: częściowo poza zasięgiem remote indexu – warto o tym pamiętać
✅ Zarządzanie kontekstem: nowe wątki dla nowych zadań, dokumentowanie wiedzy w instrukcjach, precyzyjne zaznaczanie kodu
W kolejnym wpisie przejdziemy do praktyki: konfiguracja Copilota krok po kroku – na poziomie użytkownika, workspace i repozytorium. Pokażę jak ustawić wszystko tak, żeby Copilot od pierwszej chwili wiedział z czym pracuje.
