Więcej niż vibe coding — kod generowany przez AI musi zasłużyć na miejsce na produkcji
Prototyp wygenerowany przez AI może pokazać, jak działa pomysł. Oprogramowanie produkcyjne musi spełniać trudniejsze wymagania: działać poprawnie, przestrzegać ograniczeń dostępu, znosić kolejne zmiany i pozostawać zrozumiałe dla osób, które je utrzymują.
Na tej różnicy skupia się polska konferencja DevAI by Data Science Summit, zaplanowana na 19 października 2026 roku online i 20 października w Warszawie. Jej program obejmuje bezpieczeństwo repozytoriów, granice uprawnień, cykle weryfikacji i awarie produkcyjne w kontekście programowania wspomaganego przez AI. Sam program nie dowodzi, że te problemy zostały rozwiązane. Pokazuje jednak, że dyskusja dotyczy pracy inżynierskiej wykraczającej poza generowanie kodu.
Zespołom programistycznym nie wystarczy więc lepsze formułowanie promptów. Potrzebują procesu, który pozwoli przekształcać wygenerowane zmiany w zweryfikowane, łatwe w utrzymaniu oprogramowanie o jasno określonych granicach działania.
Od promptów do odpowiedzialności inżynierskiej
Vibe coding przydaje się do sprawdzania pomysłów: opisujesz oczekiwany rezultat, generujesz implementację i oceniasz, czy pomysł ma potencjał. Wymagania produkcyjne zaczynają się tam, gdzie ktoś musi wyjaśnić działanie kodu, wykazać jego poprawność i wziąć odpowiedzialność za przyszłe zmiany.
Profesjonalne programowanie wspomagane przez AI nie znosi tych obowiązków. Sprawia natomiast, że szczególnie cenne stają się sprawdzone praktyki: testy automatyczne, kontrola wersji, dokumentacja, ciągła integracja, code review i ręczne testowanie. Wyniki tych kontroli mogą dostarczać agentom programistycznym informacji zwrotnych, zamiast pozostawiać je z własną deklaracją, że zadanie zostało ukończone.
Praktycznym punktem wyjścia jest krótki kontrakt zadania. Zanim delegujesz zmianę, określ:
Rezultat: Jak ma się zmienić działanie systemu z perspektywy użytkownika lub biznesu?
Zakres: Które komponenty agent może modyfikować?
Ograniczenia: Które interfejsy, zależności i właściwości bezpieczeństwa muszą pozostać niezmienione?
Dowody: Jakie kontrole potwierdzą powodzenie?
Odpowiedzialność: Kto przeprowadzi przegląd wyniku i będzie go utrzymywać?
Na przykład polecenie „dodaj eksport faktur” pozostawia ważne decyzje bez rozstrzygnięcia. Precyzyjniejszy kontrakt określa uprawnionych użytkowników, wymagane pola, zasady autoryzacji, obsługę błędów i wymagania dotyczące kompatybilności.
Nie chodzi o wydłużanie promptu, tylko o zapisanie, co oznacza „gotowe”, tak aby można było sprawdzić wynik.
Oceniaj wyniki, nie przekonujące wyjaśnienia
Trzeba rozróżnić dwa zadania związane z oceną.
Gdy agent pisze tradycyjne oprogramowanie, zespół musi zweryfikować powstały kod. Gdy sam produkt zawiera agenta, zespół musi również oceniać jego zachowanie w różnych zadaniach, podczas wywoływania narzędzi i w kolejnych próbach.
W obu przypadkach obowiązuje ta sama zasada: sprawdzaj wynik, a nie tylko opis. Stwierdzenie, że rezerwacja się powiodła, nie dowodzi, że rezerwacja istnieje. Podobnie podsumowanie zadania przygotowane przez agenta programistycznego nie dowodzi, że kod w repozytorium nadal działa.
Ocenę agenta zacznij od 20-50 realistycznych zadań wybranych na podstawie ręcznych kontroli i zaobserwowanych niepowodzeń. Określ jasne kryteria sukcesu, przeprowadzaj próby w czystych środowiskach i łącz:
Testy sprawdzające poprawność działania.
Analizę statyczną i kontrole bezpieczeństwa.
Zestawy kryteriów oceny jakości dla mniej obiektywnych wymagań.
Przegląd przez człowieka, który pozwoli skalibrować oceny wystawiane przez model.
Oddziel testy możliwości systemu od testów regresyjnych. Pierwsze sprawdzają, co system potrafi; drugie chronią zachowania, które już działają. Powtarzaj próby tam, gdzie liczy się niezawodność, i obok poprawności śledź opóźnienia, zużycie tokenów oraz koszty. Takie ewaluacje oceniają model wraz z otaczającą go infrastrukturą wykonawczą, a nie sam model w izolacji.
W przypadku eksportu faktur potwierdzenie spełnienia kryteriów akceptacji powinno więc obejmować testy autoryzacji i walidację danych wyjściowych, a nie tylko udane pobranie pliku.
Egzekwuj granice uprawnień poza modelem
Instrukcje dotyczące bezpiecznego zachowania nie zastępują technicznych ograniczeń dostępu.
Swobodę działania agenta ograniczaj w jego środowisku: przez kontrolę dostępu do systemu plików, sieci, danych uwierzytelniających i dostępnych operacji. Zatwierdzanie działań przez człowieka nadal jest przydatne, ale częste prośby o zgodę mogą prowadzić do znużenia. Bezpieczeństwo nie może zależeć wyłącznie od tego, czy człowiek zauważy każde ryzykowne działanie.
W pracy z agentem programistycznym korzystającym z repozytorium zastosuj takie ograniczenia jak:
Izolacja przestrzeni roboczej: Ogranicz zapis do wyznaczonego obszaru roboczego.
Oddzielenie danych uwierzytelniających: Przechowuj sekrety produkcyjne poza środowiskiem wykonawczym.
Ograniczona łączność: Zezwalaj tylko na dostęp do sieci niezbędny do wykonania zadania.
Precyzyjny zakres autoryzacji: Ograniczaj dostęp do kont i operacji, a nie tylko domen docelowych.
Kontrola zaufania przed uruchomieniem: Nie wykonuj konfiguracji pochodzącej z repozytorium, zanim uznasz je za zaufane.
Rejestry działań: Zachowuj wystarczające dane, by można było zbadać zmiany i użycie narzędzi.
Te zabezpieczenia odpowiadają na konkretne przypadki naruszeń. Zdarzało się, że konfiguracja repozytorium wykonywała się przed wyświetleniem okna z pytaniem o zaufanie, a dozwolona domena API posłużyła do przesłania plików na konto kontrolowane przez atakującego. Zaufane konektory również mogą zwracać złośliwe treści. Sandbox lub lista dozwolonych zasobów to zatem jedna warstwa ochrony, a nie pełna gwarancja bezpieczeństwa.
Zespoły wprowadzające agentów mogą zacząć od uprawnień do proponowania i testowania zmian, bez prawa do ich scalania ani wdrażania. Rozszerzaj uprawnienia dopiero wtedy, gdy proces sprawdzi się w praktyce, a odpowiedzialność za dodatkowe ryzyko zostanie jasno przypisana.
Wbuduj weryfikację w cykl dostarczania oprogramowania
Weryfikacja powinna być częścią całego procesu pracy, a nie pojawiać się dopiero podczas końcowego przeglądu.
Testy, linting, formatowanie, ciągła integracja, wdrożenia podglądowe i ręczne QA dostarczają agentom oraz osobom przeglądającym kod konkretnych informacji zwrotnych. Pomagają odróżnić implementację, która wygląda wiarygodnie, od zmiany, która spełnia wymagania projektu.
Praktyczny cykl dostarczania oprogramowania wygląda następująco:
Ustal stan wyjściowy. Zapisz początkową rewizję i testy, które już wtedy kończą się niepowodzeniem.
Zatwierdź plan o ograniczonym zakresie. Przejrzyj proponowaną listę plików, zależności i zmian w interfejsach.
Implementuj przyrostowo. Dbaj, by zmiany były na tyle małe i spójne, żeby dało się je rzetelnie przejrzeć.
Uruchom kontrole. Przetestuj zamierzone działanie oraz powiązane funkcje, które działały przed zmianą.
Sprawdź diff. Przejrzyj nieoczekiwane modyfikacje oraz zmiany w testach lub konfiguracji.
Sprawdź aplikację w działaniu. Zweryfikuj ścieżkę użytkownika w środowisku podglądowym lub stagingowym.
Wydaj zmianę w kontrolowany sposób. Potwierdź, kto odpowiada za utrzymanie i monitoring oraz jak przywrócić działanie systemu.
Traktuj testy i kod aplikacji jako osobne obszary przeglądu. Jeśli agent zmienia oba, osoby przeglądające powinny sprawdzić, czy nowe testy nadal weryfikują pierwotne wymaganie.
Na tym samym etapie oceń łatwość utrzymania kodu. Sprawdź, czy inny programista potrafi wyjaśnić implementację, czy jest ona zgodna z konwencjami projektu i czy dokumentacja opisuje ważne decyzje. Pomyślne przejście testów to początek tej oceny, nie jej koniec.
Mierz dostarczoną wartość, nie ilość wygenerowanego kodu
Dane dotyczące wpływu AI na produktywność wymagają ostrożnej interpretacji. W aktualizacji z lutego 2026 roku METR poinformował, że surowe wyniki wskazywały na szybsze wykonywanie zadań, ale uznał swój eksperyment za niewiarygodną miarę obecnego wpływu AI na produktywność. Dobór uczestników, zadania nieudostępnione do badania oraz trudności z uwzględnieniem równoległej pracy agentów ograniczały zakres możliwych wniosków. Wyniki nie uzasadniają podawania precyzyjnego, uniwersalnego mnożnika produktywności.
Zespół w agencji lub dużej organizacji powinien więc mierzyć cały proces dostarczania oprogramowania. W pilotażu zastosuj wskaźniki, które osobno uwzględniają:
Aktywny nakład pracy człowieka.
Czas działania agenta i koszt jego pracy.
Czas od rozpoczęcia zadania do dostarczenia i zaakceptowania wyniku.
Nakład pracy na przegląd i poprawki.
Błędy po wydaniu oraz pracę potrzebną do przywrócenia działania.
Zanim dopuścisz prototyp wygenerowany przez AI do produkcji, wymagaj zwięzłej dokumentacji wydania: uzgodnionych kryteriów akceptacji, wyników weryfikacji, zakresu uprawnień, wskazanej osoby odpowiedzialnej za utrzymanie i planu przywrócenia działania systemu.
Program DevAI wskazuje kierunek dalszego rozwoju programowania wspomaganego przez AI: mniej uwagi poświęcać wytwarzaniu kodu, a więcej kontroli nad tym, co ten kod może robić.
Rzetelna weryfikacja nie musi oznaczać rezygnacji z szybkości. To ona pozwala zespołom z większą pewnością delegować więcej pracy.
