Jak używać AI do programowania bez błędów w kodzie

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 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 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.

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:

1. Zmiana zachowania w jednym zdaniu.

2. Pliki, których prawdopodobnie dotkniesz, nawet jeśli nie masz pewności.

3. Istniejąca funkcja albo wzorzec, którego nowy kod musi użyć ponownie.

4. Jedna rzecz, której nie wolno zrobić, na przykład dodać zależność albo zmienić schemat.

5. 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.

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:

1. Limit rozmiaru. PR-y powyżej kilkuset zmienionych linii są dzielone, bez względu na to, kto lub co je napisało.

2. Zasadę ujawniania. Oznaczajcie zmiany wspomagane AI, żeby recenzenci odpowiednio ustawiali uwagę.

3. 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ć.

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.