# Jak używać AI do programowania bez błędów w kodzie URL: https://codebasechat.com/pl/journal/jak-uzywac-ai-do-programowania Type: blog Locale: pl Published: 2026-11-10 Updated: 2026-11-11 --- > Praktyczny workflow użycia AI w programowaniu: co zapisać przed promptem, które narzędzie pasuje do jakiego zadania i jak przeglądać wygenerowany kod. Otwierasz zgłoszenie, wklejasz opis do okna czatu i dostajesz 200 linii wiarygodnie wyglądającego kodu. Kompiluje się. Dwa dni później recenzent pyta, dlaczego kod ignoruje twój wrapper na ponawianie, i nikt w zespole nie potrafi tego wyjaśnić. Tak zwykle kończy się nauka tego, jak używać AI do programowania: etap generowania wypada dobrze, a wszystko wokół niego już nie. Poniżej opisuję workflow, który daję nowym inżynierom. Traktuje model jak szybkiego, pewnego siebie juniora, który nigdy nie widział twojego repozytorium. Jest zbudowany wokół czasu przeglądu, a nie czasu pisania. ## Czy AI naprawdę przyspiesza programowanie? Czasem tak, a uczciwa odpowiedź zależy od zadania. [Ankieta Stack Overflow Developer Survey 2025](https://survey.stackoverflow.co/2025/ai) pokazała, że 84% ankietowanych korzysta z narzędzi AI albo planuje z nich korzystać, a tylko 33% ufa ich wynikom przynajmniej w pewnym stopniu. Najczęstsza skarga, wskazywana przez 66%, dotyczy kodu, który jest „prawie dobry, ale nie do końca”. Kolejne 45.2% mówi, że debugowanie kodu wygenerowanego przez AI zajmuje więcej czasu, niż się spodziewali. Dane z kontrolowanego eksperymentu są mniej pochlebne. W badaniu [METR z 2025 roku](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) 16 doświadczonych programistów open source przeszło przez 246 realnych zgłoszeń w repozytoriach, które dobrze znali. Z dozwolonym AI kończyli około 19% wolniej, choć wierzyli, że są około 20% szybsi. METR opublikował od tego czasu nowsze dane, więc traktuj tę liczbę jako obraz narzędzi z wczesnego 2025 roku, a nie werdykt. Wniosek nie brzmi „AI jest wolne”. Brzmi tak: odczucie szybkości to zły miernik. Czas mierzy się w minutach od zgłoszenia do scalonego PR, a nie w tym, jak szybko pojawił się pierwszy szkic. ![Otwarty notatnik z ręcznie narysowanym planem funkcji obok klawiatury i karteczek](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/216434-inline1.webp) ## Co zapisać, zanim napiszesz pierwszy prompt? Plan, własnymi słowami, w mniej niż dziesięciu linijkach. Bez niego model wypełnia luki własnymi domysłami, które z definicji są generyczne. Szablon jest krótki: - Zmiana zachowania w jednym zdaniu. - Pliki, których prawdopodobnie dotkniesz, nawet jeśli nie masz pewności. - Istniejąca funkcja albo wzorzec, którego nowy kod musi użyć ponownie. - Jedna rzecz, której nie wolno zrobić, na przykład dodać zależność albo zmienić schemat. - Jak sprawdzisz, że działa: test, curl albo zrzut ekranu. Punkt 3 jest tym, który ludzie pomijają, a właśnie stąd pochodzi większość kodu „prawie dobrego”. Model nie wie, że twój helper `withRetry` istnieje, dopóki go nie nazwiesz albo nie może go przeczytać. Unikaj promptu „zbuduj mi całą aplikację”. Początkujący i seniorzy dostają z niego ten sam rezultat: duży diff, którego nikt nie rozumie, i niedokończony projekt. ## Jak wygląda dobry prompt w praktyce? Weźmy realne zadanie: sender webhooków gubi zdarzenia, gdy odbiorca przekroczy limit czasu. Słaby prompt brzmi „popraw niezawodność webhooków”. Użyteczny czyta się jak zgłoszenie: `Dodaj ponawianie z wykładniczym backoffem do sendWebhook() w src/webhooks/sender.ts. Użyj ponownie withRetry() z lib/http.ts. Maksymalnie 4 próby, z jitterem. Nie zmieniaj publicznej sygnatury i nie dodawaj zależności. Dodaj przypadek vitest: odbiorca zawodzi dwa razy, a za trzecim razem odpowiada.`Ten prompt nazywa plik, helper do ponownego użycia, limit i sposób sprawdzenia. Efektem jest diff na jakieś 30 linii, który da się przeczytać za jednym posiedzeniem. Jeśli wróci na 150 linii, model zabłądził i wynik odrzucasz zamiast go poprawiać. Dwa małe triki bardzo pomagają. Po pierwsze, poproś najpierw o plan i przeczytaj go, zanim cokolwiek zmieni się w plikach. Zły plan kosztuje trzydzieści sekund, zły diff kosztuje dziesięć minut. Po drugie, gdy odpowiedź jest chybiona, powtórz złamane ograniczenie zamiast się spierać. Zdanie „dodałeś nową zależność, a reguła mówi: zero” działa lepiej niż akapit tłumaczeń. ## Które narzędzie AI pasuje do jakiego zadania? Istnieją trzy kształty narzędzi, a ich mylenie to drugi najczęstszy błąd. **Uzupełnianie w linii** przewiduje kolejne linie, gdy piszesz. Dobrze sprawdza się przy boilerplate i testach, gdzie wzorzec jest już na ekranie. **Czat w edytorze** odpowiada na pytania o zaznaczony kod i proponuje zmiany, które akceptujesz fragment po fragmencie. **Agenci** biorą zadanie, czytają pliki, uruchamiają polecenia i wracają z gałęzią. Wybieraj według tego, ile możesz tanio zweryfikować. Uzupełnienie, które przeczytasz w dwie sekundy, ma niskie ryzyko. Przebieg agenta dotykający 14 plików to wysoka wartość i wysoki koszt przeglądu. Cursor to opcja dla osób, które stawiają na edytor: fork VS Code z mocnym uzupełnianiem Tab i równoległymi sesjami agentów. Warto, jeśli cały dzień spędzasz w edytorze. Pomiń go, jeśli zespół korzysta z JetBrains i nie zamierza się przełączyć. GitHub Copilot to wybór z niskim progiem wejścia dla zespołów, które już pracują na GitHubie, bo PR-y, zgłoszenia i przegląd są w jednym miejscu. Uważaj na rozliczenia: od czerwca 2026 roku przeszedł na kredyty AI zależne od zużycia, więc intensywne korzystanie z agentów kosztuje więcej, niż sugeruje cena miejsca. Claude Code działa w terminalu i jest agentowy: delegujesz refaktoryzację albo szukanie błędu, a potem przeglądasz wynik. Nie ma uzupełniania w linii i działa wyłącznie na modelach Claude. To uczciwa wymiana, jeśli zależy ci na delegowaniu całych zadań. Aider to opcja skryptowalna i oparta na git. Automatycznie commituje każdą zmianę z własną wiadomością, więc wycofanie jest prostym `git revert`. Płacisz tylko za tokeny modelu, co pasuje do osób, które chcą kontrolować koszty. ## Jak sprawić, żeby AI nie ignorowało twojego repozytorium? Dawaj kontekst celowo. Większość złych wyników wynika z tego, że model nigdy nie widział właściwego pliku. Pomagają trzy nawyki. Po pierwsze, dołącz dwa-trzy pliki, które definiują wzorzec, a nie cały katalog. Po drugie, wklej dosłownie niepowodzący test albo błąd zamiast jego opisu. Po trzecie, trzymaj w repozytorium krótki plik z regułami: nazewnictwo, obsługa błędów, zakazane biblioteki. Narzędzie czyta go przy każdym uruchomieniu, a większość narzędzi agentowych to wspiera. `# AI-RULES.md - Błędy: zwracaj Result, nigdy nie rzucaj wyjątku w services/ - Wywołania HTTP idą przez lib/http.ts (ma retry i tracing) - Bez nowych zależności bez notatki w opisie PR - Testy: vitest, obok plików jako *.test.ts`Cztery takie linijki usuwają zaskakująco dużą część uwag z przeglądu. Pomagają też ludziom. W repozytorium, którego jeszcze nie znasz, zadawaj pytania przed prośbą o zmiany. „Gdzie wymuszane jest wygaśnięcie sesji i co je wywołuje?” to lepszy pierwszy prompt niż „dodaj odświeżanie tokenu”. Czytasz odpowiedź, otwierasz dwa pliki, które wskazuje, i dopiero potem decydujesz, co zmienić. To ta sama pętla grep, blame i pytania kogoś, którą już znasz, tylko szybsza. ![Ekran laptopa z diffem kodu, zielone i czerwone podświetlone linie](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/567383-inline2.webp) ## Jak przeglądać kod wygenerowany przez AI? Wolniej niż kod kolegi. Kolega ma historię pracy z twoją bazą kodu. Model jej nie ma. Moja lista, w tej kolejności: - **Uruchom to, zanim to przeczytasz.** Przechodzący test, który sam napisałeś, jest wart więcej niż pewne wyjaśnienie. - **Przeczytaj importy.** Wymyślone pakiety i obce helpery pokazują się tam w pierwszej kolejności. - **Szukaj tego, czego brakuje.** Ścieżki błędów, obsługa null, sprzątanie zasobów. Modele dobrze piszą ścieżkę szczęśliwą. - **Sprawdź rozmiar diffu.** Jeśli prosiłeś o poprawkę na 10 linii, a dostałeś 120, coś zostało przepisane bez twojej prośby. - **Usuń to, czego nie umiesz wyjaśnić.** Jeśli nie obronisz linii na przeglądzie, nie wchodzi do głównej gałęzi. Commit trzymaj mały, a wiadomość uczciwą. „Dodaj ponawianie do sendera webhooków (z pomocą AI, dodano testy)” jest w porządku. Ukrywanie tego nikomu nie pomaga i utrudnia późniejsze debugowanie. ## Czego nigdy nie oddawać AI i jak to wpływa na zespół? Wszędzie tam, gdzie błąd jest cichy i kosztowny. Logika uwierzytelniania, przepływy płatności, migracje danych i sprawdzanie uprawnień to miejsca, w których „prawie dobrze” przechodzi testy, a zawodzi na produkcji. Nadal można tam korzystać z AI, ale w innym trybie: poproś model o przegląd kodu i listę ryzyk zamiast o napisanie kodu. Przeczytanie listy pięciu możliwych problemów kosztuje trzy minuty. Przeczytanie wygenerowanej migracji kosztuje popołudnie spędzone na wątpieniu w nią. Jeśli dopiero się uczysz, obowiązuje drugie wykluczenie. Najpierw napisz pierwszą wersję sam, a dopiero potem poproś model o krytykę. Junior, który zawsze akceptuje wygenerowaną wersję, uczy się pisać prompty zamiast programować, a ta luka wychodzi przy pierwszej awarii. Różnica między pojedynczymi programistami a zespołami to obciążenie przeglądem. Jedna osoba korzystająca z agentów może otworzyć więcej PR-ów dziennie, niż zespół jest w stanie przeczytać. Ustalcie na początku trzy rzeczy: - **Limit rozmiaru.** PR-y powyżej kilkuset zmienionych linii są dzielone, bez względu na to, kto lub co je napisało. - **Zasadę ujawniania.** Oznaczajcie zmiany wspomagane AI, żeby recenzenci odpowiednio ustawiali uwagę. - **Wspólny plik z regułami.** Jedno źródło prawdy o konwencjach wygrywa z pięcioma osobistymi promptami. Przy wdrażaniu nowych osób najlepiej sprawdza się czytanie prowadzone pytaniami. Nowi pytają asystenta, gdzie co leży, a potem weryfikują odpowiedź w kodzie. Skraca to pierwszy tydzień pytań w stylu „kto to właściwie utrzymuje?” i nie daje im kodu, którego nie potrafią utrzymać. ![Dwóch inżynierów przegląda razem wydrukowane strony przy stole konferencyjnym](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-11/e7c330-inline3.webp) ## Plan na pierwszy tydzień, który można skopiować Dzień 1: używaj wyłącznie uzupełniania w linii, do testów i boilerplate. Dzień 2: zadawaj dziennie trzy pytania o bazę kodu w czacie i weryfikuj każdą odpowiedź. Dzień 3: pozwól czatowi zaproponować jedną małą zmianę na zadanie i czytaj każdy fragment. Dzień 4: wypróbuj agenta na zadaniu niskiego ryzyka, na przykład na zmianie nazwy klucza konfiguracji w wielu plikach, na osobnej gałęzi. Dzień 5: napisz plik z regułami na podstawie tego, co przeszkadzało ci w przeglądzie. Śledź przez cały tydzień jedną liczbę: minuty od rozpoczęcia zgłoszenia do scalonego PR, łącznie z poprawkami z przeglądu. Jeśli nie spadła, wiesz już, gdzie narzędzie nie pasuje do twojej pracy, a to też jest wynik. Najszybszy uczciwy zysk, jaki widziałem, nie polega na generowaniu. Polega na zrozumieniu: poznanie obcego modułu w dziesięć minut zamiast w godzinę. Pisanie kodu nigdy nie było najwolniejszą częścią pracy. Wolniejsze były czytanie, podejmowanie decyzji i weryfikacja. Kieruj narzędzie właśnie tam, a przycisk scalania zostaw własnemu osądowi. ## FAQ ### Czy początkujący może używać AI do programowania? Tak, ale pierwszą wersję napisz samodzielnie, a model poproś o krytykę. Osoby, które tylko akceptują wygenerowany kod, uczą się pisać prompty zamiast programować, a ta luka ujawnia się przy awarii. ### Jaki jest najlepszy sposób pisania promptu do kodowania? Opisz zmianę zachowania w jednym zdaniu, wypisz pliki, których dotkniesz, nazwij istniejącą funkcję do ponownego użycia i określ, jak to sprawdzisz. Niepowodzące testy i błędy wklejaj dosłownie. ### Czy kod wygenerowany przez AI można bezpiecznie scalić? Nie bez przeglądu. Uruchom go, przeczytaj importy pod kątem wymyślonych pakietów, sprawdź ścieżki błędów i porównaj rozmiar diffu z tym, o co prosiłeś. ### Którego narzędzia AI do kodowania użyć? Uzupełniania w linii do boilerplate, czatu w edytorze do pytań i małych zmian, a agentów do zadań delegowanych, które można przejrzeć na gałęzi. Cursor, GitHub Copilot, Claude Code i Aider pasują do różnych stylów pracy. ### Czy AI naprawdę sprawia, że programiści pracują szybciej? Zależy od zadania. Badanie METR z 2025 roku wśród doświadczonych programistów open source zmierzyło pracę około 19% wolniejszą z AI, a ankiety pokazują, że wiele osób zgłasza oszczędność czasu w konkretnych zadaniach. Zmierz własny czas cyklu. ### Do czego nie warto używać AI przy kodzie? Nie generuj logiki uwierzytelniania, przepływów płatności, migracji danych i sprawdzania uprawnień. Tam korzystaj z AI tylko do przeglądu kodu i listy ryzyk.