Modele w Copilot: jak dobrać model do zadania

Czego się nauczysz

• Jak myśleć o modelach w Copilot bez przywiązania do jednego vendora
• Kiedy wybrać model szybki, a kiedy reasoning model
• Jak model wpływa na Chat, Inline Chat, agenta i koszty użycia

Najpierw jedna ważna rzecz

Większość osób zaczyna od złego pytania: “który model jest najlepszy?”

W praktyce to zwykle zła rama.

Lepsze pytanie brzmi: jaki model jest najlepszy do tego konkretnego zadania, w tym konkretnym momencie.

W dokumentacji VS Code to widać dość jasno. Chat daje dostęp do różnych modeli, ale ich rola nie jest symetryczna. Jedne są lepsze do szybkich edycji i prostych pytań. Inne lepiej radzą sobie z planowaniem, refaktorem i dłuższym rozumowaniem.

To ważne, bo GitHub Copilot nie jest już jednym, stałym silnikiem pod spodem. To bardziej warstwa pracy z modelami.

Co faktycznie zmieniasz, gdy zmieniasz model

Zmiana modelu nie zmienia tylko “stylu odpowiedzi”. Zmieniasz kilka rzeczy naraz:

• szybkość odpowiedzi
• jakość rozumowania przy zadaniach wieloetapowych
• tolerancję na duży kontekst
• wsparcie dla tool calling w agentach
• koszt użycia albo multiplier premium requests

To ostatnie często jest pomijane. Jeśli pracujesz na płatnym planie, model może mieć inny mnożnik kosztu niż model bazowy albo tryb Auto. To oznacza, że wybór modelu wpływa nie tylko na jakość, ale też na ekonomię codziennej pracy.

Szybki model vs reasoning model

Z dokumentacji VS Code wynika prosty podział:

• szybki model: drobne poprawki, szybkie pytania, małe transformacje kodu, krótkie iteracje
• reasoning model: złożony refaktor, decyzje architektoniczne, debugowanie wieloetapowe, planowanie zmian

To ma sens również z praktyki.

Jeżeli prosisz Copilota o zmianę nazwy, prostą funkcję pomocniczą albo dopisanie brakującego warunku, reasoning model zwykle niczego nie “ratuje”. Najczęściej tylko dodaje latencję.

Jeżeli natomiast prosisz o rozpisanie planu migracji, analizę kilku podejść albo debug przy błędzie rozchodzącym się po paru plikach, szybki model częściej idzie w pierwszą sensownie brzmiącą odpowiedź, a nie w najlepszą.

To jest różnica, którą realnie czuć po kilku dniach pracy.

Auto nie jest trybem dla leniwych

VS Code ma też tryb Auto. To nie jest tylko wygodny default dla początkujących.

W oficjalnej dokumentacji Auto jest opisane jako mechanizm, który dobiera model tak, żeby utrzymać sensowną wydajność i ograniczać problemy z dostępnością konkretnych modeli. Dla płatnych użytkowników dochodzi jeszcze temat zniżki na request multiplier.

Jeśli nie masz jeszcze wyrobionego workflow, Auto jest sensownym punktem startu. Nie dlatego, że “AI samo wie najlepiej”, tylko dlatego, że na początku ważniejsze jest nauczenie się dobrych zadań i dobrego kontekstu niż ręczne żonglowanie pickerem co 5 minut.

Kiedy przełączać model ręcznie

Ręczne przełączenie modelu ma sens, gdy widzisz któryś z tych sygnałów:

• odpowiedź jest szybka, ale zbyt płytka
• model gubi zależności między kilkoma plikami
• plan brzmi poprawnie, ale nie domyka edge case’ów
• agent potrzebuje modelu z dobrym wsparciem dla narzędzi
• chcesz zejść z kosztu przy prostych zadaniach

To jest dobry filtr roboczy:

• jeśli zadanie da się opisać w 1-2 zdaniach i dotyczy lokalnej zmiany, zacznij od szybkiego modelu
• jeśli zadanie wymaga myślenia o kolejności kroków, trade-offach albo weryfikacji hipotez, przejdź na reasoning model

Chat, Inline Chat i inline suggestions to nie to samo

Tu łatwo wpaść w uproszczenie, że “zmiana modelu zmienia wszystko”. Nie całkiem.

W dokumentacji VS Code są rozdzielone trzy obszary:

• model dla rozmów w Chat
• domyślny model dla Inline Chat
• model dla inline suggestions

To oznacza, że możesz mieć inny workflow dla rozmowy o architekturze i inny dla drobnych zmian bezpośrednio w edytorze.

To jest bardzo praktyczne. Chat może działać na modelu nastawionym na planowanie i reasoning, a inline suggestions na modelu szybszym, bo tam liczy się rytm pracy i niska latencja.

Agent mode stawia dodatkowy warunek

W dokumentacji jest jeszcze jeden ważny detal: nie każdy model nadaje się tak samo do agentów.

Jeżeli pracujesz w agent mode, lista dostępnych modeli jest ograniczona do tych, które dobrze wspierają tool calling. To ważne, bo agent nie kończy na tekście. On ma czytać pliki, odpalać komendy, analizować wyniki i iterować.

Jeśli model jest dobry w generowaniu tekstu, ale słabszy w pracy narzędziowej, jego przewaga może się kończyć dokładnie tam, gdzie zaczyna się sensowna autonomia.

Thinking effort - kiedy warto, a kiedy tylko muli

Niektóre reasoning models pozwalają ustawić thinking effort.

Brzmi kusząco, ale to nie jest suwak “więcej inteligencji”. To jest suwak kosztu i czasu rozumowania.

Wyższy effort ma sens, kiedy:

• porównujesz kilka wariantów rozwiązania
• rozbijasz problem na kroki
• debugujesz coś nieoczywistego
• robisz przegląd architektury albo plan migracji

Niższy effort ma sens, kiedy:

• poprawiasz pojedynczy fragment kodu
• dopisujesz test do znanego przypadku
• pytasz o coś mechanicznego

W praktyce zbyt wysoki effort przy prostych zadaniach tylko wydłuża odpowiedź i zapycha kontekst tokenami rozumowania. To nie daje proporcjonalnie lepszego wyniku.

Bring Your Own Key to nie jest domyślna ścieżka

VS Code wspiera też BYOK, czyli podpięcie własnego klucza do modelu spoza zestawu wbudowanego. To jest ciekawe, ale nie warto od tego zaczynać.

Powód jest prosty: to rozszerza wybór modeli, ale jednocześnie dokłada nowe warstwy złożoności - capabilities modelu, zgodność z narzędziami, kwestie filtrowania i ograniczenia planów. Dla nauki Copilota lepiej najpierw opanować modele wbudowane i dopiero potem eksperymentować z własnym providerem.

Mój praktyczny filtr wyboru modelu

Jeśli masz wyrobić sobie jeden nawyk po tej lekcji, niech będzie ten:

• prosty kod i szybkie iteracje: model szybki albo Auto
• refaktor, plan, debug, architektura: reasoning model
• agent z narzędziami: model, który dobrze wspiera tool calling
• praca kosztowa albo duży wolumen: patrz na multiplier, nie tylko na jakość odpowiedzi

Model nie naprawi słabego promptu i słabego kontekstu. Ale źle dobrany model potrafi dodać tarcie tam, gdzie wcale nie było potrzebne.

Ćwiczenie praktyczne

Zrób to od razu na jednym, małym zadaniu w swoim repo:

1. Otwórz Chat i wybierz model szybki albo tryb Auto.
2. Poproś o prostą zmianę, na przykład dopisanie walidacji argumentów w jednej funkcji.
3. Powtórz to samo zadanie na reasoning modelu.
4. Porównaj trzy rzeczy: czas odpowiedzi, trafność pierwszej propozycji i liczbę poprawek, które musiałeś dopowiedzieć.
5. Potem daj trudniejsze zadanie: “zaproponuj plan refaktoru tego modułu i wskaż ryzyka”.
6. Znowu porównaj wynik szybkiego modelu z reasoning modelem.

Po tym ćwiczeniu zwykle widać jedną rzecz: nie istnieje jeden najlepszy model. Jest tylko lepszy model do danego typu pracy.

Kluczowe wnioski

• W Copilot ważniejsze od nazwy modelu jest dopasowanie modelu do zadania.
• Szybkie modele wygrywają przy krótkich iteracjach, reasoning models przy zadaniach wieloetapowych.
• Chat, Inline Chat i inline suggestions mogą korzystać z różnych ustawień modelu.
• W agent mode liczy się nie tylko jakość tekstu, ale też wsparcie dla narzędzi.
• Auto jest dobrym defaultem, dopóki nie wiesz jeszcze, gdzie naprawdę potrzebujesz ręcznego przełączania.

Co dalej

W następnej lekcji przechodzimy do sedna skuteczności Copilota: nie do modelu, tylko do tego, co model faktycznie widzi. To tam zaczyna się realna jakość odpowiedzi.