Debug with AI: diagnozowanie i naprawa błędów z Copilotem

Czego się nauczysz

• Jak prowadzić diagnozę problemu z pomocą AI, zamiast oddawać AI całą odpowiedzialność za naprawę
• Jak używać #problems, logów, outputu testów i slash commands do zawężania przyczyn
• Jak debugować sam workflow AI przez Agent Debug Logs i Chat Debug View

Są tu tak naprawdę dwa rodzaje debugowania

I dopiero ich połączenie daje porządną praktykę.

Pierwszy rodzaj to debugowanie aplikacji albo kodu z pomocą AI.

Drugi rodzaj to debugowanie samej sesji AI: czy model dostał dobry kontekst, czy widział pliki, czy narzędzie w ogóle zostało wywołane, czy prompt file został załadowany.

Jeśli pomijasz ten drugi poziom, łatwo uznać, że “Copilot jest słaby”, podczas gdy problemem jest zły kontekst albo brakujący tool.

Zacznij od zebrania twardych sygnałów

Najgorszy prompt debugowy brzmi: “napraw to”.

Dużo lepiej działa dołączenie konkretnych źródeł objawu:

• #problems
• output z terminala
• failing test
• stack trace
• wskazany plik albo symbol

Wtedy AI nie startuje od zgadywania. Startuje od materiału dowodowego.

Copilot jest dobry w generowaniu hipotez, nie w czytaniu w myślach

To ważne nastawienie.

Najlepiej używać AI do:

• wygenerowania kilku możliwych przyczyn
• powiązania objawu z miejscami w kodzie
• zaproponowania planu weryfikacji
• przygotowania małej poprawki i testu potwierdzającego

Najgorzej używać go do bezrefleksyjnego wklejenia pierwszej sugestii fixu.

Smart actions i slash commands skracają drogę

Cheat sheet i docs testowe pokazują kilka praktycznych wejść:

• /fix
• /fixTestFailure
• Fix Test Failure w Test Explorer
• code actions i editor smart actions

Te narzędzia są dobre, bo od razu niosą właściwy typ intencji. Nie zaczynasz od ręcznego opisywania problemu od zera.

Agent też trzeba umieć diagnozować

Gdy odpowiedź AI jest nietrafna albo agent nie używa narzędzia, nie zgaduj w ciemno. Otwórz narzędzia diagnostyczne.

Najważniejsze są dwa:

• Agent Debug Log panel
• Chat Debug View

Pierwszy pokazuje chronologiczny przebieg zdarzeń. Drugi pokazuje surowy request i response do modelu.

To razem daje bardzo mocny wgląd w to, co naprawdę zaszło.

Agent Debug Logs odpowiada na pytanie: co się stało

W logach zobaczysz:

• discovery eventy
• tool calle
• token usage
• przebieg subagentów
• błędy w sesji

To idealne miejsce, jeśli chcesz sprawdzić, czy agent w ogóle próbował użyć oczekiwanego narzędzia albo czy wykrył Twoje customizacje.

Chat Debug View odpowiada na pytanie: co model faktycznie dostał

Tu widzisz:

• system prompt
• user prompt
• context
• raw response
• tool responses

To jest bezcenne, gdy masz wrażenie, że AI ignoruje plik, prompt file albo część wymagań. Zamiast spekulować, możesz sprawdzić, czy ten materiał w ogóle dotarł do modelu.

/troubleshoot to świetny skrót dla sesji lokalnych

Jeśli masz włączony debug log, możesz zadawać AI pytania o samą sesję, np.:

• jakie customizacje się załadowały
• ile było tool calli
• gdzie pojawił się błąd

To bardzo praktyczne, bo skraca drogę między logami a interpretacją.

Najczęstsze scenariusze diagnostyczne są powtarzalne

Docs debugowe pokazują kilka bardzo praktycznych przypadków:

• AI ignoruje workspace files
• oczekiwany MCP tool nie jest wywoływany
• odpowiedź jest ucięta
• prompt file albo instructions się nie stosują

To ważne, bo dużo problemów nie jest “złym modelem”, tylko problemem operacyjnym w warstwie kontekstu, indeksowania albo customizacji.

Nie zapominaj o klasycznych logach Copilota

Poza debug view dla sesji masz też zwykłe logi rozszerzeń GitHub Copilot i GitHub Copilot Chat oraz diagnostykę sieciową przez GitHub Copilot: Collect Diagnostics.

Jeśli problem dotyczy autoryzacji, proxy, VPN albo niestabilnego połączenia, to właśnie tam szukasz odpowiedzi, a nie w promptach debugowych.

Ćwiczenie praktyczne

Weź jeden realny błąd z projektu i rozpisz dla niego workflow diagnostyczny:

1. Jakie twarde sygnały dołączasz do promptu.
2. Jakie hipotezy prosisz AI, żeby wygenerowało.
3. Jak zweryfikujesz pierwszą poprawkę.
4. Jak sprawdzisz, czy agent miał właściwy kontekst i narzędzia.

Jeśli chcesz, dopisz też warunek stop: po ilu nietrafionych iteracjach kończysz sesję i zaczynasz nową, z czystszym kontekstem.

Kluczowe wnioski

• Dobre debugowanie z AI zaczyna się od twardego materiału dowodowego, nie od ogólnego polecenia “napraw”.
• Trzeba odróżniać debugowanie kodu od debugowania samej sesji AI.
• Agent Debug Logs i Chat Debug View są podstawowymi narzędziami diagnozy workflow AI.
• Wiele problemów wynika z kontekstu, toolingu albo konfiguracji, a nie z samego modelu.

Co dalej

Została ostatnia technika z tego modułu: browser tools. To moment, w którym agent przestaje tylko czytać i pisać kod, a zaczyna samodzielnie wchodzić w UI, testować interfejs i zamykać pętlę build-test-fix bez zewnętrznego MCP.