Wstęp
Sztuczna inteligencja w kodzie to gorący temat – od GitHub Copilota po ChatGPT, narzędzia AI obiecują przyspieszenie pracy i redukcję błędów. I rzeczywiście, w wielu przypadkach automatyzacja pomaga. Ale jako praktyk, który widział, jak AI potrafi napsuć krwi, powiem wprost: są sytuacje, w których ręczna interwencja doświadczonego developera jest nie tylko lepsza, ale wręcz konieczna. W tym artykule pokażę trzy konkretne scenariusze, gdzie automatyzacja zawodzi, a ludzki osąd ratuje projekt.
1. Debugowanie złożonych błędów – gdy AI widzi tylko wzorce, a nie kontekst
AI doskonale radzi sobie z prostymi błędami składniowymi czy typowymi wyjątkami. Ale gdy w grę wchodzi logika biznesowa rozłożona na kilka serwisów, timing, stany współbieżne – AI często generuje rozwiązania, które wyglądają dobrze, ale są błędne.
Przykład z życia:
Pracowałem nad aplikacją e-commerce, w której zamówienia znikały po 30 minutach. AI (ChatGPT) wskazało błąd w funkcji removeExpiredOrders i zaproponowało poprawkę. Wyglądało to logicznie – usuwało wpisy starsze niż 30 minut. Problem w tym, że nie uwzględniło kontekstu: zamówienia miały status „oczekujące” i nie powinny być usuwane, dopóki nie minie 30 minut od ostatniej modyfikacji. AI nie zrozumiało, że created_at to nie to samo co updated_at. Ręczna analiza kodu i znajomość domeny ujawniły, że błąd leży w indeksie bazy danych i synchronizacji z cache’em.
Dlaczego AI zawodzi?
- Nie rozumie domeny – nie wie, co jest ważne biznesowo.
- Opiera się na statystykach – wybiera najczęściej występujący wzorzec, a nie ten właściwy.
- Nie ma dostępu do pełnego kontekstu systemu (np. logów, metryk, stanu aplikacji).
Kiedy ręcznie: Zawsze przy błędach produkcyjnych, które wydają się nielogiczne. Zacznij od analizy logów i metryk, zanim sięgniesz po AI. Często rozwiązanie jest proste, ale wymaga zrozumienia przepływu danych.
2. Optymalizacja wydajności – AI nie zna Twojej architektury
Automatyczne narzędzia do optymalizacji kodu, jak AI sugerujące refaktoryzację, mogą wyrządzić więcej szkody niż pożytku. Typowy przykład: proponują zmianę pętli na bardziej „wydajną” konstrukcję, ale nie biorą pod uwagę specyfiki bazy danych, sieci, czy użycia pamięci.
Przykład z życia:
W projekcie SaaS do zarządzania projektami, AI zasugerowało zastąpienie pętli forEach na map z Promise.all, aby przyspieszyć pobieranie danych z API. Teoretycznie słuszne – równoległe zapytania. Ale w praktyce API zewnętrzne miało limit 5 zapytań na sekundę, a lista zawierała 100 elementów. Promise.all wysłało 100 zapytań naraz, co skończyło się błędami 429 i blokadą IP. Ręczna implementacja z p-limit lub kolejką była bezpieczniejsza.
Dlaczego AI zawodzi?
- Nie zna ograniczeń infrastruktury (limity API, wydajność bazy, przepustowość sieci).
- Optymalizuje lokalnie, nie globalnie – poprawia wydajność jednej funkcji kosztem innej.
- Nie testuje hipotez – sugeruje zmianę bez dowodu, że będzie lepiej.
Kiedy ręcznie: Zawsze, gdy optymalizacja dotyczy krytycznej ścieżki. Wykonaj profilowanie, zidentyfikuj wąskie gardło, a dopiero potem rozważ sugestie AI jako jedną z opcji. Zaufaj własnym testom obciążeniowym.
3. Pisanie kodu krytycznego dla bezpieczeństwa – AI nie myśli jak atakujący
Bezpieczeństwo to obszar, w którym AI może być szczególnie niebezpieczne. Narzędzia generujące kod często pomijają walidację danych wejściowych, autoryzację czy ochronę przed injection. Albo – co gorsza – generują kod, który wygląda bezpiecznie, ale zawiera subtelne luki.
Przykład z życia:
Poprosiłem AI o napisanie funkcji resetowania hasła. Otrzymałem kod z tokenem generowanym przez Math.random(), który nie jest kryptograficznie bezpieczny. AI nie ostrzegło, że taka implementacja jest podatna na ataki brute-force. Ręczna implementacja z użyciem crypto.randomBytes jest standardem, ale AI często wybiera prostsze rozwiązanie.
Dlaczego AI zawodzi?
- Nie ma świadomości zagrożeń – nie wie, co to jest atak CSRF, XSS, czy timing attack.
- Bazuje na przeciętnych praktykach – a w bezpieczeństwie przeciętność to porażka.
- Nie audytuje kodu pod kątem OWASP Top 10 – generuje kod, który działa, ale nie jest bezpieczny.
Kiedy ręcznie: Zawsze przy funkcjach związanych z autoryzacją, uwierzytelnianiem, przetwarzaniem płatności, danymi osobowymi. Użyj AI jako asystenta do generowania szkieletu, ale każdą linię przejrzyj pod kątem bezpieczeństwa. Warto też przeprowadzić code review z innym developerem.
Podsumowanie
AI w kodzie to potężne narzędzie, ale nie zastąpi ludzkiego myślenia. W debugowaniu złożonych problemów, optymalizacji wydajności i bezpieczeństwie, ręczna interwencja doświadczonego programisty jest kluczowa. Traktuj AI jak asystenta, nie zastępcę. Używaj go do monotonnych zadań (jak pisanie testów jednostkowych, generowanie dokumentacji), ale krytyczne fragmenty kodu zawsze sprawdzaj sam.
W JurskiTech wierzymy, że technologia ma służyć ludziom, a nie na odwrót. Dlatego w naszych projektach łączymy automatyzację z rzemiosłem – tam, gdzie to przynosi realną wartość. A Ty? Masz swoje historie, gdy AI pokazało swoją ciemną stronę? Podziel się w komentarzu.
