Vibe coding: czy można zbudować profesjonalną aplikację za pomocą AI?

Granica nie przebiega tam, gdzie większość ludzi ją stawia - nie przy liczbie linii kodu ani przy stopniu skomplikowania. Przebiega tam, gdzie pojawia się słowo cudze: cudze dane, cudze pieniądze, cudzy czas. Poniżej pięć miejsc, w których widać to najwyraźniej.

Bezpieczeństwo, czyli warstwa, której nie widać w przeglądarce

Aplikacja może wyglądać bez zarzutu i jednocześnie nie sprawdzać uprawnień. Zalogowany to nie to samo co uprawniony: jeśli identyfikator zamówienia w adresie da się podmienić na cudzy, a serwer grzecznie odpowie, to nie jest usterka wizualna, tylko wyciek danych. Podobnie z kluczami do usług zewnętrznych wklejonymi do kodu wysyłanego do przeglądarki, brakiem ograniczenia liczby prób logowania i budowaniem zapytań do bazy przez sklejanie tekstu. Żadnej z tych rzeczy nie zobaczycie, klikając.

Osobna kategoria to biblioteki. Model potrafi dopisać do zależności pakiet, który nie istnieje - a ktoś inny może taki pakiet założyć, licząc dokładnie na to. Sprawdzenie, czy każda zależność jest tym, za co się podaje, zajmuje kilka minut i praktycznie nigdy nie zdarza się w trybie, w którym kodu się nie czyta.

Model danych, czyli decyzja, której się później nie cofa

Ekran da się przerobić w godzinę. Struktura bazy, na której leżą dwa lata zamówień, nie. Model językowy proponuje domyślnie układ obsługujący to, o co poprosiliście teraz - a nie to, o co poprosicie za rok. Kiedy okazuje się, że klient może mieć kilka adresów, faktura kilka walut, a zamówienie historię zmian, poprawka nie polega na dopisaniu kolumny, tylko na migracji danych produkcyjnych. To jest ten moment, w którym prototyp przestaje być tani.

Utrzymanie, czyli koszt, który pojawia się w szóstym miesiącu

Kod, który działa, a którego nikt nie rozumie, jest zobowiązaniem, nie majątkiem. Pierwsze tygodnie są tanie i to jest cała siła tej metody. Rachunek przychodzi wtedy, gdy trzeba zmienić coś w środku: nie ma założeń zapisanych nigdzie poza historią czatu, nie ma testów opisujących, co miało się dziać, i nie ma nikogo, kto potrafi powiedzieć, dlaczego akurat tak.

Dochodzi do tego niedeterminizm. Ta sama prośba zadana dwa razy potrafi dać dwie różne architektury. W prototypie to nie przeszkadza. W systemie rozwijanym przez rok oznacza, że po pięciu takich rundach nie ma jednego wzorca, tylko pięć - i każdy trzeba zrozumieć osobno, zanim się cokolwiek ruszy.

Weryfikacja, czyli wąskie gardło, które się przesunęło

Pisanie kodu przestało być kosztowne. Sprawdzenie, czy ten kod robi to, co trzeba, kosztuje tyle samo co zawsze - i na tym polega cała zmiana. Testy napisane przez ten sam model, na podstawie tego samego nieporozumienia, potwierdzą nieporozumienie. Zielony wynik znaczy wtedy dokładnie tyle, że kod jest zgodny sam ze sobą.

Prawo i dane osobowe

Jeśli aplikacja przetwarza dane klientów, obowiązki nie znikają dlatego, że powstała szybciej. Trzeba wiedzieć, gdzie te dane leżą, jak długo, kto ma do nich dostęp i co się dzieje po żądaniu usunięcia. Osobna kwestia to wklejanie danych produkcyjnych do promptu: to przekazanie ich podmiotowi zewnętrznemu i wymaga świadomej decyzji, a nie odruchu w trakcie debugowania.

Nie znajdziecie tu procentu opisującego, jak często zdarza się każdy z tych problemów. Publikowane badania różnią się metodą i wynikami na tyle, że jedna liczba wprowadzałaby w błąd. Sensowniejsze pytanie brzmi: który z tych pięciu punktów dotyczy Waszego projektu i co się stanie, jeśli zawiedzie.

Chodzi o sześć rzeczy, których użytkownik nigdy nie zobaczy, a które rozstrzygają, czy da się na tym oprzeć firmę. Warto je przeczytać jako listę kontrolną, bo każdą da się sprawdzić w konkretnym projekcie w kilkanaście minut.

Ktoś za to odpowiada

Jest osoba, która potrafi powiedzieć, dlaczego system działa tak, a nie inaczej, i jest w stanie to zmienić. Bez tego nie ma czego serwisować - jest czarna skrzynka z cudzymi danymi w środku.

Przetrwa awarię

Kopie zapasowe, o których wiadomo, że da się je odtworzyć, bo ktoś próbował. Monitoring, który odezwie się wcześniej niż klient. Plan na dzień, w którym usługa zewnętrzna przestaje odpowiadać.

Jest zabezpieczona po stronie serwera

Uprawnienia sprawdzane tam, gdzie użytkownik nie sięgnie. Sekrety poza kodem. Ograniczenie liczby prób. To warstwa niewidoczna w przeglądarce i dlatego pomijana najczęściej.

Da się ją przekazać

Ktoś, kto jej nie pisał, wprowadza zmianę, nie psując trzech innych rzeczy. Najostrzejszy sprawdzian z całej szóstki i jednocześnie najrzadziej wykonywany przed podpisaniem umowy.

Zachowanie jest zapisane, nie zapamiętane

Testy i dokumentacja mówią, co system ma robić. Dzięki temu zmiana za rok jest zwykłą pracą, a nie archeologią prowadzoną na produkcji.

Jest zgodna z prawem

Regulamin, polityka prywatności, podstawa przetwarzania danych, obowiązki wobec konsumenta. Ta część nie ma nic wspólnego z kodem i nie powstaje z promptu.

Odpowiedź na pytanie z tytułu brzmi więc: tak, AI może napisać większość kodu profesjonalnej aplikacji - i coraz częściej pisze, również u nas. Nie może natomiast przejąć żadnej z tych sześciu pozycji, bo wszystkie sprowadzają się do tego, że ktoś bierze odpowiedzialność. To nie jest ograniczenie techniczne, które zniknie w kolejnej wersji modelu.

Wszystkie cztery widzieliśmy w projektach, które trafiły do nas po fazie szybkiego budowania. Żadna nie rozwiązuje problemu, a dwie środkowe potrafią sytuację pogorszyć.

Naprawianie błędu kolejnym promptem

Prośba w stylu napraw to, bez wcześniejszej diagnozy, daje kod usuwający objaw. Po kilku takich rundach system ma kilka nakładających się obejść tego samego problemu, a pierwotna przyczyna nadal tam siedzi - tylko trudniej ją teraz znaleźć, bo przykryły ją poprawki.

Testy wygenerowane z istniejącego kodu

Test napisany przez model, który patrzy na gotową implementację, opisuje to, co kod robi, a nie to, co miał robić. Jeśli implementacja jest błędna, test tę pomyłkę zatwierdza i zaczyna chronić ją przed poprawieniem. Testy pisze się z wymagań - to jedna z niewielu zasad, przy których naprawdę nie ma skrótu.

Przepisanie wszystkiego od zera, gdy zrobi się nieprzyjemnie

Kuszące, bo drugie podejście zawsze wygląda na czystsze. Problem w tym, że prototyp zawiera setki drobnych decyzji podjętych w kontakcie z rzeczywistością, a połowa z nich nie jest nigdzie zapisana. Przepisanie gubi je po cichu i odtwarza te same błędy, tylko w nowszej składni.

Zakładanie, że kolejna wersja modelu to rozwiąże

Modele rzeczywiście się poprawiają i część problemów z tej listy zniknie. Nie zniknie ta część, która nie jest problemem technicznym: kto odpowiada za dane klientów, kto odbierze telefon przy awarii i kto podpisuje umowę powierzenia przetwarzania. Czekanie nie jest planem.