{dev} forge – Kto odpowiada za kod generowany przez AI?

AI coding assistants zmieniły sposób, w jaki powstaje software. Kod, który kiedyś był efektem godzin pracy developera, dziś może powstać w kilka minut. Prompt, kilka iteracji i gotowe. Szybkość robi wrażenie. Problem w tym, że wraz z tą zmianą pojawia się pytanie, które wielu zespołów jeszcze nie zadaje wystarczająco głośno:

kto odpowiada za kod generowany przez AI?

To nie jest pytanie filozoficzne. To jest pytanie bardzo praktyczne. Dotyczy jakości, bezpieczeństwa, odpowiedzialności prawnej i – co najważniejsze – odpowiedzialności inżynierskiej.

W świecie, w którym kod powstaje coraz częściej przy udziale modeli językowych, nie możemy pozwolić sobie na brak jasnej odpowiedzi.

Mit: „AI wygenerowało, więc to nie moja odpowiedzialność”

Jednym z najbardziej niebezpiecznych mitów, jakie pojawiły się wraz z popularyzacją AI, jest przekonanie, że skoro kod został wygenerowany przez model, to odpowiedzialność za jego jakość jest „rozmyta”.

To bardzo wygodna narracja. Ale całkowicie nieprawdziwa.

AI nie jest członkiem zespołu. Nie bierze odpowiedzialności. Nie podpisuje się pod commitami w sensie inżynierskim. Nie odpowiada przed klientem, audytem ani produkcją.

AI jest narzędziem. Bardzo zaawansowanym, ale nadal narzędziem.

A odpowiedzialność za efekt użycia narzędzia zawsze pozostaje po stronie człowieka i organizacji.

To nie pierwszy raz w historii

Warto zauważyć, że to nie jest zupełnie nowy problem. Historia software engineeringu zna już podobne momenty.

Kiedy pojawiły się frameworki, biblioteki open source, code generators czy low-code platforms, również pojawiało się pytanie: kto odpowiada za kod, którego nie napisaliśmy w 100% sami?

Odpowiedź zawsze była taka sama:

odpowiada ten, kto decyduje o użyciu i wdrożeniu.

To, że nie napisałeś każdej linijki ręcznie, nie zwalnia Cię z odpowiedzialności za system, który trafia na produkcję.

AI tylko podnosi stawkę, bo zwiększa skalę i tempo generowania kodu.

Problem numer jeden: iluzja poprawności

Jednym z największych zagrożeń przy pracy z AI jest to, że generowany kod wygląda poprawnie.

Ma sensowną strukturę. Kompiluje się. Często przechodzi nawet podstawowe testy. Komentarze brzmią przekonująco. Nazwy są logiczne. Wszystko sprawia wrażenie profesjonalne.

Ale „wygląda poprawnie” to nie to samo, co „jest poprawne”.

Model nie rozumie Twojego systemu w taki sposób, jak robi to doświadczony inżynier. Nie zna wszystkich kontekstów biznesowych. Nie zna ograniczeń infrastrukturalnych. Nie zna kompromisów, które zostały wcześniej podjęte.

W rezultacie może wygenerować rozwiązanie, które:

• łamie reguły domenowe,
• narusza założenia architektury,
• wprowadza subtelne błędy logiczne,
• nie spełnia wymagań niefunkcjonalnych,
• jest podatne na problemy bezpieczeństwa.

I to wszystko bez żadnego ostrzeżenia.

Problem numer dwa: brak świadomości decyzji

Kiedy developer pisze kod ręcznie, podejmuje serię mikrodecyzji. Każda linijka ma swoje uzasadnienie. Każda konstrukcja wynika z jakiejś intencji.

W przypadku kodu generowanego przez AI część tych decyzji jest ukryta. Model generuje rozwiązanie, ale nie zawsze jasno komunikuje, dlaczego wybrał właśnie takie podejście.

To prowadzi do bardzo niebezpiecznej sytuacji:

zespół zaczyna utrzymywać kod, którego w pełni nie rozumie.

A utrzymywanie kodu bez zrozumienia to prosta droga do problemów.

Problem numer trzy: odpowiedzialność rozproszona

W klasycznym modelu developmentu odpowiedzialność jest względnie jasna. Wiemy, kto implementował feature, kto go reviewował, kto zatwierdził wdrożenie.

W modelu opartym o AI bardzo łatwo tę odpowiedzialność rozmyć:

• „AI to wygenerowało”
• „to było tylko sugestią”
• „nie zmieniałem tego, bo wyglądało dobrze”

Jeśli zespół nie zdefiniuje jasno zasad pracy z AI, bardzo szybko może dojść do sytuacji, w której nikt nie czuje się właścicielem kodu.

A brak właściciela to brak jakości.

Jak powinna wyglądać odpowiedzialność w erze AI?

Moim zdaniem odpowiedź jest prostsza, niż się wydaje:

odpowiedzialność się nie zmienia. Zmieniają się narzędzia.

To nadal:

• developer odpowiada za kod, który commitował,
• reviewer odpowiada za code review,
• architekt odpowiada za spójność systemu,
• organizacja odpowiada za to, co trafia na produkcję.

AI nie znosi tych ról. Ono tylko zmienia sposób, w jaki wykonujemy pracę.

Nowa kompetencja: AI Code Review

Wraz z AI pojawia się nowa, bardzo ważna kompetencja: umiejętność reviewowania kodu generowanego przez model.

To nie jest dokładnie to samo, co klasyczny code review. Trzeba nauczyć się patrzeć na kod trochę inaczej.

Na co zwracać uwagę?

• Czy rozwiązanie jest zgodne z architekturą systemu?
• Czy nie wprowadza ukrytych założeń?
• Czy obsługuje edge case’y?
• Czy nie „overengineeruje” problemu?
• Czy nie pomija ważnych aspektów (np. bezpieczeństwa, walidacji, logowania)?

AI potrafi być bardzo przekonujące. Dlatego review musi być jeszcze bardziej świadome.

Rola Spec-Driven Development

I tutaj wracamy do jednego z głównych tematów tej serii.

Jeśli chcemy realnie zarządzać odpowiedzialnością za kod generowany przez AI, potrzebujemy stabilnego punktu odniesienia. Czegoś, co pozwala jasno powiedzieć:

„to jest poprawne, a to nie”.

Właśnie tę rolę pełni specyfikacja.

W podejściu spec-driven:

• AI nie „zgaduje” rozwiązania, tylko realizuje spec,
• kod można walidować względem scenariuszy i kontraktów,
• odpowiedzialność jest powiązana z artefaktami, a nie rozmową,
• łatwiej przeprowadzić audyt i analizę decyzji.

To nie eliminuje potrzeby myślenia. Ale znacząco zmniejsza ryzyko chaosu.

Najważniejsza zasada

Jeśli miałbym sprowadzić cały temat do jednej zasady, brzmiałaby ona tak:

Jeśli wrzucasz kod na produkcję, bierzesz za niego odpowiedzialność – niezależnie od tego, czy napisałeś go sam, czy wygenerowało go AI.

To podejście jest brutalnie proste. Ale właśnie dlatego działa.

Podsumowanie

AI zmienia sposób, w jaki tworzymy software. Przyspiesza development, obniża barierę wejścia i pozwala realizować pomysły szybciej niż kiedykolwiek wcześniej.

Ale nie zmienia jednego:

odpowiedzialności za system.

Nie możemy traktować AI jako wymówki. Nie możemy zrzucać na nie decyzji. Nie możemy zakładać, że skoro coś zostało wygenerowane, to jest automatycznie poprawne.

W erze AI dobry inżynier to nie ten, kto pisze najwięcej kodu. To ten, kto potrafi ocenić, który kod powinien istnieć.

A do tego potrzebujemy nie tylko promptów, ale przede wszystkim dobrze zbudowanych specyfikacji.