Praktyczne zastosowania sztucznej inteligencji w pracy programisty: narzędzia, przykłady i ograniczenia

<

Konfiguracja asystenta w IDE – szybkie wygrane kontra głębokie integracje

Przy pierwszej instalacji asystenta AI większość programistów zatrzymuje się na ustawieniach domyślnych. Różnica między „out of the box” a sensownie skonfigurowanym narzędziem potrafi być jednak większa niż między różnymi dostawcami.

Najczęściej pojawiają się trzy podejścia do konfiguracji:

• Tryb maksymalnie agresywny – podpowiedzi pojawiają się praktycznie po każdym znaku, często całe funkcje lub bloki testów. Daje duże przyspieszenie, ale łatwo „przeklikać” nieprzemyślane sugestie. Sprawdza się przy rutynowym klepaniu boilerplate’u.
• Tryb konserwatywny – krótkie, liniowe podpowiedzi, rzadziej pojawiające się sugestie wielolinijkowe. Dobre w projektach o wysokich wymaganiach jakościowych, gdzie AI jest bardziej pomocnikiem niż współautorem.
• Tryb mieszany – agresywne podpowiedzi w plikach testów, konfiguracjach, prostym kodzie glue, za to zachowawcze ustawienia w krytycznych modułach domenowych.

W praktyce sensownie jest zacząć od trybu konserwatywnego i stopniowo luzować ograniczenia w tych obszarach kodu, gdzie AI przynosi największy zwrot z inwestycji: testy, migracje, adaptery do API, proste CRUD-y.

Praca w trybie „pair programming z AI”

Asystent w IDE może działać jak nieco rozkojarzony, ale bardzo szybki partner do pair programmingu. Kluczowy jest wybór trybu pracy.

• AI jako „driver”, człowiek jako „navigator” – programista pisze komentarze, szkicuje interfejsy i opisuje kroki, a AI generuje implementację. Dobre przy tworzeniu kodu, który nie jest strategiczny (np. mapowania DTO, proste serwisy).
• AI jako „navigator”, człowiek jako „driver” – programista pisze kod, a AI co jakiś czas sugeruje uproszczenia, wyłapuje luki w obsłudze błędów, proponuje testy. Sprawdza się w złożonej logice biznesowej, gdzie człowiek kontroluje strukturę, a AI szuka skrótów i dziur.

Różnica między tymi podejściami jest wyraźna przy onboardingu do nowej bazy kodu. W pierwszym wariancie AI szybciej „wypluwa” działające fragmenty, ale łatwo utracić zrozumienie całości. W drugim tempo jest wolniejsze, za to wiedza o systemie zostaje w głowie programisty, a nie tylko w historii commitów.

Wykorzystanie kontekstu projektu – od pojedynczego pliku do „pamięci organizacyjnej”

Najbardziej zaawansowane integracje z IDE korzystają z tzw. rozszerzonego kontekstu: indeksują całe repozytorium, dokumentację w folderze docs/, a nawet opisy ticketów w systemie zarządzania zadaniami. W rezultacie zamiast ogólnych sugestii powstają podpowiedzi mocno osadzone w realiach danej aplikacji.

Różnice widać, gdy porówna się trzy poziomy „świadomości” narzędzia:

• Kontekst pliku – AI widzi tylko aktualny plik. Dobre do krótkich fragmentów logiki, ale słabe przy refaktoryzacji przekrojowej.
• Kontekst projektu – indeksowanie całego repozytorium, znajomość istniejących klas, helperów, wzorców. Umożliwia podpowiadanie zgodne z konwencjami zespołu.
• Kontekst organizacyjny – dodatkowo dostęp do dokumentacji architektonicznej, standardów, decision logów. Przydatne w większych firmach, gdzie AI może od razu sugerować „nasz sposób” rozwiązania problemu (np. standardową implementację audytu czy logowania).

Im wyższy poziom, tym większe korzyści, ale też więcej pracy przy konfiguracji i większe ryzyko wycieku danych przy rozwiązaniach chmurowych. Mały zespół zwykle spokojnie działa na poziomie projektu, podczas gdy korporacja częściej inwestuje w zasilenie modeli pełnym kontekstem organizacyjnym – czasem nawet własnym, dostrojonym LLM.

Generowanie nowego kodu za pomocą AI – kiedy to ma sens, a kiedy nie

Scenariusze, w których generowanie kodu oszczędza najwięcej czasu

Generowanie „zielonego” kodu z AI jest najbardziej opłacalne tam, gdzie problem jest dobrze opisany, a rozwiązanie ma charakter szablonu. Kilka typowych przypadków:

• CRUD i warstwa dostępu do danych – modele świetnie radzą sobie z powtarzalnymi encjami, repozytoriami, DTO i mapperami. Zwłaszcza w aplikacjach biznesowych, gdzie struktura tabel jest przewidywalna.
• Integracje z zewnętrznymi API – gdy dokumentacja jest publiczna, AI potrafi wygenerować klienta, handle błędów czy wstępne testy kontraktowe.
• Kod „klejący” – adaptery, fasady, konwertery, translatory pomiędzy protokołami – wszystko, co głównie przenosi dane z punktu A do B z niewielką logiką.
• Prototypy i spike’i – szybkie wypróbowanie podejścia, np. stworzenie PoC dla nowej biblioteki UI czy klienta do nowego serwisu.

Przykład z praktyki: zespół musi wystawić kilka podobnych endpointów REST dla nowego modułu. Analityk dostarcza dobrze opisane przypadki użycia, model danych jest już ustalony. Generowanie szkieletu kontrolerów, DTO oraz prostych testów integracyjnych przez AI pozwala zamiast jednego dnia zredukować pracę do kilku godzin dopracowywania szczegółów.

Miejsca, gdzie generowanie kodu robi więcej szkody niż pożytku

Istnieją też obszary, w których model generujący kod łatwo podkopuje jakość projektu, szczególnie gdy działa bez refleksji programisty.

• Krytyczna logika biznesowa – wyliczanie prowizji, reguły podatkowe, limity ryzyka, algorytmy ustalające ceny. Tu wymagane jest nie tylko poprawne działanie, ale i pełne zrozumienie przez zespół. „Magiczny” kod z AI utrudnia późniejszy audyt.
• Bezpieczeństwo i kryptografia – modele potrafią wprowadzać przestarzałe praktyki (np. nieaktualne algorytmy hashujące), używać niebezpiecznych domyślnych konfiguracji lub ignorować side-channel’e.
• Fragmenty o dużym długu technicznym – wrzucenie AI w „bagno” kodu legacy często skutkuje powielaniem złych wzorców, zamiast ich poprawiania. Lepiej najpierw ręcznie oczyścić architekturę, a dopiero potem generować nowe fragmenty.

Dobrym filtrem jest pytanie: „Czy za ten fragment kodu w razie problemów przyjdzie do nas audyt lub regulator?”. Jeśli tak, AI powinno być co najwyżej pomocnikiem przy pisaniu testów, a nie głównym autorem implementacji.

Prompt jako specyfikacja – jak opisywać wymagania, żeby kod był użyteczny

Jakość generowanego kodu zależy bezpośrednio od jakości opisu zadania. Różne zespoły wypracowują swoje „szablony promptów”, ale da się wyodrębnić kilka wspólnych elementów:

• Cel biznesowy – zamiast „napisz kontroler”, lepiej: „zaimplementuj endpoint, który pozwala klientowi zmienić adres korespondencyjny z walidacją X i logowaniem Y”.
• Kontekst techniczny – framework, wersja języka, przyjęte standardy (np. „użyj Spring Boot 3, stylu REST zgodnego z dotychczasowymi endpointami w katalogu order/api”).
• Przykładowe wejście/wyjście – krótki JSON request/response lub przykładowe eventy. To często eliminuje nieporozumienia w nazewnictwie pól.
• Ograniczenia i antywzorce – np. „nie zapisuj danych w sesji”, „nie używaj statycznych singletonów”, „nie twórz logiki w warstwie kontrolera”.

Generowanie kodu bez podania tych informacji zazwyczaj prowadzi do „frameworkowego lorem ipsum” – coś działa, ale ani nie pasuje do reszty systemu, ani nie spełnia niefunkcjonalnych wymagań (wydajność, bezpieczeństwo, skalowalność).

Iteracyjne doskonalenie wygenerowanego kodu

Różnica między jednorazową generacją a iteracyjną współpracą z AI jest podobna jak między napisaniem kodu „na raz” a TDD. Bardziej efektywny model pracy obejmuje kilka kroków:

1. Poproszenie o pierwszy szkic implementacji na podstawie specyfikacji.
2. Ręczny przegląd, identyfikacja nieścisłości i braków.
3. Oddanie kodu z powrotem do AI z komentarzem: co poprawić, co uprościć, gdzie dodać testy.
4. Ostateczne „doszlifowanie” ręcznie i dopisanie edge case’ów, których model nie przewidział.

W takim podejściu AI nie jest jednorazowym generatorem, tylko pełni rolę partnera w krótkich, szybkich iteracjach. Zmniejsza to ryzyko przyjęcia słabej jakości kodu tylko dlatego, że „wyszło z narzędzia”.

AI jako recenzent i refaktoryzator kodu – drugie oczy z innym zestawem uprzedzeń

Automatyczny code review – uzupełnienie, nie zamiennik kolegi z zespołu

Modele AI potrafią generować komentarze do pull requestów, oceniać złożoność funkcji czy wskazywać powtarzające się fragmenty. Zderzają się tutaj dwa podejścia do ich użycia:

• AI przed code review człowieka – narzędzie „czyści” PR z drobnicy (nazwa zmiennej, proste duplikaty, style) zanim kod trafi do żywego recenzenta. Programista poprawia automatyczne uwagi, a człowiek skupia się na architekturze i logice.
• AI równolegle z recenzją człowieka – komentarze od AI pojawiają się obok uwag drugiej osoby. Daje to ciekawy kontrast: narzędzie częściej wyłapuje wzorce i powtarzalne antywzorce, człowiek – subtelne aspekty domeny.

W praktyce widać, że lepiej, by AI działało na wcześniej zmergowanym lub rebased PR niż na chaotycznych commitach z „WIP” w nazwie. Modele radzą sobie znacznie lepiej, gdy widzą finalną wersję zmiany, a nie trzy konkurencyjne podejścia w jednym diffie.

Rodzaje uwag, które AI zgłasza szczególnie skutecznie

Modele językowe mają swoje „obszary komfortu”. Zwykle dobrze wychwytują:

• Nadmierną złożoność funkcji – sugerują ekstrakcję metod, rozbicie na mniejsze klasy, wprowadzenie wzorca (np. Strategy zamiast serii if-else).
• Powtarzalny kod – wskazują fragmenty, które można wydzielić do wspólnych helperów, zwłaszcza przy testach integracyjnych i konfiguracjach.
• Nieoczywiste błędy w obsłudze nulli i wyjątków – np. brak logowania błędu w krytycznym miejscu, „połykane” wyjątki.
• Niespójne nazewnictwo – różnice w nazewnictwie parametrów, DTO i pól w bazie, które utrudniają późniejszą nawigację po kodzie.

Znacznie gorzej radzą sobie z subtelnymi błędami domenowymi, np. myleniem pojęć „klient biznesowy” i „partner”, jeśli w systemie mają one osobne znaczenia. Tu nadal potrzebne jest doświadczenie osoby, która zna kontekst organizacji.

Refaktoryzacja z AI – małe kroki kontra wielkie „przepisywanie”

Tu pojawia się jedna z większych pułapek: modele AI mają tendencję do proponowania dużych, eleganckich refaktoryzacji, które w świecie rzeczywistym są ryzykowne. Porównując dwie strategie:

• Małe, lokalne refaktoryzacje – np. ekstrakcja metody, uspójnienie walidacji, zamiana „magicznych stringów” na stałe. Niskie ryzyko, łatwe do przetestowania, dobrze wspierane przez AI.
• Duże, przekrojowe zmiany architektoniczne – zamiana monolitu na mikroserwisy, zmiana frameworka, przeprojektowanie modelu domenowego. Tutaj AI może sugerować poprawne teoretycznie rozwiązania, ale zderzają się one z ograniczeniami biznesowymi, wydajnościowymi czy historycznymi.

Bezpieczniejszy model pracy to proszenie AI o konkretne, ograniczone zmiany: „pokaż, jak rozbić tę funkcję na trzy mniejsze”, zamiast „przepisz ten moduł na DDD”. W pierwszym przypadku łatwo ocenić skutki, w drugim ryzyko niekontrolowanego rozlania się zmian jest dużo większe.

Styl, standardy i linters – jak pogodzić AI z istniejącym ekosystemem

W wielu projektach lintery i formatery (ESLint, Prettier, ktlint, Pylint itd.) są obowiązkowe. AI, które generuje kod niezgodny z tymi narzędziami, szybko staje się źródłem frustracji. Są dwa podejścia do tego problemu:

Dobrym uzupełnieniem będzie też materiał: Docker dla początkujących: uruchom pierwszą aplikację w kontenerze — warto go przejrzeć w kontekście powyższych wskazówek.

• Dostosowanie promptów – explicite informowanie modelu o używanych narzędziach: „kod musi przejść ESLint z konfiguracją z pliku .eslintrc i być zgodny z Prettierem”. Wiele modeli reaguje na takie instrukcje generowaniem bardziej „czystego” kodu.
• Post-processing – uruchamianie linterów i formatterów automatycznie po wklejeniu kodu od AI. Wymaga to dyscypliny lub integracji z pipeline’em w IDE (np. format on save).

Połączenie ludzkiego i maszynowego code review

Praktycznie użyteczne podejście do recenzji kodu z AI to świadome rozdzielenie ról. Inaczej wygląda przegląd „przed mergem”, a inaczej analiza większych fragmentów istniejącego systemu.

• PR-y małe i częste – AI dobrze radzi sobie z oceną jakości takich zmian: sprawdza spójność stylu, proste błędy, oczywiste antywzorce. Człowiek może tylko „przeklikać” ogólny sens i zależności z resztą systemu.
• PR-y duże i rzadkie – narzędzia generatywne pomagają pogrupować uwagi: streszczają diff, wskazują kluczowe obszary ryzyka. Programista zdecyduje, na których plikach skupić manualną uwagę, zamiast czytać wszystko linijka po linijce.

Różnica jest też w tym, kto aktywnie zadaje pytania. AI można potraktować jako interaktywnego recenzenta: „załóż się ze mną, że ten kod jest zły i wskaż argumenty”. Taka „kontrariańska” postawa narzędzia często wyciąga na wierzch kwestie, które w normalnym code review wszyscy przeskakują z przyzwyczajenia.

Testy, debugowanie i analiza błędów przy wsparciu AI

Dwa modele współpracy przy testach: od generowania do projektowania scenariuszy

AI przy testach może pełnić dwie różne role i te role warto rozdzielać, bo prowadzą do innych efektów.

• Generator testów – na podstawie istniejącej funkcji lub klasy model dopisuje testy jednostkowe, mocki, dane wejściowe. Zwykle robi to szybko, ale powierzchownie.
• Projektant scenariuszy – programista opisuje zachowanie systemu, reguły biznesowe i ograniczenia, a AI podpowiada przypadki brzegowe, alternatywne ścieżki, kombinacje parametrów.

Pierwsze podejście dobrze sprawdza się przy kodzie „technicznym”: adaptery, mapowania DTO, proste transformacje danych. Drugie – przy regułach domenowych, gdzie ważniejsze są sensowne scenariusze niż 100% pokrycia linijek.

Generowanie testów jednostkowych – plusy, pułapki i filtr zdrowego rozsądku

Przy podaniu konkretnego fragmentu kodu AI zwykle tworzy znośne szkielety testów. Różnica względem ręcznego pisania to tempo, ale też pewne charakterystyczne ograniczenia.

• Plusy:
  • szybkie wygenerowanie „szablonu” testów dla klasy, której programista jeszcze nie zna,
  • automatyczne podpowiedzi dla poprawek w istniejących testach po zmianach w interfejsie publicznym,
  • pomoc przy konfiguracji frameworków testowych (JUnit vs pytest vs NUnit itp.).
• Pułapki:
  • skłonno