Pierwsze zadania w Claude Code — jak zacząć bezpiecznie [Day 1–7]
Jak nie przestrzelić przy pierwszym kontakcie z Claude Code? Praktyczny plan na pierwszy tydzień — od zadań tylko do odczytu po pierwsze edycje kodu pod nadzorem.
Nowi użytkownicy Claude Code wpadają w jeden z dwóch skrajnych błędów. Pierwsi są zbyt ostrożni — używają go jak lepszego ChatGPT do pytań ogólnych i nigdy nie dotykają prawdziwego kodu. Drudzy idą od razu na całość: „zbuduj mi aplikację”, pełny dostęp do plików od pierwszego dnia, i po kwadransie patrzą bezradnie na repo, które trudno rozpoznać.
Jest lepszy sposób. Oto jak społeczność Claude Code — po tysiącach godzin wspólnych doświadczeń na Reddicie i Discordzie — podchodzi do pierwszego tygodnia.
Dlaczego warto zacząć od zadań read-only
Claude Code to narzędzie, które może edytować pliki, uruchamiać polecenia i wprowadzać zmiany w Twoim projekcie. To jego siła — ale też powód, dla którego warto najpierw nauczyć się, jak myśli i jak reaguje na Twoje polecenia, zanim dasz mu wolną rękę.
Zadania tylko do odczytu pozwalają zobaczyć jakość odpowiedzi bez ryzyka. Jeśli Claude coś źle zrozumie lub zaproponuje nonsens — nie ma problemu, nic się nie zmieniło. Budujesz też intuicję co do tego, kiedy warto mu ufać, a kiedy lepiej sprawdzić dwa razy.
Dni 1–3: tylko czytaj, analizuj, testuj
Zacznij od zadań, gdzie Claude nie dotyka żadnego pliku:
„Wyjaśnij mi ten plik”
Otwórz terminal w projekcie i zapytaj: Wyjaśnij, co robi @src/auth/middleware.ts. Zobaczysz, jak Claude rozumie kod. Czy trafia w sedno? Czy zauważa niuanse? To dobry test kalibracyjny.
„Napisz testy do tej funkcji”
Poproś o testy jednostkowe do konkretnej funkcji — bez zapisywania, tylko do podglądu. Napisz testy dla funkcji validateToken z @src/auth/utils.ts. Przejrzyj propozycję, zanim ją zaakceptujesz. Naucz się oceniać jakość jego sugestii.
„Zrób review tego kodu”
Przejrzyj @src/api/users.ts pod kątem potencjalnych błędów i kwestii bezpieczeństwa. Claude jest dobry w znajdowaniu rzeczy, które łatwo przeoczyć w swoim własnym kodzie.
„Wyjaśnij mi ten błąd” Wklej stack trace lub komunikat błędu i zapytaj, co może go powodować. Bez żadnych zmian — tylko diagnoza.
Dni 4–7: pierwsze edycje pod nadzorem
Kiedy masz już poczucie, jak Claude interpretuje Twoje polecenia, możesz zacząć pozwalać na edycje. Kluczowe zasady tego etapu:
Jedno zadanie na raz. Nie „popraw cały moduł auth” — tylko „popraw obsługę błędu w funkcji login w @src/auth/controller.ts”. Im węższy zakres, tym łatwiej zweryfikować wynik.
Używaj git przed każdą edycją. Commity i branche to Twoja siatka bezpieczeństwa. Jeśli coś pójdzie nie tak, masz punkt powrotu. Claude Code potrafi obsługiwać gita — możesz poprosić utwórz gałąź feature/fix-login przed każdym zadaniem.
Czytaj diff, zanim zatwierdzisz. Claude pyta o potwierdzenie przed zapisem pliku. To nie jest formalność — naprawdę czytaj, co zmienia.
Jak myśleć o Claude Code
Najlepszy mental model, jaki wypracowała społeczność: Claude Code to solidny junior–mid developer. Zna język, rozumie wzorce, pisze sensowny kod — ale nie zna kontekstu Twojego projektu, Twoich decyzji architektonicznych ani tego, dlaczego coś zostało zrobione tak, a nie inaczej.
Dajesz mu zadania tak samo jak Jr devowi: konkretnie, z kontekstem, z jasnym kryterium sukcesu. „Zrób mi appkę” to zła instrukcja dla juniora i zła instrukcja dla Claude’a. „Dodaj endpoint POST /users, który waliduje email i zapisuje do bazy — schemat w @src/db/schema.ts” — to jest właśnie to.
Trzy zdania, które warto wbić w nawyk
Iteruj zamiast czekać na perfekcję. Jeśli pierwsza odpowiedź jest w 70% dobra, powiedz co poprawić — nie zaczynaj od nowa. Claude dobrze reaguje na feedback w tej samej rozmowie.
Pytaj o alternatywy. „Jakie masz inne podejścia do tego problemu?” często wyciąga lepsze rozwiązanie niż to, które zaproponował bez pytania.
Mów mu, gdy się myli. Claude nie obraża się. „To nie zadziała, bo mamy tu zależność cykliczną — spróbuj inaczej” to dokładnie taki feedback, na którym mu zależy.