Kiedy "zrobię to sam" przestaje być dobrym pomysłem - o złudzeniu łatwości w erze AI
autor: Grzegorz Babiarz - 20.03.2026 - 11 min czytania
Niedawno w polskiej społeczności IT huczało od sprawy kogoś, kto w stworzył z pomocą AI aplikację do obsługi KSeF. Aplikacja działa, autor udostępnił kod w serwisie GitHub i podzielił się nią w mediach społecznościowych, w dobrej wierze, aby inni również mogli z niego skorzystać do ułatwienia sobie życia. To czego nie był świadomy ale uświadomiły go o tym osoby zawodowo zajmujące się programowaniem, to, że publikując kod swojej aplikacji udostępnił innym również dostęp do faktur swojej własnej działalności.
Nie jest to odosobniony przypadek. Żyjemy w czasach, gdzie granica między "potrafię to zrobić" a "powinienem to udostępnić publicznie" zaciera się w niebezpieczny sposób. AI sprawił, że każdy może napisać działającą aplikację. Ale nie obniżył konsekwencji tego, co się stanie gdy ta aplikacja zawiedzie, wycieknie dane, lub zostanie użyta w sposób którego autor nie przewidział.
Dlaczego dziś każdy może napisać aplikację (i to jest OK)
Nigdy wcześniej tworzenie oprogramowania nie było tak dostępne. ChatGPT, Claude, GitHub Copilot potrafią wygenerować działający kod w sekundach. YouTube pełen jest tutoriali, dokumentacje API są przejrzyste, Stack Overflow nie jest już nawet potrzebny. Jeden z inżynierów OpenAI przyznał niedawno publicznie, że 100% jego kodu pisze AI - on tylko zleca zadania i weryfikuje wyniki.
I to jest fantastyczne. Demokratyzacja technologii to ogromna wartość. Ludzie uczą się programowania szybciej, testują pomysły bez zatrudniania całych zespołów, rozwiązują własne problemy tworząc małe narzędzia. Przedsiębiorcy sprawdzają koncepcje biznesowe zanim wydadzą fortunę na development.
Problem nie leży w tym, że ludzie tworzą. Problem pojawia się gdy coś stworzonego jako eksperyment lub rozwiązanie własnego problemu zaczyna być używane przez innych - szczególnie w kontekście produkcyjnym. Bo wtedy zmienia się wszystko.
Gdzie zaczyna się problem
Największym niebezpieczeństwem nie jest brak umiejętności technicznych. AI potrafi pomóc napisać całkiem przyzwoity kod. Prawdziwym problemem jest brak świadomości tego, czego nie widać.
Brak świadomości zagrożeń. Osoba bez doświadczenia w tworzeniu systemów produkcyjnych nie wie, że jej kod może być niebezpieczny nawet gdy działa poprawnie. Nie wie że dane w repozytorium Git są publiczne na zawsze, nawet gdy się je potem usunie. Nie wie że klucz API w kodzie to jak zamek którego klucz zostawiasz w drzwiach. AI wygeneruje działający kod, ale nie ostrzeże że ten kod jest dziurawy jak szwajcarski ser.
Brak walidacji bezpieczeństwa. Bezpieczne przechowywanie poufnych danych, szyfrowanie transmisji, zarządzanie sesjami, ochrona przed atakami - to wszystko wymaga wiedzy której AI nie da automatycznie. Możesz zapytać ChatGPT "jak bezpiecznie przechowywać hasła" i dostaniesz poprawną odpowiedź. Problem w tym że musisz wiedzieć że powinieneś zapytać.
Brak rozumienia architektury. Dlaczego secrets nie mogą być w kodzie? Dlaczego baza danych nie powinna trafiać do repozytorium? Dlaczego ten kod który działa lokalnie zawiedzie w produkcji? To wiedza którą zdobywa się przez lata praktyki lub bardzo bolesne lekcje. AI może wytłumaczyć zasady, ale nie nauczy intuicji.
Brak odpowiedzialności prawnej. Gdy tworzysz narzędzie które przetwarza dane osobowe, faktury, płatności - odpowiadasz za nie prawnie. RODO to nie sugestia - to prawo. Wyciek danych może oznaczać kary finansowe, pozwy, utratę reputacji. I nie pomoże ci licencja MIT z dopiskiem "bez gwarancji".
Co ważniejsze - typowy autor nie wie że nie wie o tych wszystkich rzeczach. To klasyczny efekt Dunninga-Krugera w programowaniu. Kod działa na lokalnej maszynie z testowymi danymi, więc wydaje się że wszystko jest OK.
Prototyp to nie to samo co produkt
Tu dochodzimy do sedna sprawy. Istnieje fundamentalna różnica między kodem który działa a kodem który jest gotowy do użycia produkcyjnego.
Prototyp to proof of concept. Ma pokazać że coś da się zrobić, że pomysł ma sens. Może być brzydki, nieprzetestowany, bez obsługi błędów. Bo nikt oprócz twórcy go nie używa, a jeśli coś pójdzie nie tak - trudno, zrestartujemy i spróbujemy jeszcze raz. Prototyp żyje w kontrolowanym środowisku, z testowymi danymi, pod czujnym okiem osoby która go stworzyła.
Produkt to zupełnie inna liga. Produkt musi działać niezawodnie przez miesiące i lata. Musi obsłużyć wszystkie edge case'y których twórca nie przewidział. Musi działać dla użytkowników o różnych poziomach kompetencji, w różnych środowiskach, z różnymi danymi. Musi być bezpieczny, bo przetwarza prawdziwe dane prawdziwych ludzi. Musi być możliwy do zdiagnozowania gdy coś pójdzie nie tak. Musi mieć dokumentację, plan napraw i aktualizacji.
W przypadku systemów przetwarzających dane finansowe czy osobowe dochodzą jeszcze wymogi prawne. Bezpieczne przechowywanie danych wrażliwych, szyfrowanie transmisji, prawo użytkownika do usunięcia danych, logowanie dostępu - to nie jest opcjonalne.
AI jako narzędzie – ale nie gwarancja jakości
ChatGPT i podobne narzędzia to niesamowite wsparcie w programowaniu. Dla kogoś uczącego się to rewelacyjny nauczyciel dostępny 24/7. Ale AI ma fundamentalne ograniczenia, o których warto pamiętać.
AI nie rozumie kontekstu biznesowego. Nie wie że ta aplikacja będzie używana przez tysiące firm do wystawiania faktur na miliony złotych. Nie przewidzi że użytkownik może próbować coś zrobić o trzeciej w nocy gdy serwer jest w konserwacji. Nie pomyśli o tym co się stanie gdy API zmieni format odpowiedzi.
AI nie ponosi odpowiedzialności. Gdy kod który wygenerowało zawiedzie i ktoś straci przez to pieniądze lub dane - nikt nie pozwie OpenAI. Odpowiedzialność spoczywa na tobie, osobie która ten kod stworzyła i udostępniła.
AI nie ma świadomości bezpieczeństwa w kontekście. Może wygenerować kod który działa, ale przechowuje hasła w plain text albo jest podatny na injection. Powie ci jak coś zrobić, ale nie ostrzeże że robisz to niebezpiecznie - chyba że wprost zapytasz o security. A jeśli nie wiesz że powinieneś zapytać, to nie zapytasz.
AI nie analizuje konsekwencji. Nie powie ci że ten plik SQLite z danymi nie powinien trafić do repozytorium Git. Nie zauważy że commitując zmienne środowiskowe z tokenami publikujesz swoje credentials. Nie podpowie że .gitignore to nie jest opcjonalna ozdoba ale krytyczny element bezpieczeństwa.
To nie jest krytyka AI - to po prostu realistyczne spojrzenie na jego możliwości i ograniczenia na obecnym stopniu rozwoju. AI to narzędzie, świetne narzędzie, ale wymaga świadomego użycia.
Świadomość własnych ograniczeń
Tu dochodzimy do sedna sprawy. Różnica między senior developerem który pisze kod z pomocą AI a nowicjuszem który robi to samo nie leży w jakości wygenerowanego kodu. Leży w tym co dzieje się po wygenerowaniu.
Senior wie co sprawdzić. Wie jakie pytania zadać AI. Wie kiedy wygenerowany kod jest niebezpieczny nawet gdy działa. Ma w głowie checklistę rzeczy które muszą być OK zanim coś trafi do produkcji - i ta checklista powstała z lat doświadczenia, z błędów własnych i cudzych i nocnych napraw krytycznych bugów.
Osoba bez doświadczenia nie ma tej checklisty. I co gorsza - często nie wie że jej potrzebuje. Aplikacja działa, problem został rozwiązany, wydaje się że wszystko jest w porządku. To samo złudzenie które towarzyszyło panu Dawidowi gdy klikał "publish" na GitHubie.
AI to potężne narzędzie, ale to tylko narzędzie. Piła mechaniczna też pozwala każdemu ciąć deski, ale nie czyni nikogo z nas stolarzem. Różnica między użytkownikiem piły a stolarzem to nie tylko umiejętność jej obsługi, ale wiedza o drewnie, o konstrukcji, o tym co się stanie gdy coś źle zmierzymy lub źle zetniemy.
Co warto zrobić zanim się podzielisz
Nie chodzi o to żeby zniechęcać do publikowania kodu czy dzielenia się projektami. Open source i kultura współdzielenia to fundament współczesnej technologii. Ale można to robić odpowiedzialnie.
Poczytaj podstawy o bezpieczeństwie. Nie musisz być ekspertem od security, ale znajomość podstaw, najważniejszych dobrych praktyk i krytycznych błędów zajmie ci kilka godzin czytania czy oglądania, a uchroni przed największymi wpadkami.
Zwiększ swoją świadomość dzięki AI. I tak właśnie wygenerowałeś za jej pomocą swoją aplikację więc dlaczego nie zapytać jej o to co może pójść nie tak? Bądź dociekliwy i kreatywny, zacznij od ogólnych pytań o bezpieczeństwo, prywatność, jakość kodu i architektury. Nie bój się podważać tego, co zrobiło AI nawet jeśli działa. Weryfikuj informacje w innych źródłach, choćby to miał być tylko inny model AI - możesz otrzymać zupełnie inny punkt widzenia. To da Ci podstawową świadomość o rozwiązaniu które tworzysz. Pamiętaj, nie jesteś specjalistą, im więcej się dowiesz tym lepiej dla Ciebie i Twojej aplikacji.
Poproś o feedback zanim opublikujesz. Może masz znajomego, który zajmuje się tworzeniem oprogramowania profesjonalnie? Jeśli nie to znajdź forum, grupę, community gdzie ludzie chętnie pomogą. "Napisałem z pomocą AI moją pierwszą aplikację, czy ktoś mógłby rzucić okiem na oczywiste problemy?" to pytanie które w większości społeczności spotka się z pomocą, nie wyśmiewaniem.
Oznacz jasno że to projekt uczący się. W README napisz wprost: "To mój pierwszy projekt z AI, uczę się programowania, kod nie był sprawdzany przez profesjonalistów". To nie wstyd, każdy kiedyś zaczyna, a lepiej zacząć w jak najlepszy sposób. Ludzie będą bardziej wyrozumiali dla niedoskonałości.
Zastanów się czy publikować w ogóle. Nie każdy kod musi trafić na GitHuba. Czasem najlepszą opcją jest zatrzymać go dla siebie nawet jeśli uważasz, że jest najlepszy, absolutnie niezbędny i ułatwi życie połowie ludzkości. Możesz też zatrzymać swoją aplikację dla wąskiego grona znajomych którzy rozumieją że to eksperyment. Szczególnie gdy chodzi o wrażliwe dane lub krytyczne procesy biznesowe.
Zamknięcie bez moralizowania
Dostępność AI w programowaniu to ogromna szansa. Więcej ludzi może tworzyć, eksperymentować, uczyć się, rozwiązywać swoje problemy. To fantastyczne i warto to wspierać.
Ale wraz z niższą barierą wejścia musi iść większa świadomość odpowiedzialności. Kod który działa to nie to samo co kod który jest bezpieczny. Aplikacja która rozwiązuje twój problem to nie to samo co aplikacja gotowa do użycia przez innych.
Historia z KSeF to nie jest powód do wyśmiewania kogoś kto próbował. To przypomnienie dla nas wszystkich - zarówno dla tych którzy uczą się z AI, jak i dla doświadczonych deweloperów - że technologia to jedno, a świadomość konsekwencji to drugie.
Twórz, eksperymentuj, dziel się. Ale rób to z głową. A jeśli nie jesteś pewien - zapytaj kogoś kto wie więcej. To nie wstyd. To mądrość.