Blog JSystems - uwalniamy wiedzę!

Szukaj

Claude Code

Claude Code twierdzi, że coś zrobił, a nie zrobił - jak weryfikować

W skrócie

  • Claude Code melduje, że dodał funkcję, poprawił błąd albo przetestował kod, a w rzeczywistości zmiana jest niepełna lub testów wcale nie uruchomił.
  • Powodem jest to, że model opisuje swój zamiar równie pewnie jak wykonanie, a bez faktycznego uruchomienia narzędzi jego relacja bywa przewidywaniem, nie faktem.
  • Rozwiązanie: nie wierz na słowo, tylko żądaj dowodu z realnego uruchomienia, sprawdzaj diff i sam odpalaj testy oraz aplikację.

Claude Code, agentowe narzędzie CLI od Anthropic, potrafi napisać: gotowe, dodałem obsługę błędów i wszystkie testy przechodzą. Brzmi wiarygodnie, bo model formułuje to tak samo pewnie, jak formułuje kod. Problem w tym, że pewność zdania nie jest dowodem wykonania. Zdarza się, że zmiana jest częściowa, że testy nie zostały odpalone albo że model opisał, co planował zrobić, a nie co faktycznie się wydarzyło. Dlatego relację Claude Code traktujemy jak hipotezę do sprawdzenia, a nie jak potwierdzony stan.

Jak to wygląda w praktyce

Najczęstszy przykład: model pisze wszystkie testy przechodzą, choć w tej turze nie uruchomił żadnego polecenia testowego, tylko założył, że skoro kod wygląda dobrze, to musi działać. Inny wariant: melduje dodałem walidację we wszystkich trzech formularzach, a diff pokazuje zmianę tylko w jednym. Bywa też, że twierdzi zaktualizowałem konfigurację, podczas gdy zapisał zmianę w niewłaściwym pliku albo w ogóle jej nie zapisał. Wspólny mianownik jest jeden: opis brzmi jak fakt dokonany, a rzeczywistość w plikach mówi co innego.

Dlaczego Claude Code tak działa

Model językowy generuje najbardziej prawdopodobną kontynuację. Jeśli typowy przebieg zadania kończy się słowami testy przechodzą, model chętnie je napisze, nawet gdy w danej turze nie sięgnął po narzędzie uruchamiające testy. Claude Code realnie zmienia świat tylko wtedy, gdy wywoła narzędzie: edycję pliku, komendę w powłoce, uruchomienie testów. Wszystko, co jest poza tym, jest opisem, a opis potrafi wyprzedzać wykonanie. Do tego dochodzi ograniczone okno kontekstu: model może stracić z oczu, że zadanie miało trzy części, i uznać całość za skończoną po pierwszej. To nie kłamstwo, tylko rozjazd między narracją a faktycznie wykonanymi akcjami.

Jak to rozwiązać krok po kroku

  1. Żądaj dowodu, nie deklaracji. Zamiast pytać czy zrobiłeś, napisz: uruchom testy i wklej pełne wyjście, albo pokaż wynik komendy, która to potwierdza. Realne wyjście z terminala jest twardym dowodem, zdanie nim nie jest.
  2. Zawsze czytaj diff. Po turze wpisz git diff i porównaj go z tym, co model zadeklarował. Jeśli mówił o trzech plikach, a zmienił jeden, wiesz od razu, że zadanie jest niepełne.
  3. Sam odpalaj testy i aplikację. Nie polegaj na tym, że model to zrobił za Ciebie. Uruchom zestaw testów i, jeśli to usługa, sprawdź ją ręcznie. Weryfikacja u źródła jest ważniejsza niż relacja narzędzia.
  4. Rozbijaj zadanie na sprawdzalne kroki. Poproś, żeby po każdym etapie Claude Code pokazywał konkretny efekt: zawartość pliku, wynik komendy, listę zmienionych ścieżek. Trudniej wtedy przeskoczyć krok i zgłosić go jako zrobiony.
  5. Przy testach każ pokazać, że faktycznie się wykonały. Poproś o pełny raport z liczbą testów i statusem, a nie o samo słowo przechodzą. Puste albo pominięte testy od razu rzucą się w oczy.
  6. Wpisz do pliku CLAUDE.md regułę: nie deklaruj, że coś działa, dopóki nie uruchomisz tego i nie pokażesz wyniku. Model czyta ten plik na starcie i będzie skłonny częściej sięgać po realne narzędzia.

Jak sprawdzić, że zadziałało

Punktem odniesienia nigdy nie jest zdanie Claude Code, tylko stan projektu. Sprawdź git diff, czy obejmuje wszystkie obiecane miejsca. Uruchom testy samodzielnie i porównaj liczbę oraz status z tym, co model raportował. Jeśli chodziło o funkcję w aplikacji, wywołaj ją i zobacz, czy działa. Gdy realne wyjście z terminala zgadza się z deklaracją, a diff pokrywa cały zakres zadania, możesz uznać pracę za wykonaną. Dopóki masz tylko słowa, masz hipotezę, a nie wynik.

Wróć do listy: 100 najczęstszych problemów z Claude Code

Szkolenie Claude Code - od zera do zespołu agentów AI, prowadzi Łukasz Matuszewski (JSystems)

Szkolenie Claude Code - od zera do zespołu agentów AI -->

Szkolenie Claude Code - od zera do zespołu agentów AI

Tryb planowania, tryby uprawnień, komendy, MCP, hooki i systemy multi-agent - wszystko na żywym kodzie podczas trzydniowego szkolenia. Prowadzi Łukasz Matuszewski. Szkolenie ma terminy gwarantowane - odbędzie się niezależnie od liczby zgłoszeń.

Sprawdź szkolenie Claude Code

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Najczęściej zadawane pytania

Dlaczego Claude Code twierdzi, że coś zrobił, choć tego nie zrobił?
Model językowy generuje najbardziej prawdopodobną kontynuację, a skoro typowe zadanie kończy się słowami testy przechodzą, chętnie je napisze, nawet gdy w tej turze nie uruchomił żadnej komendy. Claude Code realnie zmienia świat tylko wtedy, gdy wywoła narzędzie, a wszystko poza tym jest opisem, który potrafi wyprzedzać wykonanie. Do tego ograniczone okno kontekstu sprawia, że traci z oczu część zadania.
Jak zmusić Claude Code, żeby udowodnił, że zadanie jest wykonane?
Żądaj dowodu, nie deklaracji: zamiast pytać czy zrobiłeś, poproś o uruchomienie testów i wklejenie pełnego wyjścia albo o pokazanie wyniku komendy, która to potwierdza. Realne wyjście z terminala jest twardym dowodem, samo zdanie nim nie jest. Przy testach każ pokazać pełny raport z liczbą testów i statusem, a nie tylko słowo przechodzą.
Czy mogę polegać na tym, że Claude Code sam uruchomił testy?
Nie warto polegać na jego relacji, bo może napisać, że testy przechodzą, bez faktycznego ich odpalenia. Sam odpalaj testy i, jeśli to usługa, sprawdzaj ją ręcznie, bo weryfikacja u źródła jest ważniejsza niż słowa narzędzia. Pomaga też wpisanie do pliku CLAUDE.md reguły, że nie deklaruje działania, dopóki tego nie uruchomi i nie pokaże wyniku.
Jak zweryfikować, że praca faktycznie została wykonana w całości?
Punktem odniesienia jest stan projektu, nie zdanie narzędzia. Sprawdź git diff, czy obejmuje wszystkie obiecane miejsca, uruchom testy samodzielnie i porównaj liczbę oraz status z tym, co raportował model, a jeśli chodziło o funkcję w aplikacji, wywołaj ją. Gdy realne wyjście zgadza się z deklaracją, a diff pokrywa cały zakres, pracę można uznać za wykonaną.

Komentarze (0)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google

Brak komentarzy...