Wstęp
Kilka tygodni temu rozmawiałem z CTO średniej wielkości sklepu e-commerce. Narzekał, że od kiedy zespół zaczął używać asystentów AI do generowania kodu, przybyło błędów w produkcji. – „Dziwne, bo kod wygląda dobrze, a testy przechodzą” – mówił. Problem w tym, że wygląd i testy jednostkowe nie wychwytują subtelnych problemów: złej architektury, braku skalowalności czy luk bezpieczeństwa.
AI w programowaniu to dar, ale i przekleństwo – jeśli używasz go bez głowy. W tym artykule pokażę trzy realne pułapki, które widzę u klientów i w projektach open source. Nie czarujmy się: modele językowe nie myślą, one przewidują kolejne tokeny. A my – programiści i CTO – zbyt często zapominamy o tym podstawowym fakcie.
1. Pułapka pozornej poprawności: kod, który wygląda dobrze, ale jest kruchy
Wygenerujesz funkcję w Node.js. Działa na pierwszy rzut oka. Testy przechodzą. Wrzucasz na produkcję. Po tygodniu serwer pada, bo kod nie obsługuje błędu sieci. AI nie wygenerowało obsługi wyjątków, bo w treningowym zbiorze rzadko występują takie przypadki. Ty zaufałeś, że model „wie, co robi”.
Realny przykład: W projekcie klienta z branży fintech zespół użył ChatGPT do napisania modułu płatności. Kod działał dla 90% przypadków. Przy obciążeniu 10k transakcji na minutę okazało się, że brakuje timeoutów – połączenia do API banku wisiały, aż serwer się zapchał. Straty? Około 30 tysięcy złotych w jeden dzień.
Lekcja: Model generuje średnią. Nie testuje skrajnych przypadków. Nie myśli o architekturze. Twoja odpowiedzialność to zawsze przeglądać kod pod kątem edge casów, przeciążeń i bezpieczeństwa. Nie polegaj na tym, że „AI napisało, więc jest ok”.
2. Pułapka braku kontekstu biznesowego: AI nie zna Twojego domain model
Kiedy prosisz AI o napisanie kodu, podajesz prompt. Ale prompt nie oddaje całego kontekstu: specyfiki domeny, reguł biznesowych, niuansów, które zespół wypracował przez lata. Model generuje coś, co jest poprawne składniowo, ale często niezgodne z logiką biznesową.
Realny przykład: Klient z branży logistycznej poprosił AI o wygenerowanie mechanizmu wyceny przesyłek. Model stworzył algorytm oparty na odległości geograficznej, ale firma wyceniała według stref wagowych i priorytetów. Kod został wdrożony – i przez dwa dni klienci dostawali błędne faktury. Zanim się zorientowali, stracili zaufanie kilku kluczowych kontrahentów.
Lekcja: AI nie zastąpi znajomości domeny. Używaj go do szkieletów, ale logikę biznesową zawsze pisz samodzielnie albo dogłębnie weryfikuj. Jako CTO lub tech lead musisz egzekwować, że każdy fragment wygenerowany przez model jest rozumiany przez człowieka.
3. Pułapka zaniechania przeglądów: kiedy „AI to napisało” zwalnia z odpowiedzialności
Najczęstszy błąd, jaki widzę: zespoły przestają robić code review, bo „kod wygląda dobrze”. Albo robią pobieżnie, bo wierzą, że model nie popełnia głupich błędów. A to nieprawda. Modele językowe mają tendencję do generowania fragmentów, które są poprawne lokalnie, ale psują globalną spójność – np. używają różnych konwencji nazewnictwa, powielają logikę czy wprowadzają martwy kod.
Realny przykład: W startupie SaaS zespół używał GitHub Copilot. Jeden z deweloperów wygenerował funkcję do walidacji emaili. Funkcja działała, ale nie była zintegrowana z istniejącą biblioteką walidacyjną. Po dwóch miesiącach okazało się, że w systemie są dwie różne implementacje walidacji, jedna z nich nie obsługuje nowych domen. Koszt: dwa dni pracy na refaktoring i stracone zaufanie użytkowników, którzy dostawali fałszywe błędy.
Lekcja: Code review nie znika. Wręcz przeciwnie – staje się ważniejsze, bo musisz wychwycić nie tylko błędy ludzkie, ale też „błędy maszynowe”. Nie skracaj procesu przeglądu. Wprowadź zasadę: każdy commit z udziałem AI musi być oznaczony i recenzowany podwójnie.
Podsumowanie
AI w programowaniu to potężne narzędzie – ale narzędzie, nie zastępstwo myślenia. Traktuj je jak stażystę: generuje szybko, ale wymaga nadzoru. Firmy, które zapominają o kontekście biznesowym, przestają robić code review i ślepo ufają modelom, prędzej czy później zapłacą rachunek.
Co robić?
- Wprowadź standardy korzystania z AI w zespole.
- Używaj narzędzi do analizy kodu (lintery, Snyk, SonarQube) na każdym commitcie.
- Ucz zespół krytycznego myślenia – niech AI będzie wsparciem, a nie panem.
W JurskiTech pomagamy firmom wdrażać AI w sposób odpowiedzialny. Nie chodzi o to, żeby nie używać nowych technologii – chodzi o to, żeby robić to z głową. A Wy? Jakie macie doświadczenia z asystentami programistycznymi? Dajcie znać w komentarzach.
