Kod gotowy na AI: dlaczego najpierw musi być gotowy proces

Dlaczego „gotowość na AI” tak naprawdę nie dotyczy twojego kodu

Jeden z naszych klientów postawił na AI w pracy projektowej na całego. Opisy zadań, projekty graficzne, materiały pomocnicze – generowane w ułamku czasu, który kiedyś zajmowały. Ta szybkość jest prawdziwa. Widziałem ją.

Widziałem też, gdzie ta szybkość się podziewa. Zadania trafiają do naszych programistów niekompletne, nieprecyzyjne, mylące. Programiści odsyłają je z pytaniami. Przychodzą odpowiedzi, wracają zadania, pojawiają się kolejne pytania. Mamy wrażenie, że to właśnie wtedy PM-owie po raz pierwszy dostrzegają problem – nie w chwili wygenerowania materiału, ale dwie, trzy rundy później, kiedy szybka część zdążyła już zamienić się w opóźnienia i koszty.

To nie jest opowieść o niekompetentnych ludziach. Wygenerowany materiał wygląda na skończony, a nawet najbardziej kompetentne osoby mogą przeoczyć szczegóły, które – przekazywane dalej w procesie – po cichu narastają w kosztowny problem. Wyobraź sobie oponę z tuzinem drobnych przebić. Na parkingu wygląda dobrze. Sprawdzasz ciśnienie – w porządku. Potem ruszasz i kilka kilometrów dalej stoisz przy kapciu.

To wzorzec, który warto nazwać. AI nie stworzyło problemów z jakością. Przesunęło moment, w którym się je odkrywa – dalej w procesie, w najdroższe miejsce.

Szybkość wzmacnia stan, w którym jesteś

Słabe dane wejściowe to nic nowego. Programiści odsyłają niejasne zgłoszenia, odkąd istnieją zgłoszenia. Nowa jest skala – i kamuflaż. Kiedy napisanie opisu zadania zajmowało godzinę, sam koszt wymuszał chwilę uwagi. Kiedy wygenerowanie zajmuje minutę, a wynik przychodzi dopracowany, słabość wędruje dalej. Odkrywa ją ten, kto musi na tej podstawie coś zbudować.

Skieruj AI na dobrze działający proces, a szybkość się zwielokrotni. Skieruj je na chaotyczny, a zwielokrotni się chaos – szybciej i w lepszym opakowaniu. Pytanie nie brzmi, dlaczego model się myli. Pytanie brzmi, w którym miejscu twojego procesu ktokolwiek by to zauważył.

Ten sam mechanizm, dwie warstwy. Warstwę procesu już widziałeś. Zejdźmy o poziom niżej.

Co naprawdę znaczy kod gotowy na AI

Kierujemy agenty AI na zagracone, nieudokumentowane bazy kodu – takie, jakie zwykle przejmujemy, gdzie nikt nie pamięta, po co istnieje połowa z nich. Agenty są dobre. Mapują strukturę, wyciągają na wierzch pytania o zależności, które warto zadać, szkicują plan wdrożenia. Nie potrafią natomiast ocenić tego planu. Nie wiedzą, czego nie wiedzą o twoim biznesie – który moduł po cichu dźwiga przychody, który skrót był decyzją, a który przypadkiem. Te decyzje musi podjąć człowiek, który rozumie system. O tym podziale pracy pisaliśmy w tekście o modernizacji kodu legacy z AI.

Kiedy więc ktoś pyta, czy jego kod jest gotowy na AI, uczciwa odpowiedź zaczyna się tutaj: dług techniczny to niejasne dane wejściowe, tylko o warstwę niżej. Kod ze splątanymi zależnościami i bez testów daje agentowi AI to samo, co chaotyczny opis zadania daje programiście – coś, co wygląda na wykonalne, a takie nie jest. Wynik się kompiluje, wygląda sensownie i rozsypuje się w zderzeniu z prawdziwymi ograniczeniami. Badanie GitClear mierzyło to jako code churn – linie cofnięte lub istotnie przerobione w ciągu dwóch tygodni od napisania – i wykazało, że wraz z upowszechnieniem się kodowania wspieranego przez AI wskaźnik ten mniej więcej się podwoił w porównaniu z okresem sprzed AI. Szybko na wejściu, drogo na wyjściu. Znowu ta opona.

Kod gotowy na AI to zatem taki, na którym agent może działać bez zgadywania: testy, które wyłapują zmiany zachowania, struktura, w której odnajdzie się nowa osoba, kontekst zapisany, a nie trzymany w pamięci. Warto go mieć. Ale to za mało. Czysty kod nie uratuje organizacji, która karmi AI niespójnym kontekstem – klient z początku tego tekstu nie potykał się o kod, zadania rozpadały się, zanim kod w ogóle pojawił się na horyzoncie. Dlatego naprawa nie zaczyna się od repozytorium.

Najpierw zrozumienie. Potem bramki.

Odruchowa odpowiedź to kontrole procesowe: przeglądaj wszystko, blokuj merge. Kontrole mają znaczenie – ale same w sobie są manometrem na przebitej oponie. Odczyt jest w porządku. Problem leży gdzie indziej.

Zanim z kimkolwiek porozmawiam o procesie, chcę zobaczyć, jak ludzie faktycznie pracują z tymi narzędziami. Nie jak zapowiadała prezentacja wdrożeniowa. Pytania, które mają znaczenie:

To jest diagnoza. Potem przychodzą bramki – jako monitoring, który podtrzymuje to, co ustaliła diagnoza. Najważniejsze są trzy: wejście (ktoś z doświadczeniem zatwierdza to, co trafia do AI, zanim cokolwiek zostanie wygenerowane), przegląd (wynik AI domyślnie traktowany jako niezaufany, bo pewnie brzmiący to nie to samo co poprawny) i merge (nic nie przechodzi bez osoby, która rozumie system).

Kolejność jest tu kluczowa. Ankieta Sonar State of Code pokazuje, dlaczego to pilne: programiści szacują, że 42% commitowanego przez nich kodu jest dziś generowane lub współtworzone przez AI, 96% nie ufa w pełni jego poprawności funkcjonalnej, a tylko 48% zawsze go sprawdza przed commitem. Jako branża generujemy więcej, niż rozumiemy i weryfikujemy. Ta luka nie daje o sobie znać. Ona narasta.

Pięć sygnałów, że AI przyspiesza twój chaos

Możesz to sprawdzić w tydzień, bez konsultanta:

1. Zadania i materiały wracają do autorów z pytaniami częściej niż przed AI.
2. Problemy z jakością odkrywa ten, kto wykonuje pracę, a nie ten, kto przygotował materiał.
3. Wyjaśnienie wygenerowanego materiału trwa dłużej, niż kiedyś trwało napisanie go od zera.
4. Ktoś odpowiada za jakość wyników. Nikt nie odpowiada za jakość danych wejściowych.
5. Przegląd wyników AI stał się formalnością, bo wszystko wygląda dobrze.

Trzy lub więcej – i AI wzmacnia twój chaos. To sygnał do pogłębionej analizy, a nie do kolejnego narzędzia ani do samych bramek.

Gotowość to stan, a nie zakup

Jeśli budżetujesz wdrożenie AI, pytanie nie brzmi, które narzędzie kupić. Pytanie brzmi, czy twoja organizacja jest w stanie, w którym szybkość AI przekłada się na wartość – czy właśnie kupujesz szybszą drogę do tego samego bałaganu, z fakturą przychodzącą dalej w procesie, tam, gdzie najtrudniej powiązać ją z przyczyną. Ta gotowość – praca w ramach transformacji AI, która dzieje się przed wyborem narzędzi – to część, na którą warto przeznaczyć budżet. Kod gotowy na AI jest częścią tego stanu. Ale nie całością.

Sprawdź, gdzie dziś w twoim procesie wychodzą na jaw problemy z jakością. Jeśli odpowiedź brzmi „na końcu”, napraw to w pierwszej kolejności – tam jest taniej niż w przesuniętych terminach. Wolę odbyć tę rozmowę przed wdrożeniem niż po fakturze.

Jeśli chcesz porozmawiać o tym, jak AI jest faktycznie używane w twojej organizacji – gdzie pomaga, a gdzie tylko przyspiesza problem