Explain, Fix, Code Review i naprawianie błędów terminala

Czego się nauczysz

• Jak dobrać Explain, Fix, Review i terminal quick fix do właściwej intencji
• Dlaczego lokalne smart actions są często lepsze niż ręczne otwieranie chatu
• Jak nie mylić wyjaśniania, naprawiania i review kodu

Jedno kliknięcie, ale cztery różne pytania

Z perspektywy interfejsu te akcje wyglądają podobnie. Często są obok siebie w menu kontekstowym albo pojawiają się jako szybka akcja przy problemie.

Ale z perspektywy pracy inżynierskiej odpowiadają na cztery różne pytania:

• Explain: co tu się właściwie dzieje?
• Fix: co trzeba poprawić, żeby to działało?
• Review: jakie są ryzyka, błędy albo braki jakości?
• Terminal quick fix: czemu to polecenie nie przeszło i co teraz zrobić?

Jeśli pomylisz te intencje, bardzo łatwo uzyskasz odpowiedź, która brzmi sensownie, ale nie rozwiązuje Twojego realnego problemu.

Explain jest do zrozumienia, nie do poprawiania

Smart action Explain działa najlepiej wtedy, gdy kod istnieje i chcesz skrócić czas wejścia w temat.

To dobry wybór, gdy:

• wracasz do starego fragmentu po kilku tygodniach
• czytasz kod innego developera
• próbujesz zrozumieć zależności przed refaktorem

Ważne jest to, że Explain nie powinno być traktowane jako dowód poprawności kodu. To narzędzie do rozumienia, nie do audytu.

Jeżeli prosisz o wyjaśnienie, a w głowie masz tak naprawdę pytanie “czy to jest bezpieczne?”, to lepszy będzie Review. Jeśli myślisz “jak to naprawić?”, użyj Fix.

Fix skraca drogę od problemu do pierwszej propozycji naprawy

Dokumentacja opisuje dwa główne wejścia do naprawiania:

• zaznaczasz kod i wybierasz Generate Code > Fix
• albo korzystasz z code action przy problemie kompilacji lub lintingu

To jest ogromna przewaga nad pisaniem ręcznego promptu. Produkt już wie, gdzie jest problem i w jakim fragmencie kodu trzeba działać.

W praktyce Fix jest szczególnie mocny przy:

• lokalnych błędach składniowych
• prostych problemach typów
• oczywistych naruszeniach API
• refaktorach, które zostały przerwane w połowie

Słabiej radzi sobie tam, gdzie błąd objawów siedzi w innym miejscu niż błąd przyczyny. Wtedy jedna poprawka w selekcji nie wystarczy i trzeba wejść poziom wyżej w Agent albo Chat View.

Review to nie to samo co Explain

To częsty błąd początkujących użytkowników Copilota.

Review nie służy do tłumaczenia, co robi kod. Review służy do oceny jakości zmian albo fragmentu. Dokumentacja mówi wprost, że VS Code może tworzyć komentarze review zarówno dla zaznaczonego bloku w edytorze, jak i dla całego PR przy użyciu rozszerzenia GitHub Pull Requests.

To oznacza, że Review jest dobrym wyborem, gdy chcesz zapytać:

• gdzie tu są edge case’y
• czego nie przetestowaliśmy
• co jest nieczytelne
• gdzie grozi regresja

To ważne, bo Review ustawia model w roli drugiej warstwy kontroli jakości, a nie generatora rozwiązania.

W praktyce dobrze jest używać Review po Fix, a nie zamiast Fix. Najpierw naprawiasz, potem prosisz o ocenę ryzyk tej naprawy.

Terminal quick fix zamienia błąd w kontekst

Jedna z najbardziej niedocenianych smart actions siedzi przy terminalu. Gdy polecenie nie przechodzi, VS Code pokazuje sparkle w gutterze i proponuje quick fix do wyjaśnienia problemu.

To jest mała rzecz, ale usuwa bardzo realne tarcie. Zamiast kopiować output do chatu albo ręcznie opisywać, co się stało, zaczynasz z gotowym kontekstem błędu terminalowego.

To ma sens szczególnie przy:

• błędach CLI
• źle podanych flagach
• problemach z buildem
• nieudanych skryptach npm, pnpm albo test runnerach

Znów jednak obowiązuje filtr: terminal quick fix świetnie wyjaśnia lokalny problem, ale nie zawsze sam naprawi przyczynę, jeśli problem jest głębiej w konfiguracji projektu.

Smart actions wygrywają blisko miejsca problemu

To główna przewaga całej tej grupy funkcji.

Zamiast zaczynać od zera w Chat View, używasz akcji dokładnie tam, gdzie problem się pojawia:

• na zaznaczonym kodzie
• przy błędzie kompilacji
• przy review bloku
• przy nieudanym poleceniu w terminalu

To zwykle daje lepszy pierwszy wynik, bo produkt sam dołącza właściwy kontekst lokalny.

Jak dobrać akcję bez chaosu

Mój praktyczny filtr jest bardzo prosty:

• jeśli nie rozumiesz kodu, użyj Explain
• jeśli widzisz lokalny błąd, użyj Fix
• jeśli chcesz ocenić jakość albo ryzyko, użyj Review
• jeśli polecenie w terminalu nie działa, użyj terminal quick fix

Jeśli po jednym kroku nadal nie masz rozwiązania, wtedy dopiero rozszerz problem do większej rozmowy w Chat View albo do pracy agentowej.

To ważne, bo wiele osób zbyt wcześnie odpala cięższy workflow do małego, lokalnego problemu.

Ćwiczenie praktyczne

Wybierz jeden mały fragment kodu albo jeden realny błąd i przeprowadź cztery mini-próby:

1. Użyj Explain na zaznaczonym fragmencie.
2. Użyj Fix na tym samym albo pokrewnym problemie.
3. Zrób Review poprawionego kodu.
4. Jeśli masz nieudane polecenie w terminalu, użyj quick fix do diagnozy.

Po ćwiczeniu zapisz:

• która akcja dała najbardziej użyteczną odpowiedź
• która odpowiedź była tylko opisem, a która realnie przesuwała pracę do przodu
• czy któryś problem wymagał jednak szerszego workflow niż smart action

To ćwiczenie dobrze pokazuje, że wartość nie bierze się z samego AI, tylko z trafnego doboru powierzchni.

Kluczowe wnioski

• Explain, Fix, Review i terminal quick fix odpowiadają na różne pytania, mimo podobnego wejścia w UI.
• Fix działa najlepiej przy lokalnych problemach, gdzie produkt może od razu dołączyć właściwy fragment kodu albo błąd.
• Review jest warstwą oceny jakości, a nie zamiennikiem wyjaśnienia albo naprawy.
• Terminal quick fix oszczędza czas, bo zamienia nieudane polecenie w gotowy kontekst diagnostyczny.
• Smart actions są najmocniejsze wtedy, gdy problem jest lokalny i dobrze osadzony w miejscu, w którym pracujesz.

Co dalej

Skoro smart actions potrafią już wyjaśniać i naprawiać, czas wejść w kolejny naturalny use case: bootstrap testów i dokumentacji bez ręcznego promptowania.