Sytuacja wyjściowa: po co programiście automatyzacja z AI
Cel jest prosty: przyspieszyć pracę programisty, nie rozwalając przy tym architektury ani jakości kodu. AI ma być kolejnym narzędziem w toolboxie – takim samym jak debugger, linter czy framework – a nie magicznym autopilotem, który przejmuje projekt.
Jeszcze parę lat temu największym przyspieszaczem były dobre biblioteki, wyszukiwarka i snippet z Stack Overflow. Teraz tę rolę w dużej mierze przejmują modele językowe i wyspecjalizowane narzędzia AI. Potrafią pisać boilerplate, podsuwać poprawki, generować testy, tłumaczyć legacy kod. Równocześnie rodzi to bardzo racjonalny lęk: jeżeli model generuje znaczną część kodu, to kto realnie nad nim panuje?
Granica przebiega dokładnie tam, gdzie oddajesz AI decyzje projektowe. Automatyzacja powinna dotyczyć żmudnych, powtarzalnych fragmentów: transformacji, testów, migracji, dokumentacji, refaktoryzacji mechanicznej. Architektura, logika domenowa, decyzje o trade-offach wydajności i bezpieczeństwa – to nadal odpowiedzialność człowieka.
Dobrym przykładem jest senior opiekujący się dużym monolitem: początkowo blokuje w zespole każde użycie AI, bo boi się rozjazdu stylu i tajemniczych bugów. Po kilku iteracjach kończy jednak z workflow, w którym model generuje szkice testów i powtarzalne refaktoryzacje, a on sam decyduje, co wchodzi do repo. Zamiast walczyć z narzędziem, ustawia mu ścisłe granice.
Dlaczego programista boi się automatyzacji i jak to okiełznać
Rosnąca złożoność systemów a presja „dowieźć szybciej”
Dzisiejsze systemy to mikroserwisy, event-driven, chmura, kontenery, security by design, compliance. Złożoność eksploduje, a presja „dowieź funkcjonalność szybciej” wcale nie maleje. AI kusi obietnicą, że zdejmie część obciążenia z barków developera.
Jeżeli traktujesz AI jako „magicznego juniora”, który niby wszystko rozumie, a tylko nie ma dostępu do produkcji, to prędzej czy później projekt zacznie dryfować. Jeżeli traktujesz je jak wyspecjalizowane narzędzie do transformacji tekstu i kodu, z jasnymi granicami odpowiedzialności, zaczyna się robić sensownie.
Różnica jest mentalna: AI nie jest „programistą w pudełku”, tylko funkcją, która przepisuje, streszcza, dopisuje kod zgodnie z Twoim opisem. Jako autor opisu, nadal jesteś właścicielem decyzji.
Trzy dobrze znane obawy przy AI w pracy programisty:
utrata kontroli nad kodem – model generuje coś, czego nikt nie rozumie, ale brakuje czasu, żeby to przeanalizować,
rozjazd stylu i konwencji – każde wygenerowane miejsce wygląda inaczej, inne nazwy, inne wzorce, inny poziom defensywności,
copy–paste bez zrozumienia – juniorzy (i nie tylko) zaczynają akceptować sugestie AI bez weryfikacji, bo „skoro model zaproponował, to pewnie działa”.
Te lęki nie znikną od samego „nie używajmy AI”. Znikają dopiero wtedy, kiedy proces jest tak ustawiony, że nie da się (albo jest bardzo trudno) wrzucić do repo niezweryfikowanej generacji. Tu wchodzi w grę dyscyplina Gita, code review oraz jasne zasady, które zadania w ogóle wolno delegować AI.
Automatyzacja żmudnych czynności vs. oddanie projektu na autopilota
Automatyzacja z AI ma sens tam, gdzie istnieje powtarzalny wzorzec, a człowiek wnosi niewiele poza czasem. Przykłady:
tworzenie powtarzalnych DTO, mapperów, adapterów,
rysowanie szkieletu testów jednostkowych dla prostych funkcji,
generowanie migracji bazodanowych na podstawie zmian modeli,
pisanie dokumentacji do publicznych metod i endpointów,
Oddanie AI odpowiedzialności za architekturę, design modułów, kontrakty między serwisami czy krytyczne algorytmy wydajnościowe jest z kolei proszeniem się o bugi i dług technologiczny. Model nie zna Twojej domeny, nie rozumie kontekstu biznesowego, nie zrozumie prawniczych niuansów czy edge case’ów specyficznych dla klienta.
Granica jest prosta: AI może przyspieszyć implementację decyzji, których właścicielem jest człowiek. Nie powinno podejmować tych decyzji za Ciebie.
Krótki przykład: senior i monolit, który „nauczył się” AI
Praktyczny scenariusz: senior utrzymuje ogromny monolit napisany w Java/Spring. Zespół zaczyna eksperyment z asystentem w IDE. Początkowo pojawia się opór: „AI nam zniszczy kod, nie ogarniemy, kto co napisał, styl się rozjedzie”.
Po kilku sprintach zespół ustala zasady:
AI wolno używać do generowania testów, helperów, konwersji DTO,
wszelkie większe fragmenty kodu generowane przez model muszą przejść przez PR z opisem, co zostało wygenerowane i dlaczego,
AI nie wolno dotykać głównego modelu domenowego oraz warstwy integracji z systemami zewnętrznymi.
Po paru tygodniach senior widzi zysk: mniej czasu na „klepanie” powtarzalnych rzeczy, więcej na myślenie nad architekturą. Kontrola nie znika, bo każdy patch przechodzi przez standardowy proces Gita i code review. W praktyce wygląda to podobnie do korzystania ze snippetów – tylko dużo skuteczniej.
Źródło: Pexels | Autor: cottonbro studio
Jakie zadania programisty realnie nadają się do automatyzacji przez AI
Rozróżnienie: kreatywna architektura vs. powtarzalne transformacje
W pracy programisty są dwa rodzaje zadań:
zadania kreatywne – wymagają głębokiego zrozumienia biznesu, architektury, trade-offów, ryzyka,
zadania powtarzalne – bazują na rozpoznawalnym wzorcu, który można „przekuć” na opis tekstowy.
AI jest bardzo dobre w drugim typie: transformuje tekst na inny tekst, kod na inny kod, opis na szkic implementacji. To oznacza, że świetnie radzi sobie tam, gdzie masz jasny, powtarzalny schemat. Im bardziej przypomina to mechaniczne przepisywanie, tym lepiej nadaje się do automatyzacji.
Dobre kandydaty do automatyzacji
Zadania, które w większości zespołów można spokojnie delegować do AI (z sensownym nadzorem):
tworzenie testów jednostkowych – szkice testów dla metod, które mają wyraźne wejście/wyjście,
migracje baz danych – na podstawie zmian w modelach domenowych lub ORM,
skrypty pomocnicze – konwertery danych, jednorazowe ETL, generator danych testowych,
dokumentacja techniczna – podsumowanie endpointów, parametry, kody odpowiedzi, opis flow,
refaktoryzacje syntaktyczne – zamiana API biblioteki, zmiana stylu error handlingu, wyciąganie metod.
Te zadania mają kilka wspólnych cech: duża powtarzalność, stosunkowo niskie ryzyko biznesowe, łatwość weryfikacji po stronie człowieka i czytelny „expected output”. To idealny obszar na produktywne użycie AI.
Obszary, w których AI trzeba trzymać na krótkiej smyczy
Po drugiej stronie są obszary, w których rola AI powinna być mocno ograniczona:
decyzje architektoniczne – wybór między monolitem a mikroserwisami, CQRS, event sourcing,
AI może tu pełnić rolę konsultanta: podpowiedzieć znane wzorce, wskazać potencjalne dziury, zasugerować alternatywy. Decyzje powinny jednak zapadać po stronie architekta / senior developera, który zna kontekst biznesowy, prawny i operacyjny projektu.
AI jako autocomplete++ czy współautor modułu
W praktyce można wyróżnić dwa skrajne podejścia:
AI jako autocomplete++ – sugestie w edytorze, drobne fragmenty, pojedyncze linie, małe funkcje, wywoływane ad hoc,
AI jako współautor modułu – generowanie całych plików, komponentów, a nawet całych warstw na podstawie opisów.
Pierwsze podejście daje większe poczucie kontroli; drugie daje znacznie większą dźwignię produktywności, ale też większe ryzyko. Bez solidnego procesu review i kontroli wersji AI-współautor potrafi zanieczyścić repo chaotycznym, niespójnym kodem.
Bezpieczna ewolucja to start w trybie autocomplete++ i stopniowe poszerzanie obszarów, gdzie pozwalasz AI generować większe fragmenty, zawsze z jasnymi regułami CI/CD i review.
Projekty legacy – gdzie AI pomaga, a gdzie może zaszkodzić
Legacy kusi: „nie rozumiem tego monolitu, niech AI mi wytłumaczy i dopisze nową funkcję”. To jedna z najszybszych dróg do wyprodukowania brutalnie niebezpiecznej zmiany.
AI jest użyteczne przy legacy w zadaniach typu:
generowanie streszczeń plików i modułów,
komentarze do szczególnie zagmatwanych fragmentów,
pomoc w identyfikacji duplikacji i dead code’u,
propozycje refaktoryzacji mechanicznej (np. wydzielenie metody, zamiana API).
Natomiast proszenie modelu: „dopisz tu nową funkcję X, nie wiem, jak działa reszta systemu” zwykle kończy się tym, że AI przykleja się do powierzchownego wzorca, ignoruje niewidoczne zależności i edge case’y, które tylko długoletni maintainer ma w głowie. W rezultacie zmiana wygląda sensownie, przechodzi podstawowe testy, a potem wysadza produkcję przy rzadkim scenariuszu.
Modele pracy z AI: od autopilota w IDE do asystenta w terminalu
Integracje: wtyczki IDE, CLI, API, chat obok edytora
Najczęstsze sposoby wpięcia AI w workflow programisty:
wtyczki IDE (VS Code, JetBrains) – podpowiedzi inline, refaktoryzacje, chat „zna” aktualny plik lub całe repo,
CLI – narzędzie typu ai czy ai-fix.sh, które podajesz na STDIN plik lub diff, a na STDOUT dostajesz poprawkę,
API – własne skrypty integrujące AI z Twoimi narzędziami (np. generator PR description, auto-labeler),
chat obok edytora – klasyczne UI przeglądarkowe lub desktopowe, do którego wrzucasz snippet kodu i pytania.
Wtyczki w IDE są najwygodniejsze do szybkich podpowiedzi przy pisaniu. CLI sprawdza się, gdy chcesz mieć powtarzalne, zautomatyzowane kroki (np. wpięte w pre-commit lub lokalne skrypty). API przydaje się, gdy budujesz bardziej zaawansowane integracje zespołowe.
Z kolei projektowanie architektury, dzielenie systemu na bounded contexts, analiza konsekwencji prawnych użycia AI (np. w kontekście praktyczne wskazówki: informatyka) czy decyzje, czy optymalizować under/overfetching – to zadania, gdzie model może co najwyżej być tablicą do „odbijania” pomysłów, ale nie autorem decyzji.
asynchronicznie – przygotowanie szkicu patcha, większa refaktoryzacja, generowanie dokumentacji, testów.
Synchroniczny tryb daje poczucie „żywego pair-programmingu”: model sugeruje kod w rytmie Twojego pisania, reaguje na bieżące zmiany pliku. Świetne przy prostych, lokalnych zadaniach, ale łatwo wpaść w pułapkę kopiowania sugestii bez refleksji.
Asynchroniczny tryb wymaga, byś wyraźnie zdefiniował zadanie (prompt), a potem dostał wynik jako diff, patch, plik. Dobrze nadaje się do większych, powtarzalnych zmian, gdzie chcesz móc porównać „przed” i „po” w spokoju, np. przy code review lub przy refaktoryzacji kilkudziesięciu plików.
Różnica między narzędziem w edytorze a własnym skryptem
Ścieżki integracji: narzędzie „dla ludzi” kontra klocki do automatyzacji
Narzędzie w edytorze jest projektowane tak, żeby było ergonomiczne dla człowieka. Skrypt CLI lub własny serwis wokół API – żeby był ergonomiczny dla automatu.
Efektywnie różni się to kilkoma aspektami:
granularność – w edytorze działasz na poziomie kilku linii lub pliku, w CLI częściej na poziomie całego modułu, katalogu, a nawet repo (np. „przerób wszystkie kontrolery”),
reprezentacja zmian – plugin pokaże Ci diff w edytorze, CLI zwróci gotowy patch lub nowy plik na STDOUT, który możesz wpiąć w git apply,
powtarzalność – plugin pracuje ad hoc („co teraz wpiszę”), CLI łatwo opakować w skrypt z twardymi parametrami i używać w kółko tak samo,
kontrola kontekstu – w UI łatwiej „doklejać” kontekst (podświetlony plik, wybrane fragmenty), w skrypcie sam musisz zdecydować, które pliki, diffy i metadane trafią do modelu.
Rezultat: dla eksperymentów i szybkich „co by było, gdyby” w naturalny sposób sięga się po wtyczkę IDE. Gdy pojawia się potrzeba zautomatyzowania całej klasy zadań (np. generowanie changelogów, opisów PR, refaktoryzacja setek plików), sensownie jest zainwestować w cienką warstwę CLI/API nad modelem.
Autopilot, copilot i ręczny ster – jak dobrać poziom autonomii
„Autopilot” w kontekście AI w kodowaniu to po prostu zestaw domyślnych akcji, które dzieją się bez Twojej interakcji – np. automatyczne uzupełnianie całych bloków funkcji. „Ręczny ster” to sytuacja, w której każda generacja jest uruchamiana świadomie i przechodzi przez ręczne review.
Seniority i charakter projektu mocno wpływają na to, gdzie ustawić suwak:
projekty krytyczne (finanse, medycyna, systemy czasu rzeczywistego) – sensowny jest tryb „ręczny ster plus minimalny autopilot” (krótkie sugestie, brak masowych modyfikacji bez PR),
projekty wewnętrzne, narzędzia devopsowe – można pozwolić sobie na „copilota”: generowanie całych plików naraz, ale zawsze z kontrolą w PR,
prototypy, hackathony – pełny autopilot jest wręcz pożądany, bo liczy się czas do działającego demo, a nie perfekcyjna historia Git.
Dojrzały zespół zwykle kończy z hybrydą: AI ma prawo samodzielnie proponować zmiany w mniej ryzykownych obszarach (testy, adaptery, DTO), natomiast każde dotknięcie domeny, bezpieczeństwa czy krytycznych algorytmów musi być ręcznie wyzwolone i dokładnie sprawdzone.
Źródło: Pexels | Autor: hitesh choudhary
Projektowanie promptów jak interfejsu API – precyzja zamiast magii
Dlaczego „napisz mi serwis do obsługi zamówień” to zły kontrakt
Prompt jest dla modelu tym, czym kontrakt API dla innego serwisu. Jeżeli kontrakt jest ogólnikowy, implementacja będzie nieprzewidywalna. Prośba typu „napisz serwis do obsługi zamówień” nie definiuje:
jak wygląda model danych,
jakie są scenariusze użycia (use cases),
jakie wyjątki i kody błędów są akceptowalne,
jakie ograniczenia niefunkcjonalne mają znaczenie (wydajność, bezpieczeństwo, logowanie).
Efekt: model musi zgadywać. Raz zgadnie nieźle, innym razem wstawi logikę walidacji w kontroler, zapomni o transakcjach albo „wytnie” część edge case’ów. Z punktu widzenia kontroli nad kodem to jak korzystanie z nieudokumentowanej biblioteki z NPM-a „bo działa na moim przykładzie”.
Prompt jako specyfikacja: wejście, wyjście, założenia
Bezpieczny prompt zawiera te same elementy, które wrzuciłbyś do porządnego ticketu w Jirze lub opisu endpointu:
wejście – struktury danych, typy, przykładowe payloady,
wyjście – oczekiwany kształt danych, format błędów, statusy,
założenia domenowe – co jest dopuszczalne, co ma być zabronione (np. „nie modyfikuj statusu zamówienia z PAID na NEW”),
ograniczenia techniczne – wzorce, które trzeba zachować (DDD, CQRS, architektura warstwowa),
styl i konwencje – nazewnictwo, styl błędów, preferowane idiomy (np. „używaj Result<T> zamiast rzucania wyjątków”).
Przykładowy szkielet promptu dla wygenerowania serwisu aplikacyjnego:
Jesteś asystentem w projekcie sklepu internetowego.
Kontekst:
- Język: C#, .NET 8
- Styl: DDD, warstwa aplikacyjna nie zna ORM
- Repozytoria zwracają agregaty domenowe
Zadanie:
- Napisz serwis aplikacyjny OrderApplicationService z metodą:
Task ConfirmPaymentAsync(Guid orderId, string paymentId)
Wejście:
- Order ma statusy: Draft, PendingPayment, Paid, Cancelled
Założenia:
- Potwierdzenie płatności jest możliwe tylko ze stanu PendingPayment
- Zmiana stanu musi zostać zapisana przez IOrderRepository
- Nie twórz nowych modeli domenowych
Oczekiwane:
- Pokaż pełen kod klasy (bez interfejsów), bez komentarzy
- Zwracaj domenowy wyjątek InvalidOrderStateException w nieprawidłowych stanach
Taki opis redukuje „magiczność” generacji. Zamiast liczyć, że model zgadnie architekturę, dajesz mu dokładny, powtarzalny kontrakt.
Konwencje promptów jako „style guide” zespołu
Warto traktować prompty jak element „style guide’u” zespołu. Tak jak istnieją guidelines co do nazewnictwa klas i struktury katalogów, tak samo można ustalić:
jak opisywać kontekst technologiczny (język, framework, poziom warstwy),
jak opisywać granice domenowe (co wolno dotykać, czego nie ruszać),
jak formułować oczekiwany output (pełny plik, diff, same metody),
jak oznaczać fragmenty, które musi zweryfikować człowiek (np. „oznajmij TODO w miejscach niepewności”).
Dobry wzorzec promptu można wrzucić do repo jako PROMPTING_GUIDE.md i stosować podobnie jak konwencje commit message’y. Dzięki temu output z AI staje się przewidywalny i łatwiejszy do code review.
Iteracyjne doprecyzowanie – jak nie utopić się w jednym, gigantycznym prompecie
Kuszące jest napisanie jednego, ogromnego promptu: „opisz całą architekturę i wygeneruj warstwę API, aplikacyjną i domenową”. To zwykle kończy się ścianą kodu o mieszanej jakości. Dużo lepiej podejść do zadania iteracyjnie, jak do wersjonowania API:
pierwszy prompt – projekt szkicu interfejsu (np. same sygnatury metod w serwisach),
drugi – implementacja jednej metody z pełnym kontekstem domeny,
trzeci – rozszerzenie o obsługę błędów i logowanie,
kolejne – refaktoryzacja powtarzających się patternów, ekstrakcja abstrakcji.
Na każdym kroku masz okazję zatrzymać się, porównać, co zostało wygenerowane, i skorygować oczekiwania w promptach. To dokładnie to, co robisz z publicznym API: zaczynasz od minimalnego, działającego interfejsu i dopiero potem dodajesz kolejne funkcje.
Prompty dla refaktoryzacji: opis transformacji zamiast targetu
Przy refaktoryzacjach lepiej opisywać transformację niż stan docelowy. Zamiast „przepisz na nowy styl error handlingu”, lepiej:
Masz plik z kontrolerem Web API napisany w ASP.NET Core.
Aktualny styl:
- Metody rzucają wyjątki domenowe (DomainException)
- Globalny middleware mapuje wyjątki na HTTP 400/500
Zadanie:
- Dla każdej akcji kontrolera:
- Zastąp rzucanie DomainException zwracaniem wyniku typu Result<T>
- Zwróć odpowiedni IActionResult na podstawie Result:
- Success => 200/201
- ValidationError => 400
- NotFound => 404
Ograniczenia:
- Nie zmieniaj sygnatur publicznych metod kontrolera
- Nie dotykaj innych klas niż bieżący kontroler
Output:
- Pokaż tylko zrefaktoryzowany kod kontrolera
Model dostaje wtedy jasną regułę, jaki <emrodzaj zmiany ma wprowadzić, a nie tylko mglisty opis „zrób ładnie”. Da się to powtarzać w kolejnych plikach niemal jak makro.
Kontrola wersji i AI – jak nie rozwalić historii Git
AI jako generator patchy, nie „cichy edytor”
Największe ryzyko przy użyciu AI to sytuacja, w której „coś” zmienia kod poza świadomością zespołu. Z punktu widzenia Gita oznacza to duże, nieopisane diffy z przypadkowymi modyfikacjami. Żeby temu przeciwdziałać, AI trzeba traktować jak generator patchy:
wtyczka IDE powinna pokazywać sugestie jako wyraźne propozycje, które świadomie akceptujesz,
CLI powinno wyrzucać zmiany jako diff (git diff na STDOUT) albo nowy branch,
nie ma „auto-commitów” z AI – commit zawsze wykonuje człowiek, z sensownym opisem.
Tip: jeśli narzędzie AI integruje się z Gitem, wyłącz funkcje typu „auto-commit after apply fix”. Zawsze chcesz mieć moment zatrzymania się i przejrzenia diffu.
Małe, semantyczne commity zamiast jednego „AI did it”
Łatwo jest wrzucić wszystko do jednego commita z opisem „AI refactor” i ruszyć dalej. Po kilku tygodniach debugowanie z git bisect zamienia się w horror, bo trafiasz na commit, który zmienił 150 plików w kilku wątkach na raz.
Bezpieczniejszy wzorzec to:
commit per typ zmiany (np. „refactor: zamiana wyjątków na Result w kontrolerach”, „chore: dodanie testów kontraktowych do endpointów X,Y,Z”)
maksymalna wielkość diffu – ustalona zespołowo, np. „powyżej 500 linii w PR wymagamy dodatkowego review”,
oznaczanie AI-generated – proste tagi w opisie PR lub commit message, np. [ai-generated], żeby później łatwo znaleźć te fragmenty.
Jeżeli AI generuje duże refaktoryzacje, sensowne jest najpierw wygenerowanie całego zestawu zmian na osobnym branchu, a potem manualne pocięcie go na mniejsze commity tematyczne. Dla historii projektu to ogromna ulga.
Pre-commit i CI jako filtr dla generowanego kodu
AI jest w stanie produkować kod szybciej niż człowiek zdąży go czytać. Dlatego pipeline techniczny musi być ustawiony tak, żeby odfiltrować najgorsze pomysły, zanim trafią na branch główny:
pre-commit – lint, formatowanie, proste testy jednostkowe; dzięki temu model nie będzie „przepychał” oczywistych problemów (brak importów, naruszenie stylu),
CI – pełny zestaw testów, analiza statyczna, skan bezpieczeństwa; generowany kod przechodzi przez identyczny tor jak kod ręczny,
reguły ochrony branchy – brak możliwości bezpośredniego pushowania na main/master, PR wymagający recenzji (najlepiej dwóch przy większych zmianach).
Jeżeli pipeline jest spięty dobrze, AI nie ma „drogi na skróty”. Może tylko przyspieszyć tworzenie kodu, ale nie jest w stanie ominąć kontroli jakości w Gicie.
Strategie branchowania pod pracę z AI
Przy intensywnym użyciu AI wygodnie jest wyodrębnić osobne gałęzie dla generowanych refaktoryzacji:
feature/* – standardowe funkcje, gdzie AI wspiera, ale zmiany są mocno kontekstowe,
ai-refactor/* – gałęzie, na których AI robi mechaniczne zmiany w wielu plikach (np. zmiana biblioteki logującej, migracja na inny ORM),
spike/* – eksperymenty z generowaniem większych modułów, które być może nigdy nie trafią do produkcji.
Taki podział ułatwia zrozumienie historii i pozwala przeglądać PR-y z generowaną zawartością nieco innym okiem („wiem, że tu jest dużo automatyki, szukam głównie oczywistych regresji i złamanych założeń architektonicznych”).
Opis PR: gdzie AI pomaga, a co musi napisać człowiek
Generowanie opisów PR przez AI jest jednym z najwdzięczniejszych use case’ów: narzędzie czyta diff i streszcza zmianę. Żeby nie stracić kontroli, sensownie jest podzielić odpowiedzialności:
AI – generuje listę zmienionych plików, streszcza techniczne zmiany (np. „dodano nowe endpointy”, „przepisano serwis X na async/await”),
autor PR – dopisuje motywację zmiany, ryzyka domenowe, uwagi do rollout’u („feature flag X, migracja Y”),
szablon PR – wymusza sekcje typu „Dlaczego”, „Jak testowane”, „Zmiany w kontraktach zewnętrznych”.
Sygnowanie zmian z AI – adnotacje w kodzie i commitach
Jeżeli AI pomaga w większej części kodu, opłaca się zostawiać ślady w miejscach, które potencjalnie będą wymagały późniejszego przeglądu. Nie chodzi o wielkie banery w stylu „UWAGA AI”, tylko o drobne, praktyczne adnotacje:
komentarze typu // TODO: verify logic with domain expert (generated by AI) przy nieoczywistych decyzjach biznesowych,
tagi w commit message’ach, np. [ai] refactor: migrate OrderController to Result<T>,
etykiety w PR, np. ai-assisted, ai-heavy, które pozwalają później filtrować zmiany.
Dzięki temu za kilka miesięcy, gdy ktoś trafi na dziwny fragment, może szybko sprawdzić, czy to „ręczna twórczość”, czy kawałek, który wyszedł z modelu i tylko został przejrzany. To przyspiesza decyzję: poprawiać od razu, czy najpierw ustalić z biznesem, o co tu właściwie chodzi.
Strategie revertów dla kodu generowanego
Kiedy AI zmieniło dużo, a coś poszło źle, chcesz mieć prostą ścieżkę powrotu. Z punktu widzenia Gita najlepiej działa kilka prostych zasad:
grupowanie zmian AI w osobnych commitach (bez mieszania z ręcznymi poprawkami),
oznaczanie commitów zawierających wyłącznie mechaniczne refaktoryzacje (np. refactor(ai-only): ...),
unikanie „przyklejania” logiki biznesowej do tych samych commitów, które wprowadzają generowaną infrastrukturę.
Wtedy git revert staje się realnym narzędziem: możesz cofnąć jedną większą falę refaktoryzacji bez rozwalania nowszych zmian domenowych. Przy refaktoryzacjach robionych seriami sensowne jest też tagowanie ważnych punktów stanu repo (np. pre-ai-refactor-domain-orders), żeby mieć stabilny „kotwiczny” commit.
Źródło: Pexels | Autor: Jakub Zerdzicki
AI w code review – drugi recenzent, nie „wyrocznia”
Jakich opinii oczekiwać od AI w review
Model jest świetny jako recenzent „szerokiego kąta”: widzi wzorce, powtarzalne błędy i typowe antywzorce. Gorzej radzi sobie z kontekstem biznesowym i długiem architektonicznym specyficznym dla danego projektu. Dlatego warto rozdzielić role:
AI – styl, powtarzalne bugi, zapachy architektoniczne (np. zbyt duże klasy, powielone fragmenty), niespójność nazw, nieużywany kod,
człowiek – zgodność z modelem domenowym, kontrakty między usługami, scenariusze edge-case’ów, ryzyka operacyjne.
Dobrze skonfigurowane narzędzie AI do review może pełnić podobną funkcję jak lint – zbiera „łatwe” uwagi, żeby recenzent mógł skupić się na rzeczach nietrywialnych.
Prompt dla AI-recenzenta jako polityka review
Zamiast kliknąć „review diff” i liczyć, że model „coś mądrego powie”, dużo lepiej jest zdefiniować stały szablon promptu dla review. Przykład:
Jesteś recenzentem pull requestów w projekcie <tu opisz stos>.
Zasady projektu:
- Silne rozdzielenie warstw: API, aplikacyjna, domenowa, infrastruktura
- Brak logiki domenowej w kontrolerach
- Wyjątki domenowe tylko w warstwie domeny
Zadanie:
- Przejrzyj diff poniżej
- Wypisz listę uwag w kategoriach:
- Błędy (mogą powodować bugi lub problemy w runtime)
- Niespójności z zasadami architektury
- Sugestie poprawy czytelności
Ograniczenia:
- Nie sugeruj zmiany technologii ani dużych przebudów
- Nie przepisywaj całych klas, podawaj krótkie sugestie
Taki prompt trzymany w repo jako AI_REVIEW_GUIDE.md sprawia, że uwagi z modelu są bardziej przewidywalne i nie wykraczają poza przyjętą architekturę.
Jak łączyć uwagi AI i ludzi w jednym PR
W praktyce dobrze działa model, w którym AI jest pierwszą linią:
autor PR puszcza AI-review lokalnie lub przez integrację w CI i poprawia „proste rzeczy”,
następnie PR trafia do ludzkiego reviewera, który widzi już „oczyszczony” diff,
jeśli AI jest zintegrowane z GitHub/GitLab, jego komentarze są oznaczone etykietą lub botem, co pozwala łatwo je odfiltrować.
Uwaga: komentarze AI nie powinny blokować mergowania. To sugestie, nie reguły. W blokujące checki lepiej przekuć lintery, testy i static analysis, a nie opinię modelu o „lepszej nazwie metody”.
Unikanie „gaslightingu” przez AI w code review
Modele potrafią bardzo przekonująco uzasadniać błędne sugestie. Żeby nie wpaść w pułapkę ślepej wiary:
proś model o referencje do konkretnych fragmentów kodu („wskaż linie, gdzie występuje problem”),
wymuszaj precyzję: „pokaż minimalną poprawkę w stylu diff zamiast opisu słownego”,
nie pozwalaj na ogólne stwierdzenia typu „to może być race condition” bez wskazania konkretnych miejsc.
Jeżeli model zgłasza potencjalny błąd, ale nie potrafi go pokryć scenariuszem testowym lub ścieżką wykonania, traktuj to jako słabą hipotezę, nie fakt.
Review generowanego kodu: inne kryteria niż dla ręcznego
Kod generowany przez AI bywa bardziej „szablonowy”, ale też mniej dopasowany do nietypowych miejsc projektu. Przy jego review warto zwracać uwagę na dodatkowe aspekty:
czy AI nie wprowadziło nowego „mini frameworka” (własne klasy helperów, abstrakcje, które dublują istniejące),
czy nowy kod naprawdę używa istniejących usług/infrastruktury, zamiast dublować ich funkcje,
czy nie ma nadmiarowej konfiguracji, boilerplate’u, który można zastąpić jednym wywołaniem istniejącej biblioteki.
Dobrym nawykiem jest przegląd generowanego kodu pod kątem „czy moglibyśmy to skrócić o 30% bez utraty czytelności”. AI ma tendencję do ekspandowania, a nie kompresowania.
Generowanie testów, dokumentacji i migracji – automatyzacja żmudnych fragmentów
Testy jednostkowe: generowane szkielety, nie finalny produkt
Modele świetnie radzą sobie z produkcją szkieletów testów: nazwy przypadków, podstawowe dane wejściowe, konfiguracja mocków. Znacznie gorzej jest z faktycznymi asercjami, szczególnie przy złożonej logice domenowej.
Dobry workflow dla unit testów wygląda tak:
oznacz pliki/klasy wymagające pokrycia (np. wszystkie nowe publiczne serwisy aplikacyjne),
poproś AI o wygenerowanie zestawu testów w stylu danej biblioteki (xUnit, NUnit, Jest, pytest) z naciskiem na różne gałęzie logiki,
samodzielnie doprecyzuj asercje i scenariusze graniczne.
Tip: w promptach dla testów podawaj przykłady specyfikacji w języku biznesowym:
Dla serwisu OrderDiscountService podaj scenariusze testowe w stylu:
- "Gdy klient typu VIP składa zamówienie powyżej 1000 zł, nalicz 10% rabatu"
- "Gdy klient typu Standard składa zamówienie poniżej 100 zł, nie naliczaj rabatu"
Model lepiej wtedy mapuje testy na faktyczne reguły biznesowe, a nie przypadkowe liczby.
Przy API (HTTP, gRPC, messaging) AI może znacząco przyspieszyć tworzenie testów kontraktowych:
generowanie przykładów request/response na podstawie OpenAPI/Protobuf,
tworzenie scenariuszy dla testów E2E (np. ścieżka „szczęśliwa” + kilka typowych błędów),
mapowanie istniejącej dokumentacji endpointu na konkretne przypadki testowe.
Jeżeli specyfikacja API jest maszynowo czytelna (OpenAPI, AsyncAPI), można użyć jej jako twardego źródła prawdy w promptach i poprosić model o wygenerowanie testów, które sprawdzają każdy opisany status HTTP lub typ zdarzenia.
Dokumentacja techniczna generowana z kodu i commitów
AI jest wyjątkowo użyteczna przy generowaniu dokumentacji wtórnej (na podstawie kodu i historii zmian), a nie przy wymyślaniu specyfikacji od zera. Przykładowe zastosowania:
streszczenie zmian w module na podstawie historii commitów z ostatnich tygodni,
tworzenie „how-to” dla konfiguracji nowych instancji usług na bazie istniejącego kodu i plików YAML.
Żeby dokumentacja nie odjechała w science-fiction, w promptach warto ograniczyć źródła:
Na podstawie poniższych plików:
- OrderController.cs
- OrderApplicationService.cs
- IOrderRepository.cs
Wygeneruj techniczną dokumentację modułu Zamówienia:
- Krótki opis odpowiedzialności modułu
- Publiczne endpointy HTTP (metoda, ścieżka, parametry)
- Wyjątki domenowe, które może zwrócić API
Nie wymyślaj nowych funkcji, opieraj się wyłącznie na kodzie.
Taka dokumentacja jest potem łatwa do weryfikacji – porównujesz ją z kodem i od razu widać, czy model coś dopisał „z głowy”.
Utrzymywanie dokumentacji żywej z pomocą AI
Największy problem z dokumentacją to jej dezaktualizacja. AI może pomóc w automatycznej detekcji rozjazdów:
porównywanie obecnego kodu z istniejącym README modułu i wypunktowanie rozbieżności,
propozycje zmian w opisach endpointów API po dodaniu nowych parametrów,
generowanie changelogów na poziomie modułów na bazie commitów z określonego zakresu.
Można to nawet zintegrować z CI: job, który przy większych zmianach w module generuje propozycję aktualizacji dokumentacji i dołącza ją jako komentarz do PR. Autor tylko akceptuje i dopisuje niuanse biznesowe.
AI przy migracjach schematu bazy danych
Migracje to idealny kandydat do automatyzacji, ale też miejsce, gdzie łatwo o katastrofę. Rozsądny sposób użycia AI przy migracjach:
najpierw ręczne zaprojektowanie modelu docelowego (diagram, opis encji i relacji),
potem użycie AI do wygenerowania szkieletu migracji z konkretnych różnic między stanem obecnym a docelowym,
na końcu dokładna weryfikacja i dopisanie kroków związanych z danymi (migracja wartości, backfill, konwersje typów).
Przykładowy prompt:
Masz obecny model EF Core (klasy + konfiguracje) oraz docelowy model po zmianach.
Wygeneruj migrację:
- Dodaj nową tabelę PaymentMethods
- Dodaj kolumnę PaymentMethodId do Orders (nullable, z domyślną wartością NULL)
- Nie usuwaj jeszcze starych kolumn związanych z płatnością
Nie generuj kodu aktualizującego dane. To zrobi człowiek w osobnej migracji.
Model dostaje jasno rozdzielone zadania: struktura bazy – tak, migracja danych – nie. Przy danych domenowych zawsze potrzebujesz kogoś, kto zna biznes i rozumie, co oznacza „pusta wartość” w danym kontekście.
Generowanie migracji danych z kontrolowanym zakresem
Jeżeli migracje obejmują duże ilości danych, AI może przygotować szkielety skryptów, ale nie powinno decydować o strategii migracji (batchowanie, okna czasowe, wpływ na SLA). Zdrowy kompromis:
człowiek opisuje strategię: „migrujemy po 10k rekordów, tylko nocą, z logowaniem do tabeli pomocniczej”,
AI generuje kod, który tę strategię implementuje w wybranej technologii (SQL/PLSQL, migracje ORM, joby w workerach),
review skupia się na zgodności implementacji ze strategią, nie na mechanicznych szczegółach.
Uwaga: ai-generated skrypty migracyjne zawsze powinny być testowane na kopii produkcyjnej bazy lub przynajmniej na zanonimizowanym dumpie. Modele potrafią pominąć indeksy, locki lub wpływ na replikację.
Automatyczne uzupełnianie komentarzy i docstringów
Jeśli w projekcie obowiązują komentarze do publicznych API (docstringi, XML comments, JSDoc), AI może odciążyć z ich pisania. Podstawowy wzorzec:
na wejściu – metoda/klasa + ewentualnie krótki opis domenowy,
na wyjściu – komentarz w zadanym stylu (np. JSDoc) z opisem parametrów, wyjątków, zwracanej wartości.
Żeby uniknąć „dokumentowania oczywistości” i powtarzania nazw w opisach, w promptach dodaj filtr:
Dodaj komentarze XML do publicznych metod.
Zasady:
- Nie powtarzaj nazwy parametru w jego opisie
- Skup się na celu metody i efektach ubocznych
- Jeśli metoda rzuca wyjątki domenowe, opisz w jakich sytuacjach
Dobry docstring powinien mówić „po co” i „kiedy się wysypie”, nie „co robi linijka po linijce”. AI trzeba tego nauczyć wprost.
Najczęściej zadawane pytania (FAQ)
Jak używać AI w programowaniu, żeby nie stracić kontroli nad kodem?
Kluczowe jest ustawienie roli AI: to ma być narzędzie do transformacji kodu i tekstu, a nie samodzielny „programista w pudełku”. AI może generować szkielety testów, boilerplate, migracje czy dokumentację, ale ostateczne decyzje projektowe i akceptacja zmian zawsze powinny należeć do człowieka.
Praktycznie oznacza to, że każdy fragment kodu wygenerowany przez model przechodzi normalny proces: commit z czytelnym opisem, pull request, code review. Dodaj też jasne zasady w zespole, do jakich typów zadań wolno używać AI i które obszary (np. logika domenowa, bezpieczeństwo) są z tej automatyzacji wyłączone.
Jakie zadania programisty najbardziej opłaca się automatyzować za pomocą AI?
Największy zwrot daje automatyzacja zadań powtarzalnych, które mają przewidywalny wzorzec i łatwy do sprawdzenia rezultat. Przykładowo:
tworzenie szkieletów testów jednostkowych dla prostych metod,
migracje baz danych na podstawie zmian w modelach/ORM,
skrypty pomocnicze: konwertery danych, jednorazowe ETL, generator danych testowych,
dokumentacja techniczna endpointów i publicznych metod,
mechaniczne refaktoryzacje: zmiana API biblioteki, stylu error handlingu, wyciąganie metod.
W tych obszarach wkład człowieka to głównie czas i dyscyplina, a nie kreatywne decyzje. AI potrafi je skutecznie skrócić, a ty nadal trzymasz rękę na pulsie przez weryfikację outputu.
Czego nie powinienem oddawać AI w projekcie programistycznym?
AI nie powinno samodzielnie podejmować decyzji tam, gdzie potrzebne jest głębokie rozumienie domeny i pełny kontekst biznesowy. Szczególnie ryzykowne jest powierzanie mu:
decyzji architektonicznych (monolit vs mikroserwisy, CQRS, event sourcing),
kluczowej logiki biznesowej (przepisy, regulaminy, podatki, złożone workflowy),
krytycznych algorytmów wydajnościowych (intensywnie używane w runtime, złożone obliczeniowo),
obszarów bezpieczeństwa (autoryzacja, szyfrowanie, przechowywanie haseł, rotacja kluczy).
Model może tu pełnić rolę konsultanta: podsunąć wzorce, alternatywy, checklistę ryzyk. Ostateczna decyzja i implementacja powinny jednak należeć do architekta lub seniora, który zna realia systemu i wymagań.
Jak uniknąć chaosu w stylu kodu przy korzystaniu z AI (rozjazd namingów, wzorców)?
Podstawą jest spójny „kontrakt” ze stylem: lokalne linters/formattery, definicja konwencji nazewniczych i wzorców projektowych oraz ich egzekwowanie w code review. AI trzeba nauczyć tych zasad w promptach i przypominać o nich przy generacji kodu.
Przykład praktyczny: w PR jasno zaznaczaj, które fragmenty są wygenerowane przez model i oceniaj je bardziej pod kątem spójności ze stylem niż „magicznej poprawności”. Uwaga: dobrze działa zasada, że AI generuje raczej małe fragmenty w istniejącym pliku niż całkiem nowe moduły bez kontekstu repozytorium.
Czy junior programista powinien korzystać z AI, czy to utrudni naukę?
AI może przyspieszyć naukę, ale tylko wtedy, gdy jest używane świadomie. Dobry pattern dla juniora to:
najpierw samodzielna próba rozwiązania problemu,
potem użycie AI do porównania podejścia i wychwycenia lepszych wzorców,
obowiązkowo: ręczna analiza wygenerowanego kodu, linijka po linijce.
Problem pojawia się, gdy junior zaczyna akceptować sugestie bez zrozumienia („skoro AI zaproponowało, to działa”). Wtedy rośnie ryzyko bezmyślnego copy–paste i braku rozwoju. Tip: w zespole można wprowadzić zasadę, że w opisie PR junior musi wytłumaczyć, jak działa kluczowy fragment kodu – także wtedy, gdy AI pomogło go napisać.
Jak ustawić proces w zespole, żeby AI nie wrzucało śmieci do repozytorium?
Sprawdzony schemat to połączenie kilku elementów:
jasne zasady, do jakich typów zadań wolno używać AI (np. „tak” dla testów i helperów, „nie” dla modelu domenowego),
wymóg oznaczania w PR, które fragmenty kodu zostały wygenerowane,
code review nastawione na zrozumiałość i spójność, a nie tylko „przechodzi testy”.
Dobrym nawykiem jest też praca na małych, izolowanych zmianach. Jeżeli AI wygeneruje większy refaktoring, rozbij go na mniejsze commity, które łatwiej przeczytać i odrzucić w razie problemów. To działa podobnie jak z manualnymi zmianami – tylko tempo tworzenia patchy jest wyższe.
Czy lepiej traktować AI jako „autocomplete++”, czy pozwalać mu pisać całe moduły?
Bezpieczniej zacząć od trybu „autocomplete++”: krótkie sugestie w IDE, pojedyncze funkcje, fragmenty testów. Masz wtedy pełny kontekst pliku, łatwiej wychwycić błędy i dopasować styl. Ten tryb jest szczególnie sensowny w dużych, żyjących projektach z ugruntowaną architekturą.
Generowanie całych modułów z opisu (np. całej warstwy API) ma sens w ściśle ograniczonych kontekstach: nowe serwisy, prototypy, jednorazowe narzędzia. Nawet wtedy warto potraktować pierwszy output jako szkic, który przechodzi po człowieku gruntowną rewizję i dostosowanie do realiów projektu.
