Ktoś w Twojej firmie napisał już aplikację, o której nie wiesz — 62% z nich ma krytyczną lukę

Dlaczego to się dzieje właśnie teraz

Przez dwadzieścia lat wąskim gardłem każdego wewnętrznego narzędzia był programista. Pomysł na prosty formularz do zbierania zgłoszeń serwisowych konkurował o czas z integracją ERP i zawsze przegrywał. W efekcie 80% pomysłów na drobne usprawnienia umierało w kolejce, a firma dalej robiła to w Excelu.

Koszt napisania takiej aplikacji spadł do godziny pracy osoby, która zna proces, ale nie zna kodu. Narzędzia do generowania aplikacji z opisu przestały być zabawką w 2025 roku — dzisiejsze modele nie podpowiadają fragmentów kodu, tylko piszą, testują i uruchamiają całość. Kierownik magazynu, który od trzech lat prosi o narzędzie do inwentaryzacji, przestał prosić. Zbudował je sam.

To zjawisko bliskie temu, co opisywaliśmy przy shadow AI, ale z jedną istotną różnicą. Shadow AI to wynoszenie danych na zewnątrz — jednorazowy transfer, który da się zamknąć polityką i szkoleniem. Vibe coding zostawia po sobie działający system, który ktoś zaczyna traktować jak infrastrukturę. Wyciek się kończy; aplikacja żyje dalej i z każdym miesiącem coraz więcej osób na niej polega.

Co dokładnie pokazują dane

Warto oddzielić panikę od liczb, bo w tej dyskusji łatwo o jedno i drugie. Kod generowany przez modele nie jest zły — jest niedokończony w powtarzalny, przewidywalny sposób. Model dobrze pisze to, o co go poproszono, i pomija wszystko, o co nie poproszono, a bezpieczeństwo należy do rzeczy, o które nikt nie prosi wprost.

• Veracode przetestowało ponad 100 modeli na zadaniach wrażliwych z punktu widzenia bezpieczeństwa: 45% wygenerowanych fragmentów zawierało podatność z listy OWASP Top 10. Przy ochronie przed cross-site scriptingiem odsetek błędów sięgał 86%.
• Skan ponad 1400 produkcyjnych aplikacji zbudowanych tą metodą: 65% z problemami bezpieczeństwa, 58% z co najmniej jedną luką krytyczną.
• Liczba zgłoszonych podatności (CVE) przypisanych bezpośrednio narzędziom do generowania kodu rosła w 2026 roku z 6 w styczniu, przez 15 w lutym, do 35 w marcu. Badacze z Georgia Tech szacują, że realna liczba jest pięć do dziesięciu razy wyższa.
• Gartner przewiduje, że do 2028 roku podejście „prompt-to-app” w rękach osób bez przygotowania inżynierskiego zwiększy liczbę defektów oprogramowania o 2500% i wywoła kryzys jakościowy.

Trzy koszty, których nie widać w pierwszym tygodniu

Rachunek za vibe coding nie przychodzi wtedy, kiedy aplikacja powstaje. Przychodzi trzy do dziewięciu miesięcy później i ma trzy pozycje.

Pierwsza to dane. Aplikacja zbudowana w godzinę zwykle przechowuje dane tam, gdzie było najprościej — w zewnętrznej usłudze, na koncie prywatnym, z kluczem API wpisanym wprost w kod. Jeżeli w środku są dane klientów, jesteście administratorem danych w miejscu, o którym nie wie ani IT, ani osoba odpowiedzialna za RODO. Nie ma umowy powierzenia, nie ma rejestru czynności, nie ma kopii zapasowej.

Druga to własność. Narzędzie zna jedna osoba i nikt nie zna go poza nią. Kiedy ta osoba odchodzi albo zmienia dział, firma zostaje z systemem, którego nie umie zmienić ani wyłączyć, bo nie wiadomo, co jeszcze na nim wisi. Widzieliśmy firmy fakturujące klientów z aplikacji, której autor był na wypowiedzeniu.

Trzecia to prawda o danych. Dwa narzędzia zbudowane niezależnie przez dwa działy zaczynają liczyć to samo inaczej. Sprzedaż raportuje jedną liczbę, controlling drugą, i nikt nie potrafi rozstrzygnąć, która jest poprawna, bo obie mają swoje źródło. To jest dokładnie ten sam problem, o który rozbija się większość wdrożeń AI — opisywaliśmy go przy danych z KSeF. Model, który później ma odpowiadać na pytania o firmę, dziedziczy ten bałagan w całości.

Jedna reguła, która rozstrzyga niemal wszystko

Nie potrzeba tu polityki na dwadzieścia stron. Wystarczy jedno pytanie zadane przed uruchomieniem: czy ta aplikacja dotyka danych osobowych, pieniędzy albo świata zewnętrznego?

Jeśli odpowiedź brzmi „nie” — puśćcie to. Kalkulator marży, generator opisów produktów na bazie własnej listy, panel do przeglądania eksportu z systemu, makieta procesu do pokazania zarządowi. Ryzyko ogranicza się do tego, że narzędzie policzy coś źle, a to wychodzi szybko i kosztuje niewiele. Blokowanie tego jest czystą stratą — odbiera firmie najtańsze usprawnienia, jakie ma dziś w zasięgu.

Jeśli odpowiedź brzmi „tak” — prototyp jest w porządku, produkcja nie. Aplikacja obsługująca płatności, przechowująca dane klientów, wysyłająca maile do kontrahentów albo wystawiona do internetu wymaga przeglądu przez kogoś, kto umie czytać kod. Nie chodzi o przepisanie od zera. Chodzi o godzinę pracy, w której ktoś sprawdza uwierzytelnianie, klucze i to, gdzie faktycznie leżą dane. W praktyce ta godzina wyłapuje większość z tych 58%.

Granica jest tu identyczna jak przy wyborze między agentem a zwykłym skryptem: im wyższy koszt pomyłki, tym więcej struktury wokół. Rozpisaliśmy to w tekście o tym, czy potrzebujesz agenta AI, czy automatyzacji.

Gdzie vibe coding realnie zarabia

Najlepszym zastosowaniem nie jest budowanie systemów. Jest nim rozstrzyganie sporów o to, co budować — a to w małej firmie jest zwykle droższe niż samo budowanie.

• Prototyp zamiast specyfikacji. Zamiast pisać dokument opisujący wymarzone narzędzie, zbuduj klikalną wersję w dwa dni i daj ją trzem osobom, które mają jej używać. Połowa wymagań z dokumentu okazuje się niepotrzebna, a dwa krytyczne braki wychodzą natychmiast.
• Weryfikacja pomysłu przed wyceną. Jeżeli dostawca wycenia narzędzie na 60 tysięcy, prototyp za dwa dni pracy odpowiada na pytanie, czy w ogóle ktoś tego użyje. To najtańsza dostępna forma odrzucenia złego projektu.
• Narzędzia jednorazowe. Przetworzenie eksportu, przygotowanie danych do migracji, jednorazowy raport dla banku. Rzeczy, które mają zadziałać raz i zostać skasowane — i które przez lata robiło się ręcznie przez trzy dni.
• Wewnętrzne panele tylko do odczytu. Podgląd danych, które już gdzieś są, bez możliwości zapisu. Niskie ryzyko, natychmiastowa wartość, zero integracji zwrotnych.
• Praca nad ogłoszeniami, opisami, szablonami — czyli wszystko, co i tak jest tekstem, a dotąd czekało na wolne popołudnie.

Czego tą metodą nie budować

Lista jest krótka i w praktyce dobrze się broni. Nie budujcie tak niczego, co obsługuje płatności lub księgowość, niczego, co przechowuje dane osobowe klientów lub pracowników, niczego wystawionego publicznie do internetu bez przeglądu, i niczego, co po cichu zapisuje dane do systemu produkcyjnego — bo błąd w takim zapisie odkrywa się zwykle po kwartale.

Osobna kategoria to narzędzia podłączone do firmowych systemów. Kiedy aplikacja dostaje dostęp do skrzynki, CRM-a czy dysku, przestaje być kalkulatorem i staje się integracją, z całym ryzykiem uprawnień, które za tym idzie. To jest moment, w którym warto zejść z improwizacji na standard — mechanizm i miny bezpieczeństwa opisaliśmy w tekście o MCP i integracji AI z systemami firmy.

Jak to poukładać w dwa tygodnie

Zakaz nie zadziała — sprawdziliśmy to na tylu firmach, że można to uznać za regułę. Osoba, która potrafi rozwiązać swój problem w godzinę, rozwiąże go niezależnie od polityki, tylko przestanie o tym mówić. Celem jest widoczność, nie kontrola.

1. Amnestia. Ogłoście, że każdy, kto zbudował coś własnego, może to zgłosić bez konsekwencji. Bez tego kroku żaden spis nie będzie pełny, a firmy regularnie odkrywają przy tej okazji cztery lub pięć aplikacji, o których zarząd nie miał pojęcia.
2. Spis. Co to robi, kto tego używa, gdzie leżą dane, kto to napisał. Cztery kolumny w arkuszu wystarczą — celem jest lista, nie dokumentacja.
3. Podział na trzy kosze: zostawiamy jak jest, wymaga przeglądu, wyłączamy. Reguła z sekcji wyżej rozstrzyga przydział w większości przypadków w kilka sekund.
4. Jedna zasada na piśmie, w trzech zdaniach: co wolno budować samodzielnie, kiedy trzeba zgłosić, do kogo. Dłuższy dokument nikt nie przeczyta.
5. Jedna osoba, która raz na kwartał przegląda listę. Bez tego cały przegląd jest jednorazowy i za rok wracacie do punktu wyjścia — dokładnie ten sam mechanizm, który rozkłada wdrożenia opisane w tekście o luce adopcji.

Co to znaczy dla firm, które dopiero wybierają dostawcę

Ta zmiana ma jeszcze jeden skutek, o którym mówi się rzadko: przesuwa granicę tego, za co warto płacić z zewnątrz. Jeżeli formularz, panel i prosty CRM potrafi dziś zbudować Wasz własny zespół w kilka dni, to zamawianie ich na zewnątrz za kilkadziesiąt tysięcy przestało mieć sens. Wartość dostawcy przeniosła się na to, czego prototyp nie załatwia: architekturę danych, integracje z systemami, bezpieczeństwo, utrzymanie i decyzję o tym, czego nie budować.

W praktyce oznacza to inny sposób rozmowy o zakresie. Zamiast pytać „ile kosztuje zbudowanie tego narzędzia”, warto zapytać „czy to narzędzie w ogóle powinno istnieć osobno, czy jest funkcją czegoś, co już mamy”. Odpowiedź często oszczędza cały projekt. Widełki i strukturę kosztów rozpisaliśmy w tekście o kosztach wdrożenia AI.

Od czego zacząć

Pierwszy krok zajmuje jedno spotkanie i nie wymaga budżetu: zapytajcie zespół wprost, kto zbudował sobie coś własnego w ostatnim półroczu — bez tonu przesłuchania. W firmie na pięćdziesiąt osób odpowiedź to zwykle od dwóch do sześciu narzędzi, a osoba prowadząca spotkanie zna wcześniej najwyżej jedno z nich.

Drugi krok to przepuszczenie każdego z nich przez jedno pytanie: dane osobowe, pieniądze, świat zewnętrzny — tak czy nie. Większość trafi do kosza „zostawiamy”, i to jest dobra wiadomość, bo znaczy, że zespół sam rozwiązuje swoje problemy. Reszta to zwykle jedna lub dwie aplikacje, które warto obejrzeć zanim staną się częścią infrastruktury.

Tak z tym pracujemy: najpierw audyt tego, co już w firmie działa — łącznie z tym, czego nie ma w żadnym rejestrze — potem decyzja, co zostaje, co wymaga przeglądu, a co zastąpić rozwiązaniem, które ktoś utrzymuje. Zakres konsultingu i wdrożeń AI opisaliśmy osobno, stawki znajdziesz w cenniku, a jeśli chcesz sprawdzić, co powstało u Was poza radarem — umów bezpłatną konsultację.