Zagrożenie skrzywieniem kontekstu przy weryfikacji kodu: dlaczego pojedynczy model AI utrwala własne błędy

Automatyzacja procesów inżynierii oprogramowania weszła w fazę, w której generowanie implementacji przez sztuczną inteligencję przestało być eksperymentem, a stało się elementem codziennego cyklu wytwórczego. Zjawisku temu towarzyszy jednak niebezpieczna pokusa architektoniczna: powierzenie weryfikacji i inspekcji zmian temu samemu silnikowi, który odpowiadał za ich wygenerowanie. W praktyce, gdy pojedynczy model AI pełni jednocześnie rolę autora pull requesta oraz jego recenzenta w ramach tej samej sesji lub rodziny wag, w procesie pojawia się zjawisko skrzywienia kontekstu (context poisoning). Zamiast niezależnego audytu dochodzi do utrwalania błędów logicznych, akceptowania niebezpiecznych założeń i rozrastania się nadmiarowego kodu źródłowego, którego żaden człowiek nie jest w stanie rzetelnie przeanalizować.

Kryzys procedury code review i brutalne zderzenie z SDLC

Problem zależności od maszynowych recenzji obnaża głębszy kryzys, który w branży IT narastał od lat. W odcinku podcastu Patoarchitekci zatytułowanym „Kto się podpisze pod kodem od AI? - SDLC, koszty i harness” prowadzący Szymon Warda i Łukasz Kałużny z firmy PROTOPIA zauważają, że generatory kodu niczego w gruncie rzeczy nie zepsuły – one jedynie bezlitośnie obnażyły wcześniejsze zaniedbania w procesie SDLC. Jak stwierdził wprost Szymon Warda: „Czy robiliśmy review lat temu trzy? Nie, nie robiliśmy, tylko wszyscy okłamywali się, że robią review porządnie i klikali: tak, tak, tak może iść”.

Przeniesienie tej powierzchownej akceptacji na narzędzia algorytmiczne prowadzi wprost do tworzenia tzw. AI slop factories oraz dark software factories – środowisk produkujących tysiące linii kodu pozbawionego nadzoru architektonicznego. Gdy programiści, zmęczeni zalewem syntetycznych zmian, zlecają wykonanie review instancji tego samego systemu, formalna kontrola jakości zamienia się w cyfrowy teatr pozorów.

Anatomia context poisoning i pułapka self-enhancement bias

Podatność na błędy poznawcze w systemach opartych na dużych modelach językowych wynika bezpośrednio z mechaniki ich działania. Skrzywienie kontekstu (context poisoning) nie jest atakiem na wagi bazowe w procesie treningu, lecz degradacją wnioskowania w czasie rzeczywistym. Jeżeli model w trakcie generowania rozwiązania przyjął błędne założenie, wprowadził niespójność typów lub wygenerował halucynację biblioteczną, wszystkie te elementy trafiają do bieżącego okna kontekstowego (context window). Przy próbie autorecenzji silnik traktuje historię konwersacji i wygenerowany wcześniej kod jako stan faktyczny (ground truth), budując kolejne argumenty na skażonym fundamencie.

Do tego dochodzi zjawisko zdefiniowane w badaniach nad ewaluacją maszynową jako self-enhancement bias (błąd auto-faworyzacji). Badania nad paradygmatem LLM-as-a-judge jednoznacznie wskazują, że sieci neuronowe wykazują statystyczną preferencję wobec treści wygenerowanych przez własną architekturę i własny zbiór wag. Model uważa własne konstrukcje syntaktyczne za bardziej naturalne, co drastycznie obniża wykrywalność subtelnych luk bezpieczeństwa. Równocześnie uaktywnia się verbosity bias – algorytm faworyzuje długie, przegadane struktury, nagradzając nadmierne skomplikowanie kodu zamiast promować zwięzłe idiomy projektowe. Towarzyszące modelom zjawisko pochlebstwa (sycophancy) sprawia ponadto, że weryfikator w pętli konwersacyjnej dąży do potwierdzenia intencji twórcy, zamiast bezwzględnie egzekwować niezmienniki logiczne.

Rachunek ekonomiczny i bariery infrastrukturalne

Próby obejścia problemu przez niekontrolowane mnożenie wywołań w ramach jednego ekosystemu generują olbrzymie koszty tokenów, które wcale nie przekładają się na wzrost stabilności oprogramowania. Z danych przytoczonych przez twórców podcastu Patoarchitekci wynika, że realne wydatki w zespole inżynieryjnym potrafią szybko wymknąć się spod kontroli:

• utrzymanie agentów dla inżyniera DevOps to wydatek rzędu 200–300 dolarów miesięcznie,
• wsparcie programisty przy złożonych zadaniach, takich jak migracja starego .NET-u, pochłania 500–600 dolarów na developera,
• standardowy miesięczny forecast budżetowy na czteroosobowy zespół programistyczny sięga 3000 euro,
• w skrajnych przypadkach braku nadzoru odnotowano pojedyncze incydenty z 13 tysiącami dolarów przepalonymi na kredyty narzędzia Copilot.

Nadzieje na tanie, lokalne weryfikowanie kodu również rozbijają się o twarde realia sprzętowe. Jak zauważa Łukasz Kałużny, „w tym momencie self-hosting to jest mit finansowy” – nawet zaawansowana stacja robocza Apple M5 Max ze 128 GB zunifikowanej pamięci osiąga przy pracy z potężnymi modelami zaledwie 30-parę tokenów na sekundę. Taka przepustowość eliminuje możliwość budowania responsywnych, wieloetapowych pętli weryfikacyjnych na maszynach deweloperskich.

Separacja ról: weryfikacja między dostawcami i bezwzględny harness

Aby skutecznie zneutralizować zagrożenie skrzywieniem kontekstu, inżynieria oprogramowania musi wdrożyć rygorystyczną zasadę separacji ról (separation of concerns). Podstawowym krokiem jest technika decoupled critique, w której model recenzujący otrzymuje wyłącznie „czysty” kod oraz formalne wymagania (tzw. Frozen Rubric), bez dostępu do historii przemyśleń i promptów autora kodu.

Drugim filarem bezpieczeństwa jest weryfikacja krzyżowa (cross-model verification). Jeśli implementację tworzy model jednego dostawcy, weryfikację semantyczną i wyszukiwanie podatności należy powierzyć modelowi pochodzącemu od zupełnie innego dostawcy, trenowanemu na odmiennym zbiorze danych i cechującemu się inną architekturą. Dopiero odmienna dystrybucja wag pozwala przełamać błąd auto-faworyzacji i zauważyć strukturalne ślepe plamki.

Sama wymiana modeli nie zastąpi jednak twardych reguł inżynieryjnych. W nowoczesnym procesie wytwórczym autonomiczni agenci kodujący nie mogą polegać wyłącznie na plikach Markdown czy promptach systemowych. W definicji przedstawionej przez Kałużnego „harness to config, którego agent nie ominie, nawet gdyby bardzo chciał”. Oznacza to powrót do klasycznych, bezwzględnych narzędzi: statycznej analizy kodu przez SonarQube, automatycznych testów architektonicznych weryfikujących diagramy C4, szybkiego środowiska kompilacji oraz metodyki lekkiego Spec-Driven Development zamiast przerośniętych standardów w stylu Spec Kit.

Kto ostatecznie podpisze się pod kodem?

Zagrożenie skrzywieniem kontekstu przypomina, że weryfikacja kodu przez sztuczną inteligencję nie jest procesem autonomicznym, lecz operacją wysokiego ryzyka. Pojedynczy model AI, uwięziony we własnym oknie kontekstowym i obciążony błędem auto-faworyzacji, zawsze będzie dążył do usprawiedliwienia wygenerowanego kodu. Odpowiedzialność prawna i zawodowa za wdrożenie zmian spoczywa wyłącznie na człowieku. Aby nie stać się bezwolnym podpisem pod niesprawdzonymi zmianami, inżynierowie muszą traktować higienę kontekstu i separację dostawców modeli z taką samą powagą, z jaką przez dekady traktowano izolację środowisk produkcyjnych.