Nie, AI nie obniża jakości kodu. Ono ujawnia braki procesowe
Coraz częściej słyszę, że kod z AI jest po prostu gorszej jakości. Że modele produkują bałagan, a jakość spada wraz z liczbą wygenerowanych linii. To wygodna diagnoza. I zwykle fałszywa. Jakość nie zależy wyłącznie od autora kodu. Zależy od wymagań, architektury, testów i standardów pracy. AI przyspiesza implementację, ale nie przyspiesza automatycznie decyzji, feedbacku ani walidacji hipotez. Nie tworzy braków procesowych. Sprawia tylko, że ich konsekwencje wychodzą na jaw szybciej.
Key Points
|
AI przesuwa bottleneck z kodowania na wymagania i decyzje
Kodowanie przestaje być głównym ograniczeniem. AI pozwala budować kolejne elementy systemu wielokrotnie szybciej, więc wąskim gardłem stają się wymagania, decyzje produktowe i tempo feedbacku. Pisaliśmy o tym szerzej w tekście o prawdziwych ograniczeniach delivery z AI. Tu chcę się skupić na czymś innym: co ta zmiana robi z kosztem błędu.
Ten sam błąd. Znacznie wyższy koszt
Kiedyś wokół niewłaściwego założenia produktowego przez dwa tygodnie powstawały trzy historyjki. Dziś może powstać ich dwadzieścia albo trzydzieści. Każda kolejna funkcja, integracja i test zaczyna zależeć od tego założenia. Gdy wreszcie ktoś zauważy pomyłkę, do zmiany jest już nie jeden endpoint, tylko cały fragment produktu. Błąd został ten sam. A koszt utraconych korzyści wystrzelił w kosmos.
Czas poświęcony na odkręcenie złego kierunku nie idzie już na rozwój produktu. W tym samym okresie mogłoby powstać znacznie więcej wartościowych zmian. Co za tym idzie, tracisz nie tylko czas potrzebny na naprawę błędu. Tracisz też wszystko, co zespół mógłby wtedy dowieźć.
Bug w implementacji boli. Gorzej, gdy błędna decyzja produktowa albo architektoniczna zdąży już obrosnąć kolejną warstwą kodu z AI. Dlatego rozmowa o „jakości kodu generowanego przez AI” jest za wąska, jeśli pomija jakość decyzji i tempo ich weryfikacji.
Jak refinement wpływa na jakość kodu generowanego przez AI
Trzeba zadbać o jakość kodu jeszcze przed implementacją. W momencie, gdy ktoś precyzuje, jaki problem rozwiązujecie i po czym poznacie, że jest rozwiązany.
Kodując z AI, programiści rzadko startują od pustego prompta. W backlogu jest user story i zwykle kilka kryteriów akceptacji. Problem w tym, że często brakuje części wymagań albo kontekstu biznesowego: po co ta funkcja ma istnieć, jakie wyjątki obowiązują i jak będzie wyglądał sukces. AI nie zostawi tych luk pustych. Oprze się na tym, co ma pod ręką: wzorcach z codebase’u, podobnych funkcjach i typowych założeniach z treningu. Część z tego będzie sensowna. A część okaże się kompletnie nietrafiona. Podczas code review łatwo to przeoczyć, bo kod wygląda „porządnie”, choć ważne decyzje nigdy nie zostały domknięte z biznesem.
Dlatego deweloperzy nie powinni po prostu odbierać gotowych zadań od Product Ownera. Powinni wspólnie z biznesem dopinać cel funkcji, reguły, wyjątki, kryteria akceptacji, zależności i ryzyka. Czas poświęcany na refinement powinien wzrosnąć kilkukrotnie: im szybciej AI koduje, tym więcej uwagi trzeba włożyć w przygotowanie pracy. Spec-driven development jest tu dobrym przykładem: najpierw powstaje precyzyjna specyfikacja, a dopiero potem kod. Ta sama specyfikacja staje się kontekstem dla ludzi i dla agentów AI.
Pracuj w małych iteracjach
Gdy AI przyspiesza delivery, dłuższy sprint szybko przestaje pasować do tempa pracy. Zmian jest za dużo, a review i odbiór nie nadążają. Dostosuj długość sprintu i częstotliwość review do nowego rytmu kodowania.
W naszych zespołach dwutygodniowe sprinty przestawały działać. Zmian przybywało tak szybko, że trudno było je sensownie omówić w czasie przewidzianym na review. Spotkania ciągnęły się przez 4–5 godzin. Skróciliśmy więc sprinty do tygodnia. Dzięki temu biznesowi łatwiej nadążyć za liczbą zmian wdrażanych w sprincie.
Krótsze sprinty pomagają też szybciej wykryć nietrafione inicjatywy. Im wcześniej je zatrzymasz, tym mniej kosztuje ich odkręcenie. I nie dokładaj kolejnych funkcji tylko dlatego, że zespół potrafi je produkować szybciej, niż biznes jest w stanie je ocenić.
AI nie zabija agile
Część zespołów wyciąga odwrotny wniosek: skoro AI koduje szybciej, po co nam sprinty, review i ceremonie. Wystarczy prompt i merge. To kuszące. I zwykle kończy się większym bałaganem niż przed wdrożeniem narzędzi.
Agile nie było odpowiedzią na wolne kodowanie. Było odpowiedzią na niepewność: złe założenia, zmieniające się priorytety i feedback, który przychodzi za późno. AI tej niepewności nie usuwa. Wręcz przeciwnie: przyspiesza tempo, w jakim niepewność zamienia się w kod.
Po wdrożeniu AI praktyki zwinne nabierają większej wagi niż kiedykolwiek. Potrzebne są krótkie iteracje, częsty feedback, możliwość szybkiej zmiany priorytetów i prawo do zatrzymania prac, zanim błędna decyzja stanie się zbyt kosztowna, by ją odkręcić. Nie dlatego, że tak każe podręcznik Scruma. Dlatego, że przy nowym tempie delivery jedyny tani moment na korektę wypada jeszcze przed wdrożeniem funkcjonalności.
Bez tych praktyk szybsze kodowanie nie daje przewagi. Daje tylko szybsze pomyłki. A gdy kod powstaje w tak szybkim tempie, sama zwinność nie wystarczy: potrzebujesz też kontroli jakości, która nadąża za delivery.
Jak testować kod z AI: zachowanie systemu, CI/CD i code review
Testy powinny odpalać się zawsze, dla każdego nowego fragmentu kodu. Przy tempie, jakie daje AI, automatyzacja testów nie jest już opcjonalna. Ręczne testowanie jest po prostu za wolne, żeby nadążyć za ilością zmian.
Sprawdzaj, czy system robi to, czego oczekuje użytkownik
Najwięcej dają testy akceptacyjne, funkcjonalne, end-to-end i integracyjne. One sprawdzają realne ścieżki użytkownika i reguły biznesowe, a nie tylko to, czy pojedyncza funkcja w izolacji zwraca oczekiwany wynik. Testy jednostkowe nadal są potrzebne, ale same nie wystarczą. Jeśli AI napisze je wyłącznie na podstawie istniejącego kodu, w testach utrwali się to, co już jest w implementacji, także błędy. Build przejdzie bez alarmu, a organizacja dostanie poczucie bezpieczeństwa bez realnej ochrony.
AI pomoże w pisaniu testów. Ale to ludzie po stronie biznesu i produktu muszą określić, co system ma robić, a czego nie.
Wymagaj solidnego CI/CD i zmieniaj formę code review
Przy AI w delivery CI/CD z automatycznymi kontrolami przestaje być „miłym dodatkiem”. Bez niego zespół nie nadąży za tempem zmian: ręcznie nie przerobi takiej ilości kodu.
Automatyzacja nie zastąpi jednak code review. Zmieni jego formę. W dobrze otestowanym systemie review skupi się na kompletności testów, logice i decyzjach architektonicznych. W legacy, bankowości oraz systemach regulowanych i krytycznych nadal będzie potrzebny głębszy przegląd zmian, a często także dodatkowe audyty.
Jak dobra architektura i dokumentacja poprawiają jakość kodu zgenerowanego przez AI
AI działa najlepiej, gdy dostaje małe, jednoznaczne zadanie i tylko ten kontekst, którego naprawdę potrzebuje. Ukryte zależności, splątane moduły i nieudokumentowane reguły zwiększają ryzyko, że lokalna zmiana wywoła błędy gdzie indziej. Poprawka w jednym miejscu potrafi wtedy wywrócić coś trzy katalogi dalej.
Czytelne granice między obszarami odpowiedzialności i mniejsze moduły ograniczają to ryzyko. AI nie musi wtedy przy każdej zmianie analizować całego codebase’u. Dobrze wydzielony zakres trzyma model w jednym kontekście, zamiast pozwalać mu domyślać się zależności poza zadaniem.
Dokumentacja reguł i decyzji to kontekst dla AI, nie formalność
Reguły biznesowe, wyjątki, kryteria akceptacji i decyzje architektoniczne powinny być zapisane, a nie trzymane wyłącznie w głowach zespołu. Bez tego AI odtworzy intencję tylko z kodu i uzupełni braki „na oko”. Ta sama dokumentacja przyspieszy też onboarding i zmniejszy zależność od wiedzy uwięzionej u pojedynczych osób.
W greenfieldzie takie warunki da się zbudować od razu. W klasycznym legacy zwykle najpierw trzeba ograniczyć złożoność, uzupełnić testy i uporządkować dokumentację. Gdy dług jest systemowy, a rozwój w starym kształcie staje się zbyt drogi, lepszym ruchem jest przepisanie od zera: z wiedzą o produkcie, ale na nowej architekturze.
Przez lata wielu ekspertów odradzało taki rewrite. Kent Beck, Robert C. Martin czy Martin Fowler powtarzali wprost: nie przepisuj systemu od zera. Ryzyko było ogromne, a korzyści niepewne. Dziś zmienia to AI: przy dobrej specyfikacji i modularnej architekturze pozwala wykonać rewrite w tempie, którego wcześniej nie brano pod uwagę. Przepisanie legacy nie jest już tak jednoznacznie złą decyzją jak kiedyś. Potrafi być szybsze i bezpieczniejsze niż dalsze łatanie starego kodu.
Dobrym przykładem jest Pragmatic Meet, nasz własny produkt. Stara wersja była typowym legacy i coraz trudniej było ją rozwijać. Zamiast dalej ją łatać, przepisaliśmy produkt od zera z AI: mniejszy kontekst, jasne granice modułów i spec-driven development. Na webinarze o tym przepisaniu pokazujemy, jak wyglądało to w praktyce.
Sprawdź, czy proces w organizacji jest gotowy na AI
Zanim ocenisz „jakość kodu z AI”, oceń proces, w którym ten kod powstaje.
- [ ] Czy user stories mają jasno opisany cel, kontekst biznesowy i kryteria akceptacji?
- [ ] Czy zespół poświęca na refinement istotnie więcej czasu niż przed wdrożeniem AI?
- [ ] Czy długość sprintu i częstotliwość review są dopasowane do tempa, w jakim zespół dowozi zmiany?
- [ ] Czy biznes wyrabia się z feedbackiem do zmian w produkcie, zanim zespół wdroży kolejne?
- [ ] Czy testy akceptacyjne, funkcjonalne, end-to-end i integracyjne chronią kluczowe ścieżki użytkownika?
- [ ] Czy każda zmiana kodu przechodzi przez CI/CD z automatycznymi kontrolami?
- [ ] Czy moduły mają czytelne granice, a reguły biznesowe i decyzje architektoniczne są udokumentowane?
Jeśli odpowiedzią na część z tych pytań jest „nie”, problemem nie jest model językowy. Luka leży w fundamentach pracy zespołu.
Co zrobić dalej
Żeby szybko zobaczyć, gdzie proces kuleje, sięgnij po AI Readiness Checklist. To 19 pytań „Tak/Nie” w czterech obszarach: procesy i kontekst biznesowy, fundamenty inżynierskie, standardy pracy z AI oraz sposób mierzenia efektów. Arkusz pokaże, gdzie AI realnie przyspieszy delivery, a gdzie tylko pogłębi chaos.
Gdy fundamenty są na miejscu, a budujesz nowy produkt, odpowiednio wdrożone AI realnie przyspieszy delivery bez strat na jakości. Przy systemach legacy sytuacja wygląda trochę inaczej. Tam często brakuje testów, dokumentacji i CI/CD, a zależności są splątane. Dokładanie AI w takich warunkach zwykle tylko przyspiesza narastanie długu technicznego. Ponadto koszt nadrobienia tych braków w starym systemie rzadko się zwraca, a czasem w ogóle nie da się ich sensownie uzupełnić. Wtedy warto rozważyć przepisanie systemu od zera zamiast dalszego łatania.
Podsumowanie
AI nie obniża jakości kodu samo z siebie. Pokazuje tylko, czy proces w organizacji wytrzyma szybsze kodowanie: czy wymagania są dopracowane, kontekst zapisany, testy automatyczne działają, a feedback nadąża za delivery. Bez tych fundamentów AI to tylko silnik napędzający wzrost chaosu.
