Od pisania kodu ważniejsza jest dziś jego kontrola
AI przyspiesza pisanie kodu, ale nie obniża kosztu błędów. Sprawdź, jak kontrolować wymagania, bezpieczeństwo i utrzymanie.
AI obniża koszt stworzenia dedykowanego rozwiązania dla firmy, ale nie obniża kosztu błędnych wymagań ani wadliwego kodu.
Im szybciej powstaje kod, tym ważniejsze staje się sprawdzenie, czy pasuje do procesu, działa poprawnie, nie otwiera dostępu do danych i czy da się go zmienić za rok.
Szybkość przestała być problemem
Jeszcze niedawno pomysł na własny panel klienta, integrację z księgowością albo narzędzie dla zespołu kończył się zwykle pytaniem: „Ile będzie kosztował programista?”. Sam koszt pracy był barierą.
AI obniża tę barierę. Może przygotować szkielet aplikacji, napisać integrację, poprawić fragment istniejącego systemu albo napisać testy. W wielu przypadkach skraca pracę z dni do godzin.
Zmienia to ekonomię decyzji. Gdy stworzenie funkcji jest tańsze, firma zamawia ich więcej, częściej zmienia istniejące rozwiązania i szybciej mówi: „Spróbujmy”. Błędne założenie szybciej trafia więc do codziennej pracy firmy.
Gdy kod działa idealnie, ale biznes ponosi straty
Firma chce stworzyć system przypomnień o zaległych płatnościach. Zadanie brzmi rozsądnie: „Każdego ranka wysyłamy wiadomość do klienta, który nie zapłacił faktury w terminie”.
AI pomaga przygotować integrację z systemem księgowym i mechanizm wysyłki e-maili. Programista uruchamia test:
- system znajduje fakturę po terminie,
- tworzy wiadomość,
- wysyła ją na właściwy adres.
Z technicznego punktu widzenia wszystko działa.
Po tygodniu okazuje się, że część wpłat trafia na konto, zanim zostaną zaksięgowane w systemie finansowym. Automatyzacja widzi więc zaległość, choć klient faktycznie zapłacił. System wysyła ponaglenie. Sfrustrowany klient odsyła potwierdzenie przelewu. Opiekun klienta przeprasza, a księgowość w pośpiechu szuka przyczyny.
Kod wykonał dokładnie to, co mu zlecono. Architektura automatyzacji nie uwzględniała jednak różnicy między sytuacją, w której „faktura nie ma jeszcze statusu opłaconej w systemie”, a sytuacją, w której „firma rzeczywiście nie otrzymała pieniędzy”.
Nie zawiodła składnia kodu, lecz logika całego procesu. W wymaganiach zabrakło reguł dotyczących płatności zaksięgowanych z opóźnieniem, wpłat częściowych, korekt, indywidualnych terminów płatności i postępowań reklamacyjnych.
AI nie wymyśli tych wyjątków z niczego. Może zaproponować standardowe scenariusze, ale nie zna specyfiki pracy Twojej księgowości ani nieformalnych ustaleń z konkretnym klientem.
Błędne wymaganie ma dziś krótszą drogę do szkody
Dawniej zły pomysł mógł czekać miesiąc na realizację. W tym czasie ktoś czasem dostrzegał problem. Nie z powodu szczególnej dojrzałości organizacyjnej, lecz dlatego, że było więcej czasu na zawahanie.
Dziś AI może dostarczyć pierwszą działającą wersję tego samego pomysłu jeszcze tego samego dnia. To świetne dla dobrego wymagania. Dla złego działa równie sprawnie.
Firma łatwo myli dwie rzeczy: „system robi to, co powiedzieliśmy” oraz „system robi to, czego naprawdę potrzebujemy”. Między nimi mieści się lista wyjątków, danych, nietypowych klientów i sytuacji, które normalnie rozwiązujesz telefonem lub ręczną decyzją.
Jeżeli ten obszar nie zostanie opisany, kod przejmie jedynie prostą regułę. Reszta pozostanie w głowach ludzi. System bez wiedzy o wyjątkach potrafi psuć relacje.
Vibe Coding kończy się tam, gdzie zaczyna się firma
Vibe Coding to budowanie rozwiązania za pomocą kolejnych poleceń dla AI: „dodaj formularz”, „połącz z CRM-em”, „napraw błąd”, „dodaj panel”. Kod powstaje szybko, więc łatwo uznać, że problem został rozwiązany.
Taki sposób pracy bywa wystarczający przy prostym prototypie albo skrypcie działającym na kopii danych. Kłopot zaczyna się, gdy kod trafia do firmy i dotyczy klientów, płatności, danych lub dostępu do systemów.
Wtedy „działa u mnie” przestaje być kryterium. Firma musi wiedzieć, jak kod obsługuje błędy, kto zatwierdził jego wdrożenie, do jakich systemów ma dostęp i kto naprawi go po pierwszej zmianie procesu.
Vibe Coding nie jest problemem dlatego, że używa AI. Problem pojawia się, gdy zamiast brać odpowiedzialność za produkt, definiować wymagania i pisać testy, zdajemy się na serię coraz bardziej szczegółowych promptów. AI może szybko tworzyć kod, ale nie odpowiada za skutki jego działania.
Czy kod w ogóle powinien powstać
AI obniża koszt stworzenia własnego rozwiązania. Nie znaczy to jednak, że firma powinna tworzyć własne rozwiązanie dla każdego problemu.
Własny CRM brzmi kusząco, gdy gotowe narzędzie nie pasuje idealnie do sposobu pracy zespołu. CRM to jednak nie tylko ekran z klientami i listą zadań. To także uprawnienia, historia kontaktu, import danych, raporty, integracje, kopie zapasowe, aktualizacje, bezpieczeństwo oraz lata poprawek, których nikt nie dostrzega, dopóki czegoś nie zabraknie.
Jeżeli gotowy CRM obsługuje 80 albo 90 procent procesu, pisanie całego systemu od zera tylko po to, by dopasować pozostały fragment, bywa kosztowną ambicją. Firma nie kupuje wtedy przewagi. Bierze na siebie utrzymanie problemów, które ktoś inny rozwiązuje i poprawia od lat.
Dedykowany kod ma sens tam, gdzie proces rzeczywiście odróżnia firmę od konkurencji, gotowe narzędzia nie obsługują istotnej reguły albo integracja między sprawdzonymi systemami daje efekt bez budowy całej aplikacji.
Pierwsze pytanie brzmi:
Czy potrzebujemy własnego kodu, czy rozsądniej użyć gotowego narzędzia?
Dopiero po tej decyzji zaczyna się rozmowa o wymaganiach, bezpieczeństwie, poprawności i utrzymaniu.
Kontrola kodu to nie jedno sprawdzenie
Słowo „kontrola” brzmi jak kolejny etap spowalniający projekt. Chodzi jednak o cztery różne pytania. Pominięcie każdego z nich prowadzi do innego rodzaju problemu.
Wymaganie ma być opisem decyzji, nie życzeniem
„Zbuduj panel dla klientów” nie jest wymaganiem. „Połącz nam CRM z księgowością” również nim nie jest. To nazwy problemów, z którymi ktoś dopiero musi się zmierzyć.
Wymaganie zaczyna się wtedy, gdy firma potrafi opisać zdarzenie uruchamiające, dane wejściowe, regułę decyzji, wyjątki, oczekiwany wynik i osobę odpowiedzialną za odbiór.
W systemie przypomnień o płatnościach reguła „wyślij e-mail trzy dni po terminie” nie wystarcza. Potrzebna jest też odpowiedź na pytanie, co system robi z wpłatą niezaksięgowaną, korektą faktury, klientem objętym reklamacją oraz błędem połączenia z księgowością.
To są kryteria odbioru. Mówią, po czym firma pozna, że rozwiązanie nadaje się do użycia. Bez nich wykonawca może dostarczyć kod zgodny z ogólnym poleceniem, a firma nie ma uczciwego sposobu, by stwierdzić, że wynik jest niepełny.
Test kodu nie jest testem firmy
Test techniczny odpowiada na pytanie: „Czy kod robi to, co opisano?”. Może sprawdzić, czy system wyśle wiadomość, gdy faktura ma status zaległej, oraz czy nie wyśle jej, gdy status jest opłacony.
Nie odpowie sam z siebie na pytanie: „Czy status w systemie księgowym rzeczywiście oznacza sytuację finansową klienta?”.
Można mieć świetnie przetestowany kod, który wykonuje złą regułę. To zwykły skutek zamiany niepełnej wiedzy o procesie na precyzyjne instrukcje.
Odbiór biznesowy powinien opierać się na prawdziwych przypadkach. Nie na jednym idealnym rekordzie przygotowanym na pokaz, lecz na zaległości, płatności częściowej, kliencie z innym terminem, błędnej kwocie, awarii integracji i danych, które dotarły za późno.
Najprostsza ochrona to tryb podglądu. System przez pewien czas tworzy listę działań, ale ich nie wykonuje. Osoba znająca proces porównuje wynik z rzeczywistością. Gdy lista jest poprawna także wtedy, gdy sytuacja staje się nieprzyjemna, kod może zacząć działać samodzielnie.
Ekran nie mówi, co dzieje się pod spodem
Widok „wysłano wiadomość” nie ujawnia, czy system ma dostęp do całej skrzynki, czy jedynie do funkcji wysyłki. Nie pokazuje też, czy hasło do integracji znajduje się w kodzie ani czy ktoś będzie mógł je zmienić bez przebudowy systemu.
Bezpieczeństwo zaczyna się przed uruchomieniem:
- jakie dane rozwiązanie widzi,
- jakie może zmieniać,
- gdzie przechowuje dostęp,
- co się stanie, gdy ktoś zdobędzie jego token.
System do przypomnień o płatnościach nie potrzebuje uprawnienia do kasowania dokumentów na dysku firmy. Integracja odczytująca status faktury nie potrzebuje pełnego konta administratora w księgowości. Każdy nadmiarowy dostęp zwiększa zasięg błędu.
OpenSSF ostrzega, że asystenci kodowania mogą wprowadzać przestarzałe zależności , pomijać obsługę błędów lub ujawniać sekrety. Zaleca nie umieszczać haseł, kluczy API ani innych sekretów w kodzie oraz korzystać z bezpiecznych mechanizmów przechowywania dostępu.
Kod też może się zepsuć po wdrożeniu
System nie przestaje być ryzykowny w chwili, gdy przechodzi test. Zewnętrzne API zmienia format danych. Ktoś zmienia zasady pracy zespołu. Klient zaczyna korzystać z procesu w sposób, którego nikt nie przewidział.
Rozwiązanie potrzebuje śladu po swoich działaniach. Nie chodzi o stertę technicznych raportów, których nikt nie czyta. Chodzi o możliwość odpowiedzi na proste pytania: co system zrobił, kiedy to zrobił, na podstawie jakich danych i gdzie wystąpił błąd.
Przy zmianach dotyczących klientów, płatności albo danych potrzebny jest też prosty wyłącznik. Jeśli system zaczyna zachowywać się źle, firma musi umieć go zatrzymać bez czekania na programistę, który jest akurat w samolocie, na urlopie albo po prostu nie odbiera.
Równie istotna jest możliwość cofnięcia zmiany. Kod, który aktualizuje rekordy, powinien umożliwiać powrót do wcześniejszego stanu albo najpierw działać na kopii danych. W przeciwnym razie „szybka poprawka” bywa szybką metodą na pomyłkę.
AI może pomagać w kontroli, ale nie może być swoim audytorem
AI nie może być jedynym recenzentem własnej pracy. Model może wygenerować kod, a następnie z przekonaniem stwierdzić, że jest on świetny. To bardzo wygodne.
Jeśli AI wygenerowała kod, drugi model może pomóc w jego sprawdzeniu. Świeży kontekst i odmienny sposób rozumowania zwiększają szansę na zauważenie pominiętego przypadku, błędnego założenia albo podejrzanej zależności.
Nie traktuj jednak drugiego modelu jak niezależnego audytora. Dwa modele mogą zgodnie przeoczyć ten sam problem, zwłaszcza gdy oba otrzymały niepełne wymagania. Niezależność zapewnia dopiero połączenie innego modelu, testów oraz człowieka odpowiedzialnego za podjęcie decyzji.
Korzystaj z AI, aby przyspieszyć sprawdzanie, ale zachowaj niezależny punkt kontroli.
Vendor Lock-In, czyli jak nie stać się zakładnikiem własnego kodu
Zmieni się oferta firmy, sposób pracy ludzi albo wykonawca. Kod będzie wymagał zmian, nawet jeśli dziś wygląda na skończony.
Firma musi mieć dostęp do kodu, historii zmian i środowiska, w którym rozwiązanie działa. Potrzebuje też krótkiego opisu:
- skąd system bierze dane,
- z czym się łączy,
- jak wdrożyć poprawkę,
- kto ma dostęp.
Jeśli po odejściu wykonawcy nikt nie potrafi zmienić rozwiązania bez budowy wszystkiego od nowa, firma nie kupiła narzędzia, tylko zależność od kogoś innego.
Utrzymywalność oznacza, że kolejna osoba z odpowiednimi umiejętnościami może zrozumieć system, zmienić go i nie uszkodzić przy tym reszty firmy.
Nie każda zmiana zasługuje na ciężką procedurę
Skrypt, który na kopii folderu porządkuje nazwy plików, można sprawdzić przez porównanie kilku wyników. Jeśli coś pójdzie źle, zmiany da się odwrócić w kilka minut.
W takim przypadku pełny przegląd bezpieczeństwa, rozbudowany odbiór i dokumentacja dla przyszłych pokoleń byłyby droższe niż sam błąd. AI może wtedy obniżyć całkowity koszt zadania, także koszt ewentualnej poprawki.
Inaczej wygląda kod, który wysyła wiadomości do klientów, przetwarza dane osobowe, zmienia płatności, nadaje uprawnienia albo modyfikuje dane w systemie firmy. Im większy zasięg, im trudniej odwrócić skutek i im bliżej pieniędzy lub danych, tym silniejsza powinna być kontrola.
Granica nie przebiega między „kodem z AI” a „kodem bez AI”. Przebiega między zmianą odwracalną a zmianą, która może samodzielnie wyrządzić szkody.
Cztery błędy, które wyglądają jak oszczędność
- Zaczynanie od rozwiązania. Firma mówi: „Potrzebujemy aplikacji”, zanim opisze decyzje i wyjątki, które aplikacja ma obsłużyć. Potem dziwi się, że system rozwiązuje jedynie prostą wersję problemu.
- Odbiór po prezentacji. Widok jednej poprawnej ścieżki nie jest dowodem, że kod poradzi sobie z prawdziwymi danymi. Jest tylko dowodem, że ktoś przygotował jedną poprawną ścieżkę.
- Przekazanie AI lub wykonawcy wszystkich dostępów „żeby działało”. Przyspiesza to start, ale zwiększa koszt każdego późniejszego błędu. Dostęp ma być wystarczający, a nie szeroki z rozpędu.
- Brak własności rozwiązania. Kod w prywatnym repozytorium wykonawcy, konto chmurowe przypisane do jego adresu oraz brak opisu integracji to przepis na kosztowną zależność. Nie widać jej w pierwszym miesiącu. Widać ją, gdy trzeba coś zmienić.
Zadaj sześć pytań, zanim coś zbudujesz
Przed rozpoczęciem pracy nad dedykowanym rozwiązaniem poproś o odpowiedzi na sześć pytań:
- Co dokładnie uruchamia proces?
- Z jakich danych korzysta kod?
- Jakie decyzje podejmuje sam, a jakie zostawia człowiekowi?
- Jakie wyjątki i błędy są przewidziane?
- Po czym firma odbierze rozwiązanie jako poprawne?
- Kto ma kod, dostępy i możliwość zatrzymania systemu?
Po zbudowaniu rozwiązania przychodzą cztery inne pytania:
- Czy działa ono na prawdziwych przypadkach?
- Czy dostęp jest ograniczony?
- Czy działania można prześledzić?
- Czy inny wykonawca potrafi je przejąć?
To krótka droga do uniknięcia sytuacji, w której AI pomogła szybko zbudować problem, a firma płaci później za jego usuwanie wolniejszą, ręczną metodą.
FAQ
Czy AI może stworzyć bezpieczny kod dla firmy?
Może pomóc go stworzyć, ale bezpieczeństwo zależy od wymagań, przeglądu, testów, użytych zależności i dostępu do danych. Sam fakt, że kod powstał z pomocą AI, niczego nie gwarantuje.
Czy testy automatyczne wystarczą?
Nie. Testy sprawdzają zachowanie kodu według zapisanych scenariuszy. Nie odkryją samodzielnie, że firma pominęła wyjątek albo błędnie opisała swoją regułę.
Czy każda funkcja z AI wymaga pełnego audytu?
Nie. Zakres kontroli zależy od zasięgu działania, możliwości cofnięcia błędu i rodzaju danych. Mały, odwracalny skrypt wymaga mniej sprawdzenia niż kod pracujący na klientach, płatnościach lub uprawnieniach.
Czy AI może też sprawdzać kod?
Tak. Może pomagać tworzyć testy, wyjaśniać kod i wskazywać podejrzane miejsca. Nie zastępuje jednak niezależnego przeglądu ani odpowiedzialności osoby, która zatwierdza wdrożenie.
