Blog JSystems - uwalniamy wiedzę!

Szukaj

Claude Code

Jak zweryfikować, że kod od Claude Code naprawdę działa

W skrócie

  • Claude Code mówi "gotowe", ale nie masz pewności, czy kod naprawdę działa, czy tylko wygląda poprawnie w diffie.
  • Analiza samego kodu nie wystarcza - "wygląda dobrze" to nie to samo co "uruchamia się i daje właściwy wynik".
  • Rozwiązaniem jest weryfikacja działania, a nie kodu: uruchomienie testów i buildu, porównanie ze zrzutem, a przy większych zmianach niezależny przegląd świeżym podagentem.

Claude Code, oficjalne narzędzie CLI od Anthropic do programowania z AI, potrafi napisać kod szybciej, niż zdążysz go przeczytać. Pokusa, żeby zaufać zgrabnie wyglądającemu diffowi, jest duża - i właśnie tu wpada się w kłopoty. Kod, który wygląda dobrze, wcale nie musi działać. Poniżej pokazujemy, jak zweryfikować rezultat na żywo, żeby nie ogłaszać sukcesu na podstawie samej analizy tekstu.

Jak to wygląda w praktyce

Dostajesz od Claude Code implementację, czytasz ją, wygląda sensownie, więc uznajesz temat za zamknięty. Potem okazuje się, że funkcja nie obsługuje przypadku brzegowego, endpoint zwraca zły format albo interfejs po zmianie wygląda inaczej, niż miał. Objaw wspólny: decyzja o "działa" zapadła na podstawie czytania kodu, a nie jego uruchomienia. To najczęstsza droga do sytuacji, w której poprawka trafia dalej, choć nie robi tego, co powinna.

Dlaczego Claude Code tak działa

Claude Code zatrzymuje się, gdy praca wygląda na skończoną - i jeśli nie ma sprawdzianu, który sam uruchomi, "wygląda na skończoną" jest jedynym sygnałem, jakim dysponuje. To nie jest złośliwość narzędzia, tylko naturalna granica pracy z tekstem. Dlatego dokumentacja Anthropic stawia sprawę jasno: trzeba dać Claude Code coś, co zwraca pass albo fail, i kazać pokazać dowód - wynik testów, uruchomione polecenie i jego rezultat albo zrzut ekranu - zamiast przyjmować zapewnienie o sukcesie. Przegląd dowodu jest szybszy niż samodzielne powtarzanie całej weryfikacji.

Jak to rozwiązać krok po kroku

  1. Uruchom kod, nie tylko go czytaj. Odpal build i testy - w Claude Code możesz to zrobić w trybie powłoki, wpisując na przykład ! npm test albo ! make build. Wynik wpada do rozmowy i Claude Code od razu się do niego odnosi.
  2. Podaj kryteria weryfikacji już w prompcie. Zamiast "zaimplementuj funkcję" napisz, jakie wejścia mają dać jakie wyjścia, i dodaj "uruchom testy po napisaniu". Wtedy Claude Code sam iteruje, aż przejdą.
  3. Zmiany interfejsu sprawdzaj wizualnie. Poproś "zrób zrzut ekranu wyniku i porównaj go z oryginałem, wypisz różnice i je popraw". Porównanie ze wzorcem graficznym łapie to, czego nie widać w kodzie.
  4. Żądaj dowodu zamiast deklaracji. Dopisz "pokaż wynik testów oraz polecenie, które uruchomiłeś" - dostaniesz wklejone wyjście, a nie samo "gotowe".
  5. Przy większej zmianie dołóż niezależny przegląd. Zleć świeżemu podagentowi sprawdzenie diffu: "użyj podagenta, żeby przejrzeć zmianę pod kątem błędów i braków". Podagent widzi tylko diff i kryteria, nie rozumowanie, które doprowadziło do kodu, więc ocenia wynik bezstronnie. Możesz też uruchomić wbudowany skill /code-review.
  6. Sam potwierdź na żywej aplikacji. Po tym, jak sprawdzian Claude Code przejdzie, uruchom u siebie /verify, żeby potwierdzić zmianę względem faktycznie działającej aplikacji, a nie tylko testów.
  7. Na dłuższą albo nienadzorowaną pracę ustaw twardą bramkę: warunek jako cel przez /goal (osobny ewaluator sprawdza go po każdej turze) albo hook Stop, który blokuje zakończenie tury, dopóki Twój skryptowy sprawdzian nie przejdzie.

Jak sprawdzić, że zadziałało

Kryterium jest proste: masz w rozmowie twardy dowód działania, a nie zapewnienie. Zielone testy z widocznym wyjściem, kompilacja bez błędów, zrzut ekranu zgodny z projektem albo raport podagenta bez istotnych braków. Uruchom /diff, żeby przejrzeć dokładny zakres zmian, i skonfrontuj go z tym, co miało powstać. Jeśli używasz celu /goal albo hooka Stop, dowodem jest to, że tura po prostu nie kończy się, dopóki sprawdzian nie przejdzie. Zasada, którą warto zapamiętać: jeśli czegoś nie potrafisz zweryfikować w działaniu, nie traktuj tego jako gotowego.

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

Czy wystarczy przeczytać kod od Claude Code, żeby wiedzieć, że działa?
Nie. Kod, który wygląda dobrze, wcale nie musi się uruchamiać i dawać właściwego wyniku. Decyzja o działa powinna zapadać na podstawie uruchomienia, a nie czytania. Weryfikuj działanie, nie sam kod, bo najczęstsza droga do problemów to ogłoszenie sukcesu z samej analizy diffu.
Jak najprościej uruchomić build albo testy z poziomu Claude Code?
Użyj trybu powłoki: wpisz wykrzyknik i komendę, na przykład polecenie testów albo buildu. Wynik trafia do rozmowy, a Claude Code od razu się do niego odnosi, więc od razu widzisz, czy kompilacja i testy przechodzą, czy coś pada.
Jak zweryfikować zmianę w interfejsie, której nie widać w kodzie?
Poproś o weryfikację wizualną: zrób zrzut ekranu wyniku i porównaj go z oryginałem, wypisz różnice i je popraw. Porównanie ze wzorcem graficznym łapie rozjazdy, których nie da się ocenić z samego diffu. Po sprawdzianie Claude Code możesz sam potwierdzić zmianę na żywej aplikacji przez /verify.
Jak dostać niezależną ocenę większej zmiany?
Zleć przegląd świeżemu podagentowi, na przykład: użyj podagenta, żeby przejrzeć zmianę pod kątem błędów i braków. Podagent widzi tylko diff i kryteria, nie rozumowanie prowadzące do kodu, więc ocenia wynik bezstronnie. Możesz też uruchomić wbudowany skill do przeglądu kodu.

Komentarze (0)

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

Brak komentarzy...